[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 compuware...@gmail.com 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 cangca...@gmail.com 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 compuware...@gmail.com 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 cangca...@gmail.com 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.



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: 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 protoc99_hint.h

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 jas...@google.com 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 emanuele.plac...@gmail.com 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 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 protoc99_hint.h

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 jas...@google.com 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 emanuele.plac...@gmail.com 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
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 jas...@google.com 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 emanuele.plac...@gmail.com 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 protoc99_hint.h

  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 jas...@google.com 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 emanuele.plac...@gmail.com 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.



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 emanuele.plac...@gmail.com 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 protoc99_hint.h

 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 jas...@google.com 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 emanuele.plac...@gmail.com 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] 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] 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 ahabco...@yahoo.co.uk 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] 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.



Re: [protobuf] Will protobuf support JSON?

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

 2011/4/1 ZHOU Xiaobo xb.z...@qq.com

 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.