Another big advantage of writing the size first is that you can potentially
write parsers which skip over sub-messages quickly, and perhaps parse them
lazily. Currently the Google-provided implementations do not implement
this, but there are some third-party implementations that use lazy parsing.
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
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
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
