RE: [protobuf] Additional data types
Date and decimal types are ubiquitous and in wide use. Language specific bindings could easily be created - this is exactly what we do in some other open source projects that I contribute to. The way I envision it, protocol buffers would provide 'date' and 'decimal' types - protoc compiler would compile these into language specific data types (e.g. java.util.Date for Java and DateTime for C#). Jawaid Hakim Chief Technology Officer CodeStreet LLC 646 442 2804 www.codestreet.com -Original Message- From: Alexandru Turc [mailto:alex.t...@gmail.com] Sent: Wednesday, April 04, 2012 5:09 PM To: Jawaid Hakim Cc: Protocol Buffers Subject: Re: [protobuf] Additional data types proto files are mapped to many languages, Date and BigDecimal are java specific. On Apr 4, 2012, at 9:37 AM, jhakim wrote: Any plans to provide out-of-the-box for commonly used data types such as Date (encoded as String) and BigDecimal/BigInteger types? Seems this would be of interest to a lot of users. -- 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] Additional data types
You are correct to point out the complications of dealing with complex data types. All the more reason why it would be great to not have the developer community keep re-inventing the wheel. But I understand why this is not on the radar map of the proto buffer team. My group builds applications using use multiple languages, including Java and C#, so a simple int64 for date representation does not work. Jawaid Hakim Chief Technology Officer CodeStreet LLC 646 442 2804 www.codestreet.com -Original Message- From: Alexandru Turc [mailto:alex.t...@gmail.com] Sent: Wednesday, April 04, 2012 5:42 PM To: Jawaid Hakim Cc: Protocol Buffers Subject: Re: [protobuf] Additional data types What would be the mapping for C or C++? I think there is an advantage of keeping the set of data types very limited, to primitive values which can be easily mapped to multiple languages. Otherwise things can get complicated. Let's take date as an example. It's representation depends on the calendar used. Gregorian is very common, but other systems are used as well (Japanese, Buddhist). Also, when your are saying Date are you implying to have just day accuracy or get to hour, minute, second, millisecond etc.. WIth all these a string representation can get quite long which is against protocol buffer's goal to keep the serialized size small. However, most likely in particular applications based on protocol buffers most likely you do not need all the flexibility and you can have some conventions: only gregorian calendar is used and we only need day accuracy. With these probably you can represent a date in a simple int32 as a value relative to an absolute date. Is more compact and much faster to process. If you are only using java then you can stick with the Java's convention of representing time as number of milliseconds since January 1'st, 1970 UTC and use a int64 for this - reduces the chance of making mistakes. On Apr 4, 2012, at 11:21 AM, Jawaid Hakim wrote: Date and decimal types are ubiquitous and in wide use. Language specific bindings could easily be created - this is exactly what we do in some other open source projects that I contribute to. The way I envision it, protocol buffers would provide 'date' and 'decimal' types - protoc compiler would compile these into language specific data types (e.g. java.util.Date for Java and DateTime for C#). Jawaid Hakim Chief Technology Officer CodeStreet LLC 646 442 2804 www.codestreet.com -Original Message- From: Alexandru Turc [mailto:alex.t...@gmail.com] Sent: Wednesday, April 04, 2012 5:09 PM To: Jawaid Hakim Cc: Protocol Buffers Subject: Re: [protobuf] Additional data types proto files are mapped to many languages, Date and BigDecimal are java specific. On Apr 4, 2012, at 9:37 AM, jhakim wrote: Any plans to provide out-of-the-box for commonly used data types such as Date (encoded as String) and BigDecimal/BigInteger types? Seems this would be of interest to a lot of users. -- 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] Additional data types
C# has a decimal type and Java has BigDecimal - 'decimal' seems like a generic data type name for Protocol Buffers. I hear you about making contributing a module; will see if that is possible. Jawaid Hakim Chief Technology Officer CodeStreet LLC 646 442 2804 www.codestreet.com -Original Message- From: Christopher Smith [mailto:cbsm...@gmail.com] Sent: Thursday, April 05, 2012 12:58 AM To: Jawaid Hakim Cc: Alexandru Turc; Protocol Buffers Subject: Re: [protobuf] Additional data types Nothing prevents you from making a module available for everyone's benefit. If it is broadly useful, it will undoubtedly be universally adopted. --Chris P.S.: What is a decimal type? On Apr 4, 2012, at 2:21 PM, Jawaid Hakim jawaid.ha...@codestreet.com wrote: Date and decimal types are ubiquitous and in wide use. Language specific bindings could easily be created - this is exactly what we do in some other open source projects that I contribute to. The way I envision it, protocol buffers would provide 'date' and 'decimal' types - protoc compiler would compile these into language specific data types (e.g. java.util.Date for Java and DateTime for C#). Jawaid Hakim Chief Technology Officer CodeStreet LLC 646 442 2804 www.codestreet.com -Original Message- From: Alexandru Turc [mailto:alex.t...@gmail.com] Sent: Wednesday, April 04, 2012 5:09 PM To: Jawaid Hakim Cc: Protocol Buffers Subject: Re: [protobuf] Additional data types proto files are mapped to many languages, Date and BigDecimal are java specific. On Apr 4, 2012, at 9:37 AM, jhakim wrote: Any plans to provide out-of-the-box for commonly used data types such as Date (encoded as String) and BigDecimal/BigInteger types? Seems this would be of interest to a lot of users. -- 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] Generate Protobuf message definitions from (Java) source
Hi, Our platform inter-operates between .NET (frontend) and Java (backend), communication channel is pub/sub (JMS), and serialization is done using a reflection based framework. The allows the frontend and backend development teams to just 'drop' domain specific objects into message containers - the underlying framework does the rest. Development teams don't need to code up separate DTOs. Looking at Protobuf as a potential replacement for the custom serialization framework. However, given the large body of existing business objects it would be a huge effort to write Protobuf message definitions manually. Also we'd like to have the developers focus on domain objects and not worry (too much) about Protobuf message definitions. Is there a battle tested conversion tool/utility that generates Protobuf message from Java source? Such a tool could be part of the build pipeline and free developers from having to keep Protobuf messages refs in sync with domain specific objects. Thanks! -- You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. To unsubscribe from this group and stop receiving emails from it, send an email to protobuf+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/protobuf/8372f62b-236f-423d-b09d-6ee345f42b31o%40googlegroups.com.
[protobuf] Re: Convert JAVA object to proto file
I'm very interested in this as well. On Friday, April 17, 2020 at 6:59:45 AM UTC-4, Sanjay Hingu wrote: > > Hello Everyone, > Is there any option to convert JAVA objects to proto file? > Can i have one proto Message extend another proto Message like we do it in > JAVA? > > > Regards, > Sanjay > -- You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. To unsubscribe from this group and stop receiving emails from it, send an email to protobuf+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/protobuf/69c07a6a-e9fc-4b2f-923e-280d6c537c01o%40googlegroups.com.
