Hi,
i don't know if this is the appropriate place to ask this, but i did
not see any mailing list/forum/irc channel or similar thing on the
protobuf-c project page so i thought i'd ask here. I realize that this
is a very long email, so i am extra grateful to anyone who actually
reads it. I
I still think that this doesn't belong in the scope of protocol buffers, but
rather some higher-level utility library.
That said, what does your proposal offer over the
writeDelimited/parseDelimited methods added to the Java runtime in 2.1.0?
(Still need to add them to C++ and Python...)
On Tue,
On Tue, Jun 9, 2009 at 12:11 AM, Jon Skeet sk...@pobox.com wrote:
On Jun 9, 1:42 am, Kenton Varda ken...@google.com wrote:
In the next version there will be a third option: LITE_RUNTIME. This
variant is like optimizing for speed but will generate code that only
depends on a lighter
On Jun 9, 8:28 pm, Kenton Varda ken...@google.com wrote:
I still think that this doesn't belong in the scope of protocol buffers, but
rather some higher-level utility library.
Doesn't that make writeDelimited/parseDelimited somewhat less useful
then? You can write as many messages as you like
On Jun 9, 8:31 pm, Kenton Varda ken...@google.com wrote:
Is the plan that the reflection parts of the API will just throw
exceptions, or will there be non-reflection interfaces which are
implemented by these generated classes?
There will be a new interface called MessageLite which is a
Ah, I see. How about if we just extend parseDelimited() to return null at
EOF?
On Tue, Jun 9, 2009 at 12:36 PM, Jon Skeet sk...@pobox.com wrote:
On Jun 9, 8:28 pm, Kenton Varda ken...@google.com wrote:
I still think that this doesn't belong in the scope of protocol buffers,
but
rather
On Jun 10, 12:01 am, Kenton Varda ken...@google.com wrote:
Ah, I see. How about if we just extend parseDelimited() to return null at
EOF?
Absolutely - the problem is that I *suspect* that means the
mergeFromDelimited method will need to break the normal builder
convention of returning itself,
