Hi Jon,

   So we both agree there should be a way to delimit messages in a
stream.  In your stream is sounds like there is

(A) The field type + wire type, which here is 1*8+2 = 10 written as a
varint the stream in a single byte since it is <= 127.
(B) The length of the message as a varint
(C) The message body

And in you C# code reading this one message at a time is support by a
special API command.

So this is very close to my proposal (which is in my Haskell code).  I
do not have (A) but I do have (B) and (C).

Does you C# API allow (in some way) the user to read (B)+(C) as a
single message from the stream?  Does it allow the user to write such
a thing?

In my Haskell code could make a wrapper message and an extension key
to allow it to write (A)+(B)+(C).  And this could read all the
messages in the stream.  But I lack a special API command to read a
single such message from the stream.  The (A)+(B)+(C)+(A)+(B)+(C)+...
is wire compatible with such a repeated message but your reading API
is special.  Since a special API is needed I chose (B)+(C)+(B)+(C)+(B)+
(C)+... and if the user wants them all then the user has to loop over
this collecting a single message at a time.

Where is your C# API documented, in case I wish to support your (A)+(B)
+(C) single message reading behavior?

As for mixing message types in a stream, I think the ability to have a
heterogeneous stream (or a stream embedded in another protocol) will
be needed by someone.  So the main question, like with delimited
messages, is whether each application invents its own technique.  One
could use a serialized DescriptorProto Message to announce the type
before each message.  All the fields are optional, so the herald
message needs only to set the name field.  Or perhaps serialize a
(nearly empty) FileDescriptorProto with the (nearly empty) embedded
DescriptorProto would make it more clear which object is being
serialized.  But this is getting me off track.

The main point of the message is to see if the C# and Haskell code can
agree on common APIs and encodings for delimited messages in a
continuous stream.

Here is a generalization question:  If we adopt a way to read (A)+(B)+
(C) then will the generalize beyond message types to groups or to
basic types like Double ? What happens in the special API in your C#
code if one tries to do this or encounters such a stream?  My Haskell
API only works with messages.  I have not exposed a friendly way to
encode or decode anything else.


You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To post to this group, send email to protobuf@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 

Reply via email to