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 -~----------~----~----~----~------~----~------~--~---
