Request for review - std.serialization (orange)

[Kagamin]

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?