Hello all,
This is my first time using PB, and I'm already stuck. On something
that should be simple too... Oy!
Essentially, I send a message within a wrapper that indicates the
message type. From what I saw on the forums, that's the common
practice. I'm able to create the message, but nothing g
I noticed in my test app, and then in the ProtoBuf source, that the
serialization of Nullable properties ignores the IsRequired
parameter. So that if a Nullable property is null, it does not get
serialized. Is there a reason for this? This is currently causing us
problems in our code.
Bryan
-
I'm completely new to PB, but thought I would take a look as I am
currently writing some custom marshalling/serialising code for
messages and PB appears like a decent fit. My use-case is quite
particular and I am having to watch memory usage and Java JVM
behaviour very closely . I am trying to a
parseFrom() reads and parses the entire stream, so it won't stop reading
until it reaches EOF. If you don't want to close the socket on the sending
end, then you should write the size of the message first, then the contents.
Then, on the receiving end, you'll need to read that size first, then us
I'm guessing this question is about protobuf-net, specifically? (Not sure
since I haven't used it myself.)
On Thu, Mar 12, 2009 at 5:23 AM, Bryan wrote:
>
> I noticed in my test app, and then in the ProtoBuf source, that the
> serialization of Nullable properties ignores the IsRequired
> parame
I should have specified that this is in protobuf-net .Net
implementation.
Also, from looking more at the code, it appears that any reference
types ignore the IsRequired parameter. Therefore any class or array
that is null will not be serialized and any array or list that is
empty will not be ser
It's not possible to set values by writing directly into a byte array since
the size of a value depends on its contents. For example, integers are
encoded using the varint encoding which uses fewer bytes for smaller
numbers. So, if the value of a particular int32 field is 1, and then you
set it t
Hi Brian. There is a pretty fundamental reason for this: the binary
wire format doesn't have a meaningful way of expressing null. Under
the default Nullable usage, it treats the null value as "do not
serialize" (although there are other ways of expressing this too). I
will get this written up on a
I should add; re Nullable - if the intent is to support a value
with a non-null default, and to know whether it has a *specified*
value (rather than the default value), there is a pattern for this
(compatible also with XmlSerializer etc); if you use protogen, it will
emit the correct C#. I can dig
On Feb 17, 2:10 pm, Petar Petrov wrote:
> I've done some prototypes that show it's a good idea, but not a full
> implementation yet.
(Sorry for catching up with this thread a bit late.)
It seems like there's decent interest in C Python implementation. Now
if there were something to patch and im
Ok, I can do that.
But that comes accross as a twisted way of doing things, especially
when both ends know the message format and should know when its end
has been reached...
Is there any solution that is a bit more elegant?
On Mar 12, 10:12 pm, Kenton Varda wrote:
> parseFrom() reads and parses
On Thu, Mar 12, 2009 at 8:54 PM, marc-andre
wrote:
>
> Ok, I can do that.
> But that comes accross as a twisted way of doing things, especially
> when both ends know the message format and should know when its end
> has been reached...
No, the receiving end does *not* know when the end has been
12 matches
Mail list logo
