Re: [protobuf] Will protobuf support JSON?

2011-04-01 Thread Austin Ziegler 
On Fri, Apr 1, 2011 at 11:19 AM, Konrad Malawski
 wrote:
> Sure, just google "protobuf json" -> http://code.google.com/p/protobuf-json/

> 2011/4/1 ZHOU Xiaobo 
>>
>> script languages can easily dealing with JSON, but
>> in C/C++ is actually difficult.
>> can protobuf support json encode/decode?

A few weeks ago, someone on my team wrote something in Ruby to
generate the .proto file that would be associated with the JSON that
we're expecting, plus the necessary YAJL code to parse the JSON in
C++.

It's not that hard to do, but we can't open source our work (it's too
raw in any case).

-a
-- 
Austin Ziegler • halosta...@gmail.com • aus...@halostatue.ca
http://www.halostatue.ca/ • http://twitter.com/halostatue

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To post to this group, send email to protobuf@googlegroups.com.
To unsubscribe from this group, send email to 
protobuf+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/protobuf?hl=en.

[protobuf] Java: Protobuf jars compatibility (2.4.0 with 2.0.3)

2011-04-01 Thread Blackbird 
Hi,

After finishing our project using latest protobuf-java-2.4.0a jar and
corresponding protoc compiler, we came to know that there are usages
of protobuf-2.0.3.jar (which is older) in our system. So, now it turns
only one of these jars can exists.

Can you guys let me know whether there will be any problem when the
old jar is replaced with new 2.4.0a jar?

I agree that I have test the behavior anyway, still I would like to
know whether Google Protocol Buffers officially support this version
backward-comaptibility?

Thanks,
{"name": "blackbird"}


-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To post to this group, send email to protobuf@googlegroups.com.
To unsubscribe from this group, send email to 
protobuf+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/protobuf?hl=en.

[protobuf] Re: Repeat custom message extensions not working in Java on deserialisation

2011-04-01 Thread Ahab 
That worked.  No issues now that I have added in the
ExtensionRegistry.

Thanks a lot Jason.

On Apr 1, 5:17 pm, Jason Hsueh  wrote:
> The most common issue with Java and extensions is not passing an
> ExtensionRegistry containing the extensions you want to the deserialization
> method. However, you mention that the parse is failing: if you didn't
> register the extensions, or didn't use an extension registry, then the data
> would simply be ignored. If you're getting an
> InvalidProtocolBufferException, the parse failure indicates either you are
> parsing bad data, or one of the required fields has not been set.
>
> If that doesn't get you going in the right direction, can you send a short
> code snippet?
>
> On Fri, Apr 1, 2011 at 9:06 AM, Ahab  wrote:
> > I've been using protocols for a while, and just moved to extensions
> > lasts week.  Deserialising out of a byte[] back into my Batch object
> > is now failing - protos below.  I am looking in Eclipse and it is
> > struggling with the repeat batchData objects - and my test is
> > failing.  They end up not being retrievable after deserialisation.  I
> > can see the elements are present before serialisation, but are there
> > once they come back out.
>
> > Is this all supported, am I doing anything wrong?
>
> > Thanks in advance.
>
> > message GenericData {
> >    // Should key be an enum - I think so - part of the contract
> >    required string idKey = 1;
> >    enum DataType {
> >        INTEGER = 1 ;
> >        STRING = 2 ;
> >        START = 3;
> >        END = 4 ;
> >        TIMING = 5;
> >    }
> >    required DataType dataType = 2;
>
> >    optional int32 intType = 3 [default = 0];
> >    optional string strType = 4 [default = ""];
> >    optional double startTime = 5 [default = 0];
> >    optional double stopTime = 6 [default = 0];
> > }
>
> > message Batch {
> >    required string idRequest = 1;
> >    required string idClient = 2;
> >    enum AppType {
> >        A = 0;
> >        B = 1;
> >    }
> >    required AppType idApplication = 3 [ default = A ];
> >    optional string appInstance = 4;
>
> >    extensions 100 to 199;
> > }
>
> > extend Batch {
> >    repeated GenericData batchData = 100;
> >    repeated TaskList taskList = 101;
> > }
>
> > I can send code too - but hoping to get quick steer on whether I am
> > doing something badly wrong.
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Protocol Buffers" group.
> > To post to this group, send email to protobuf@googlegroups.com.
> > To unsubscribe from this group, send email to
> > protobuf+unsubscr...@googlegroups.com.
> > For more options, visit this group at
> >http://groups.google.com/group/protobuf?hl=en.

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To post to this group, send email to protobuf@googlegroups.com.
To unsubscribe from this group, send email to 
protobuf+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/protobuf?hl=en.

Re: [protobuf] Repeat custom message extensions not working in Java on deserialisation

2011-04-01 Thread Jason Hsueh 
The most common issue with Java and extensions is not passing an
ExtensionRegistry containing the extensions you want to the deserialization
method. However, you mention that the parse is failing: if you didn't
register the extensions, or didn't use an extension registry, then the data
would simply be ignored. If you're getting an
InvalidProtocolBufferException, the parse failure indicates either you are
parsing bad data, or one of the required fields has not been set.

If that doesn't get you going in the right direction, can you send a short
code snippet?

On Fri, Apr 1, 2011 at 9:06 AM, Ahab  wrote:

> I've been using protocols for a while, and just moved to extensions
> lasts week.  Deserialising out of a byte[] back into my Batch object
> is now failing - protos below.  I am looking in Eclipse and it is
> struggling with the repeat batchData objects - and my test is
> failing.  They end up not being retrievable after deserialisation.  I
> can see the elements are present before serialisation, but are there
> once they come back out.
>
> Is this all supported, am I doing anything wrong?
>
> Thanks in advance.
>
> message GenericData {
>// Should key be an enum - I think so - part of the contract
>required string idKey = 1;
>enum DataType {
>INTEGER = 1 ;
>STRING = 2 ;
>START = 3;
>END = 4 ;
>TIMING = 5;
>}
>required DataType dataType = 2;
>
>optional int32 intType = 3 [default = 0];
>optional string strType = 4 [default = ""];
>optional double startTime = 5 [default = 0];
>optional double stopTime = 6 [default = 0];
> }
>
> message Batch {
>required string idRequest = 1;
>required string idClient = 2;
>enum AppType {
>A = 0;
>B = 1;
>}
>required AppType idApplication = 3 [ default = A ];
>optional string appInstance = 4;
>
>extensions 100 to 199;
> }
>
> extend Batch {
>repeated GenericData batchData = 100;
>repeated TaskList taskList = 101;
> }
>
> I can send code too - but hoping to get quick steer on whether I am
> doing something badly wrong.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Protocol Buffers" group.
> To post to this group, send email to protobuf@googlegroups.com.
> To unsubscribe from this group, send email to
> protobuf+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/protobuf?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To post to this group, send email to protobuf@googlegroups.com.
To unsubscribe from this group, send email to 
protobuf+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/protobuf?hl=en.

[protobuf] Repeat custom message extensions not working in Java on deserialisation

2011-04-01 Thread Ahab 
I've been using protocols for a while, and just moved to extensions
lasts week.  Deserialising out of a byte[] back into my Batch object
is now failing - protos below.  I am looking in Eclipse and it is
struggling with the repeat batchData objects - and my test is
failing.  They end up not being retrievable after deserialisation.  I
can see the elements are present before serialisation, but are there
once they come back out.

Is this all supported, am I doing anything wrong?

Thanks in advance.

message GenericData {
// Should key be an enum - I think so - part of the contract
required string idKey = 1;
enum DataType {
INTEGER = 1 ;
STRING = 2 ;
START = 3;
END = 4 ;
TIMING = 5;
}
required DataType dataType = 2;

optional int32 intType = 3 [default = 0];
optional string strType = 4 [default = ""];
optional double startTime = 5 [default = 0];
optional double stopTime = 6 [default = 0];
}

message Batch {
required string idRequest = 1;
required string idClient = 2;
enum AppType {
A = 0;
B = 1;
}
required AppType idApplication = 3 [ default = A ];
optional string appInstance = 4;

extensions 100 to 199;
}

extend Batch {
repeated GenericData batchData = 100;
repeated TaskList taskList = 101;
}

I can send code too - but hoping to get quick steer on whether I am
doing something badly wrong.

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To post to this group, send email to protobuf@googlegroups.com.
To unsubscribe from this group, send email to 
protobuf+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/protobuf?hl=en.

Re: [protobuf] Will protobuf support JSON?

2011-04-01 Thread Konrad Malawski 
Sure, just google "protobuf json" -> http://code.google.com/p/protobuf-json/
-- 
Konrad Malawski
XSolve.pl  - Software Developer
Java.pl  - Polish Java User Group
Project13.pl  - Private Portfolio & Blog


2011/4/1 ZHOU Xiaobo 

> script languages can easily dealing with JSON, but
> in C/C++ is actually difficult.
> can protobuf support json encode/decode?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Protocol Buffers" group.
> To post to this group, send email to protobuf@googlegroups.com.
> To unsubscribe from this group, send email to
> protobuf+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/protobuf?hl=en.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To post to this group, send email to protobuf@googlegroups.com.
To unsubscribe from this group, send email to 
protobuf+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/protobuf?hl=en.

[protobuf] Will protobuf support JSON?

2011-04-01 Thread ZHOU Xiaobo 
script languages can easily dealing with JSON, but
in C/C++ is actually difficult.
can protobuf support json encode/decode?

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To post to this group, send email to protobuf@googlegroups.com.
To unsubscribe from this group, send email to 
protobuf+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/protobuf?hl=en.

Re: [protobuf] Re: self including message array

2011-04-01 Thread Jason Hsueh 
You appear to be using a third party implementation for pure C. You'll have
to check with the author of the implementation.

On Fri, Apr 1, 2011 at 7:25 AM, zad  wrote:

>  message resource_info {
>optional string device_name=18;
>optional Res_type res_type=19 [default=RAW];
>repeated resource_info resources=2;
> }
>
> the above message generates the following .h
>
> /*! \file deviceManager_hint.h
>  *  \brief message hints
>  */
>
> /*--
>  * Generated 2011-04-01 15:14:14 +0100
>  *   by protoc99 version 0.17
>  * DO NOT EDIT! See "man protoc99" for details.
>  *
>  *--
>  */
>
> #ifndef _CIDL_DEVICEMANAGER_HINT_H
> #define _CIDL_DEVICEMANAGER_HINT_H
>
> #include 
>
> enum {
>  cidl_resource_info_size_hint = 0
>+ PROTOC99_TAG_TYPE_SIZE(1) + PROTOC99_MAX_VAR32_SIZE +
> PROTOC99_DEFAULT_STRING_LENGTH /* resource_info::device_name */
>+ PROTOC99_TAG_TYPE_SIZE(2) + PROTOC99_MAX_VAR32_SIZE /*
> resource_info::res_type */
>+ (PROTOC99_TAG_TYPE_SIZE(3) + PROTOC99_MAX_VAR32_SIZE +
> cidl_resource_info_size_hint) * PROTOC99_DEFAULT_ARRAY_COUNT /*
> resource_info::resu
>  cidl_device_list_size_hint = 0
>+ PROTOC99_TAG_TYPE_SIZE(1) + PROTOC99_MAX_VAR32_SIZE /*
> device_list::found_dev */
>+ (PROTOC99_TAG_TYPE_SIZE(2) + PROTOC99_MAX_VAR32_SIZE +
> cidl_resource_info_size_hint) * PROTOC99_DEFAULT_ARRAY_COUNT /*
> device_list::resour
>  cidl_get_device_info_size_hint = 0
>+ PROTOC99_TAG_TYPE_SIZE(1) + PROTOC99_MAX_BOOL_SIZE /*
> get_device_info::result */,
>  cidl_device_info_registered_size_hint = 0,
>  cidl_device_info_unregistered_size_hint = 0,
>
> };
>
> #endif /* _CIDL_DEVICEMANAGER_HINT_H */
>
> And during gcc build I got an "/cidl_deviceManager_hint.h:25: error:
> 'cidl_resource_info_size_hint' undeclared here (not in a function)"
> error from the compiler.
>
> On Apr 1, 2:05 am, Jason Hsueh  wrote:
> > Recursive definitions should work, though I'm not sure we have a test
> case
> > to verify use in repeated fields. I know there is one for optional
> messages.
> > What result did you get?
> >
> >
> >
> >
> >
> >
> >
> > On Tue, Mar 29, 2011 at 5:58 AM, zad  wrote:
> > > Is it possible to have in a message declaration an array of the
> > > declaring message?
> > > Let me explain better:
> > > I'm trying to achieve the following:
> >
> > > message resource_info {
> > >optional string device_name=18;
> > >optional Res_type res_type=19 [default=RAW];
> > >repeated resource_info resources=2;
> > > }
> >
> > > I tried also with this:
> > > message resource_info {
> > >optional string device_name=18;
> > >optional Res_type res_type=19 [default=RAW];
> > >extensions 2 to 3;
> > > }
> > > extend resource_info{
> > >repeated resource_info resources=2;
> > > }
> >
> > > --
> > > You received this message because you are subscribed to the Google
> Groups
> > > "Protocol Buffers" group.
> > > To post to this group, send email to protobuf@googlegroups.com.
> > > To unsubscribe from this group, send email to
> > > protobuf+unsubscr...@googlegroups.com.
> > > For more options, visit this group at
> > >http://groups.google.com/group/protobuf?hl=en.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Protocol Buffers" group.
> To post to this group, send email to protobuf@googlegroups.com.
> To unsubscribe from this group, send email to
> protobuf+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/protobuf?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To post to this group, send email to protobuf@googlegroups.com.
To unsubscribe from this group, send email to 
protobuf+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/protobuf?hl=en.

[protobuf] Re: self including message array

2011-04-01 Thread zad 
Ok I'll do, I  asked to be sure if a recursive definition was
"syntactically" correct.
Can you please check if there is a test case or an example?

On Apr 1, 4:44 pm, Jason Hsueh  wrote:
> You appear to be using a third party implementation for pure C. You'll have
> to check with the author of the implementation.
>
>
>
>
>
>
>
> On Fri, Apr 1, 2011 at 7:25 AM, zad  wrote:
> >  message resource_info {
> >        optional string device_name=18;
> >        optional Res_type res_type=19 [default=RAW];
> >        repeated resource_info resources=2;
> > }
>
> > the above message generates the following .h
>
> > /*! \file deviceManager_hint.h
> >  *  \brief message hints
> >  */
>
> > /*--
> >  * Generated 2011-04-01 15:14:14 +0100
> >  *           by protoc99 version 0.17
> >  * DO NOT EDIT! See "man protoc99" for details.
> >  *
> >  *--
> >  */
>
> > #ifndef _CIDL_DEVICEMANAGER_HINT_H
> > #define _CIDL_DEVICEMANAGER_HINT_H
>
> > #include 
>
> > enum {
> >  cidl_resource_info_size_hint = 0
> >    + PROTOC99_TAG_TYPE_SIZE(1) + PROTOC99_MAX_VAR32_SIZE +
> > PROTOC99_DEFAULT_STRING_LENGTH /* resource_info::device_name */
> >    + PROTOC99_TAG_TYPE_SIZE(2) + PROTOC99_MAX_VAR32_SIZE /*
> > resource_info::res_type */
> >    + (PROTOC99_TAG_TYPE_SIZE(3) + PROTOC99_MAX_VAR32_SIZE +
> > cidl_resource_info_size_hint) * PROTOC99_DEFAULT_ARRAY_COUNT /*
> > resource_info::resu
> >  cidl_device_list_size_hint = 0
> >    + PROTOC99_TAG_TYPE_SIZE(1) + PROTOC99_MAX_VAR32_SIZE /*
> > device_list::found_dev */
> >    + (PROTOC99_TAG_TYPE_SIZE(2) + PROTOC99_MAX_VAR32_SIZE +
> > cidl_resource_info_size_hint) * PROTOC99_DEFAULT_ARRAY_COUNT /*
> > device_list::resour
> >  cidl_get_device_info_size_hint = 0
> >    + PROTOC99_TAG_TYPE_SIZE(1) + PROTOC99_MAX_BOOL_SIZE /*
> > get_device_info::result */,
> >  cidl_device_info_registered_size_hint = 0,
> >  cidl_device_info_unregistered_size_hint = 0,
>
> > };
>
> > #endif /* _CIDL_DEVICEMANAGER_HINT_H */
>
> > And during gcc build I got an "/cidl_deviceManager_hint.h:25: error:
> > 'cidl_resource_info_size_hint' undeclared here (not in a function)"
> > error from the compiler.
>
> > On Apr 1, 2:05 am, Jason Hsueh  wrote:
> > > Recursive definitions should work, though I'm not sure we have a test
> > case
> > > to verify use in repeated fields. I know there is one for optional
> > messages.
> > > What result did you get?
>
> > > On Tue, Mar 29, 2011 at 5:58 AM, zad  wrote:
> > > > Is it possible to have in a message declaration an array of the
> > > > declaring message?
> > > > Let me explain better:
> > > > I'm trying to achieve the following:
>
> > > > message resource_info {
> > > >        optional string device_name=18;
> > > >        optional Res_type res_type=19 [default=RAW];
> > > >        repeated resource_info resources=2;
> > > > }
>
> > > > I tried also with this:
> > > > message resource_info {
> > > >        optional string device_name=18;
> > > >        optional Res_type res_type=19 [default=RAW];
> > > >        extensions 2 to 3;
> > > > }
> > > > extend resource_info{
> > > >        repeated resource_info resources=2;
> > > > }
>
> > > > --
> > > > You received this message because you are subscribed to the Google
> > Groups
> > > > "Protocol Buffers" group.
> > > > To post to this group, send email to protobuf@googlegroups.com.
> > > > To unsubscribe from this group, send email to
> > > > protobuf+unsubscr...@googlegroups.com.
> > > > For more options, visit this group at
> > > >http://groups.google.com/group/protobuf?hl=en.
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Protocol Buffers" group.
> > To post to this group, send email to protobuf@googlegroups.com.
> > To unsubscribe from this group, send email to
> > protobuf+unsubscr...@googlegroups.com.
> > For more options, visit this group at
> >http://groups.google.com/group/protobuf?hl=en.

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To post to this group, send email to protobuf@googlegroups.com.
To unsubscribe from this group, send email to 
protobuf+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/protobuf?hl=en.

[protobuf] Re: self including message array

2011-04-01 Thread zad 
 message resource_info {
optional string device_name=18;
optional Res_type res_type=19 [default=RAW];
repeated resource_info resources=2;
}

the above message generates the following .h

/*! \file deviceManager_hint.h
 *  \brief message hints
 */

/*--
 * Generated 2011-04-01 15:14:14 +0100
 *   by protoc99 version 0.17
 * DO NOT EDIT! See "man protoc99" for details.
 *
 *--
 */

#ifndef _CIDL_DEVICEMANAGER_HINT_H
#define _CIDL_DEVICEMANAGER_HINT_H

#include 

enum {
  cidl_resource_info_size_hint = 0
+ PROTOC99_TAG_TYPE_SIZE(1) + PROTOC99_MAX_VAR32_SIZE +
PROTOC99_DEFAULT_STRING_LENGTH /* resource_info::device_name */
+ PROTOC99_TAG_TYPE_SIZE(2) + PROTOC99_MAX_VAR32_SIZE /*
resource_info::res_type */
+ (PROTOC99_TAG_TYPE_SIZE(3) + PROTOC99_MAX_VAR32_SIZE +
cidl_resource_info_size_hint) * PROTOC99_DEFAULT_ARRAY_COUNT /*
resource_info::resu
  cidl_device_list_size_hint = 0
+ PROTOC99_TAG_TYPE_SIZE(1) + PROTOC99_MAX_VAR32_SIZE /*
device_list::found_dev */
+ (PROTOC99_TAG_TYPE_SIZE(2) + PROTOC99_MAX_VAR32_SIZE +
cidl_resource_info_size_hint) * PROTOC99_DEFAULT_ARRAY_COUNT /*
device_list::resour
  cidl_get_device_info_size_hint = 0
+ PROTOC99_TAG_TYPE_SIZE(1) + PROTOC99_MAX_BOOL_SIZE /*
get_device_info::result */,
  cidl_device_info_registered_size_hint = 0,
  cidl_device_info_unregistered_size_hint = 0,

};

#endif /* _CIDL_DEVICEMANAGER_HINT_H */

And during gcc build I got an "/cidl_deviceManager_hint.h:25: error:
'cidl_resource_info_size_hint' undeclared here (not in a function)"
error from the compiler.

On Apr 1, 2:05 am, Jason Hsueh  wrote:
> Recursive definitions should work, though I'm not sure we have a test case
> to verify use in repeated fields. I know there is one for optional messages.
> What result did you get?
>
>
>
>
>
>
>
> On Tue, Mar 29, 2011 at 5:58 AM, zad  wrote:
> > Is it possible to have in a message declaration an array of the
> > declaring message?
> > Let me explain better:
> > I'm trying to achieve the following:
>
> > message resource_info {
> >        optional string device_name=18;
> >        optional Res_type res_type=19 [default=RAW];
> >        repeated resource_info resources=2;
> > }
>
> > I tried also with this:
> > message resource_info {
> >        optional string device_name=18;
> >        optional Res_type res_type=19 [default=RAW];
> >        extensions 2 to 3;
> > }
> > extend resource_info{
> >        repeated resource_info resources=2;
> > }
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Protocol Buffers" group.
> > To post to this group, send email to protobuf@googlegroups.com.
> > To unsubscribe from this group, send email to
> > protobuf+unsubscr...@googlegroups.com.
> > For more options, visit this group at
> >http://groups.google.com/group/protobuf?hl=en.

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To post to this group, send email to protobuf@googlegroups.com.
To unsubscribe from this group, send email to 
protobuf+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/protobuf?hl=en.

[protobuf] Re: self including message array

2011-04-01 Thread zad 
 message resource_info {
optional string device_name=18;
optional Res_type res_type=19 [default=RAW];
repeated resource_info resources=2;
}
the above message generate the following .h

/*! \file deviceManager_hint.h
 *  \brief message hints
 */

/*--
 * Generated 2011-04-01 15:14:14 +0100
 *   by protoc99 version 0.17
 * DO NOT EDIT! See "man protoc99" for details.
 *
 *--
 */

#ifndef _CIDL_DEVICEMANAGER_HINT_H
#define _CIDL_DEVICEMANAGER_HINT_H

#include 

enum {
  cidl_resource_info_size_hint = 0
+ PROTOC99_TAG_TYPE_SIZE(1) + PROTOC99_MAX_VAR32_SIZE +
PROTOC99_DEFAULT_STRING_LENGTH /* resource_info::device_name */
+ PROTOC99_TAG_TYPE_SIZE(2) + PROTOC99_MAX_VAR32_SIZE /*
resource_info::res_type */
+ (PROTOC99_TAG_TYPE_SIZE(3) + PROTOC99_MAX_VAR32_SIZE +
cidl_resource_info_size_hint) * PROTOC99_DEFAULT_ARRAY_COUNT /*
resource_info::resu
  cidl_device_list_size_hint = 0
+ PROTOC99_TAG_TYPE_SIZE(1) + PROTOC99_MAX_VAR32_SIZE /*
device_list::found_dev */
+ (PROTOC99_TAG_TYPE_SIZE(2) + PROTOC99_MAX_VAR32_SIZE +
cidl_resource_info_size_hint) * PROTOC99_DEFAULT_ARRAY_COUNT /*
device_list::resour
  cidl_get_device_info_size_hint = 0
+ PROTOC99_TAG_TYPE_SIZE(1) + PROTOC99_MAX_BOOL_SIZE /*
get_device_info::result */,
  cidl_device_info_registered_size_hint = 0,
  cidl_device_info_unregistered_size_hint = 0,
};

#endif /* _CIDL_DEVICEMANAGER_HINT_H */

And during build I got an "/cidl_deviceManager_hint.h:25: error:
'cidl_resource_info_size_hint' undeclared here (not in a function)"
error from the compiler.


On Apr 1, 2:05 am, Jason Hsueh  wrote:
> Recursive definitions should work, though I'm not sure we have a test case
> to verify use in repeated fields. I know there is one for optional messages.
> What result did you get?
>
>
>
>
>
>
>
> On Tue, Mar 29, 2011 at 5:58 AM, zad  wrote:
> > Is it possible to have in a message declaration an array of the
> > declaring message?
> > Let me explain better:
> > I'm trying to achieve the following:
>
> > message resource_info {
> >        optional string device_name=18;
> >        optional Res_type res_type=19 [default=RAW];
> >        repeated resource_info resources=2;
> > }
>
> > I tried also with this:
> > message resource_info {
> >        optional string device_name=18;
> >        optional Res_type res_type=19 [default=RAW];
> >        extensions 2 to 3;
> > }
> > extend resource_info{
> >        repeated resource_info resources=2;
> > }
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Protocol Buffers" group.
> > To post to this group, send email to protobuf@googlegroups.com.
> > To unsubscribe from this group, send email to
> > protobuf+unsubscr...@googlegroups.com.
> > For more options, visit this group at
> >http://groups.google.com/group/protobuf?hl=en.

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To post to this group, send email to protobuf@googlegroups.com.
To unsubscribe from this group, send email to 
protobuf+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/protobuf?hl=en.

Re: [protobuf] on the wire sizes

2011-04-01 Thread Evan Jones 

On Apr 1, 2011, at 6:54 , AdrianPilko wrote:

What is the [best] way to determine the on the wire size?


You probably want msg.ByteSize() in C++, msg.getSerializedSize() in  
Java.


Evan

--
http://evanjones.ca/

--
You received this message because you are subscribed to the Google Groups "Protocol 
Buffers" group.
To post to this group, send email to protobuf@googlegroups.com.
To unsubscribe from this group, send email to 
protobuf+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/protobuf?hl=en.

[protobuf] Re: Protobuf in JAX-WS

2011-04-01 Thread Canggih 
Or, maybe can I handle request and read the callback without using JAX
WS (without java.xml.ws library)?

On Apr 1, 10:04 am, Ben Wright  wrote:
> Unfortunately JAX-WS (Java API for XML Web Services) only works
> directly with XML (anyone feel free to correct me if I'm
> misinformed in this regard as I've never fully explored using JAX-WS
> without XML)
>
> You have a couple of options though...
>
> If you want to stick with XML based web services you can go with using
> Base64 encoded protocol buffer message(s) in appropriate XML fields.
> Likewise you can return data this way.  The drawbacks of this are that
> you're essentially throwing away a lot of the good that comes from web
> services being well defined in terms of argument and return data
> types. (Base64 is an encoding scheme for putting binary data in "human
> readable" data streams such as XML by only using displayable
> characters... encoding suffers a 4/3 size penalty as it takes four 6-
> bit chars to encode three 8-bit bytes)
>
> If you're more flexible you can implement a non-XML based web service
> using a RESTful model, or thin HTTP requests, to post and get protocol
> buffers directly as raw bytes.  There are also some "remoting"
> services built on top of protocol buffers that act much like web
> services.  I have not used any of them so I'll leave it to someone
> more versed in those to speak to them.
>
> If you want more info you can ask more questions or do a search on
> RESTful web services (and yes JAX-WS supports "RESTful" but still
> using XML...)
>
> Best of luck,
> Ben Wright
>
> On Mar 31, 10:38 pm, Canggih PW  wrote:
>
>
>
>
>
>
>
> > hi,
>
> > Sorry, i'm new in Java.
>
> > Currently, i make a web service using python (for server) and java (for 
> > client).
> > Client-Server can updates data synchronously, i'm using long polling 
> > method. All
> > i know about how to implement those thing is using JAX WS, to send request 
> > and
> > read the callback response. But, JAX WS using XML. How can i using protobuf 
> > in
> > JAX-WS, or there are any other library in java that can do it?
>
> > Thanks in advance
> > Canggih

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To post to this group, send email to protobuf@googlegroups.com.
To unsubscribe from this group, send email to 
protobuf+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/protobuf?hl=en.

[protobuf] Re: Protobuf in JAX-WS

2011-04-01 Thread Canggih 
thanks.
Actually, i'm using Restful web services. But, i'm confuse, how to use
it for long polling method. I have search it, but the result is using
JAX WS to handle the request and get callback response.
is there a way to do it in pure protobuf? Maybe using another library?

Thanks in advance
Canggih

On Apr 1, 10:04 am, Ben Wright  wrote:
> Unfortunately JAX-WS (Java API for XML Web Services) only works
> directly with XML (anyone feel free to correct me if I'm
> misinformed in this regard as I've never fully explored using JAX-WS
> without XML)
>
> You have a couple of options though...
>
> If you want to stick with XML based web services you can go with using
> Base64 encoded protocol buffer message(s) in appropriate XML fields.
> Likewise you can return data this way.  The drawbacks of this are that
> you're essentially throwing away a lot of the good that comes from web
> services being well defined in terms of argument and return data
> types. (Base64 is an encoding scheme for putting binary data in "human
> readable" data streams such as XML by only using displayable
> characters... encoding suffers a 4/3 size penalty as it takes four 6-
> bit chars to encode three 8-bit bytes)
>
> If you're more flexible you can implement a non-XML based web service
> using a RESTful model, or thin HTTP requests, to post and get protocol
> buffers directly as raw bytes.  There are also some "remoting"
> services built on top of protocol buffers that act much like web
> services.  I have not used any of them so I'll leave it to someone
> more versed in those to speak to them.
>
> If you want more info you can ask more questions or do a search on
> RESTful web services (and yes JAX-WS supports "RESTful" but still
> using XML...)
>
> Best of luck,
> Ben Wright
>
> On Mar 31, 10:38 pm, Canggih PW  wrote:
>
>
>
>
>
>
>
> > hi,
>
> > Sorry, i'm new in Java.
>
> > Currently, i make a web service using python (for server) and java (for 
> > client).
> > Client-Server can updates data synchronously, i'm using long polling 
> > method. All
> > i know about how to implement those thing is using JAX WS, to send request 
> > and
> > read the callback response. But, JAX WS using XML. How can i using protobuf 
> > in
> > JAX-WS, or there are any other library in java that can do it?
>
> > Thanks in advance
> > Canggih

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To post to this group, send email to protobuf@googlegroups.com.
To unsubscribe from this group, send email to 
protobuf+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/protobuf?hl=en.

[protobuf] on the wire sizes

2011-04-01 Thread AdrianPilko 
I notice from:

http://code.google.com/apis/protocolbuffers/docs/encoding.html

There is a description of the size of output messages "on the wire"
and presumably this could be used to manually calculate the size of a
message. so far so good for simple messages...

There are functions in the compiled protobuf files called
SerializeWithCachedSizesToArray() but these don't return the size of
the data just a uint8* to the data. We've also noticed functions
called int GetCachedSize().

What is the [best] way to determine the on the wire size?

Thankyou
Adrian

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To post to this group, send email to protobuf@googlegroups.com.
To unsubscribe from this group, send email to 
protobuf+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/protobuf?hl=en.