Hi Jon,
>> 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.
>>     
>
> The benefit of the A+B+C format is that it's not really coming up with
> a new encoding, so much as just a new way of reading repeated "field
> 1" messages. The whole data still ends up being a valid message of the
> appropriate type.
>
> But yes, I agree that a common API would be good to decide.
You are right, the key API innovation in your system are the "read/write 
one field only" commands.
You fix the field number and wire encoding to be field number 1 and 
length delimited (for messages).

Would a good choice for a new API by a generalization of those commands?
Hmmm...you also write:

> I think it's best to concentrate on the simple requirement first, and
> not guess too much about what would be needed. Use cases for an
> homogenous stream are easy to come up with - the simplest being
> logging, for example.

Is writing and reading a field at a time an overly complicated mechanism?

You fixed field# only sinks and sources the message object.  A more general API 
would be able to set the field# and return the field#.  A slight generalization 
would work on strings and bytes since their wire encoding is identical to 
messages.  A full generalization would work on all allowed field types.

These are each about 2 or 3 lines of Haskell (plus documentation), so I will 
probably add them all.

And it seems that I am coming around to your view that the A+B+C is better than 
B+C encoding.

Cheers,
  Chris



--~--~---------~--~----~------------~-------~--~----~
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 
http://groups.google.com/group/protobuf?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to