I'm working on one (of the many) J2ME ports, and I have some questions
about the implementation of the Java version:
1. CodedInputStream uses an internal byte[] buffer, instead of
directly using the InputStream. Does this give significant performance
improvements?
2. Messages implement the
On Aug 5, 2:12 pm, Evan Jones ev...@mit.edu wrote:
On Aug 5, 2010, at 7:06 , Ralf wrote:
1. CodedInputStream uses an internal byte[] buffer, instead of
directly using the InputStream. Does this give significant performance
improvements?
It does appear to, actually. I tried it with
For my J2ME port, I used the compiler plugin system introduced in
protobuf 2.3.0. It really simplified my work - the entire code
generator is only about 200 lines of Python code, and another 160
lines for the template (see
http://github.com/ponderingpanda/protobuf-j2me/tree/master/generator/).
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
Let's say you have a message (A) that has an extension field (F) that
is a message (B) that no fields. To set F on an instance of A in c++
you would call instance.MutableExtension(F). It appears the python
analog is something like:
a = A()
a.Extensions[F]._Modified()
Is this correct?
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
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
On Thu, Aug 5, 2010 at 4:09 PM, Ralf Kistner ralf.kist...@gmail.com wrote:
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
Groups are primarily deprecated because it used to be the case that groups
could not be reused in other types. Now groups can be reused, but other
messages must use the length-delimited format, rather than the group format.
In theory, the fact that groups do not require a length prefix makes them
