Igor, I started the port February this year, as far as I know only two other ports existed - neither of met my requirements (nested messages).
I saw your port today for the first time. I still have to investigate it, but I have a feeling the two ports have different priorities. >From inspection your port at http://code.google.com/p/protobuf-j2me/ aims to be feature-complete, and close to the official Java implementation. My port at http://github.com/ponderingpanda/protobuf-j2me started from one of the other J2ME ports, and I added support for features I needed. The big difference is that it aims to keep the generated code as small as possible. I'm working on projects with more than 40 messages, so the generated code size is important to me. To achieve this I sacrificed some of the features, such as immutable/ready-only messages. However, the port is slowly moving closer back to the official Java port. Overall the basic runtime library (CodedInputStream, etc) is very similar in our two ports and the official implementation. The biggest difference is in the generated messages. I'm open to the possibility of merging the two ports - users should not have to choose between four J2ME ports. However, the fundamental differences in the generated messages might make this unpractical. Ralf On Thu, Aug 5, 2010 at 8:27 PM, Igor Gatis <igorga...@gmail.com> wrote: > Hey Ralf, just out of curiosity: what motived you to create your own j2me > port? > The reason I'm asking that is because I did wrote my one > (http://code.google.com/p/protobuf-j2me/)too but it was just due the fact, > by the time published mine, none of the available j2me implementations were > either complete, focused on code size nor 100% compatibility with all > protobuf 2.3.0 features. I'm just wondering what made you discard them too > (including mine). > > On Thu, Aug 5, 2010 at 10:53 AM, Evan Jones <ev...@mit.edu> wrote: >> >> On Aug 5, 2010, at 9:16 , Ralf wrote: >>> >>> I might be mistaken, but didn't "groups" use this approach - use a >>> special tag to indicate the end of a message? As only tags are >>> checked, there is no need to escape any data. >> >> Good point, I forgot about groups. They definitely do use that approach. >> Maybe one of the Googlers on this list will have a better idea about why >> groups are now deprecated in favour of nested messages. >> >> >>> Anyway, I was referring more to the implementation. For example, we >>> could first serialize the message to a ByteArrayOutputStream, then >>> write the result and its size to the output. Obviously this approach >>> is much slower, but I was wondering if there were other similar >>> approaches. >> >> That's true, and would work. The other option would be to use fixed width >> integers for the lengths, so then you could "reserve" space in the buffer, >> serialize the message, then go back and fill in the length field. This would >> be an incompatible change to the serialization format, however. >> >> Evan >> >> -- >> Evan Jones >> 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 proto...@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 proto...@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.
