On Monday, 1 April 2013 at 21:11:57 UTC, Matt Soucy wrote:
And therefore, it supports arrays just fine (as repeated fields). Yes. That last sentence was poorly-worded, and should have said "you'd just end up with the un'packed' data with an extra header."
It says repeated messages should be merged which results in one message, not an array of messages. So from several repeated messages you get one as if they formed contiguous soup of fields which got parsed as one message: e.g. scalar fields of the resulting message take their last seen values.
Unfortunately, I'm not particularly knowledgeable about networking, but that's not quite what I meant. I meant that the use case itself would result in sending individual Result messages one at a time, since packing (even if it were valid) wouldn't be useful and would require getting all of the Results at once. You would just leave off the "packed" attribute.
As you said, there's no way to tell where one message ends and next begins. If you send them one or two at a time, they end up as a contiguous stream of bytes. If one is to delimit messages, he should define a container format as an extension on top of PB with additional semantics for representation of arrays, which results in another protocol. And even if you define such protocol, there's still no way to have array fields in PB messages (arrays of non-trivial types).
For example if you want to update students and departments with one method, the obvious choice is to pass it a dictionary of key-value pairs of new values for the object's attributes. How to do that?
