[Portland] Transport mechanism

[nf2]

Lubos Lunak wrote:
>  
>
> - Wire format: As already said above, it can be pretty simple. Message can be 
> { int id; int seq; int length; char rest[ length ]; }. The actual body can be 
> mostly marshalled as memcpy( buf, &foo, sizeof( foo )), variable length stuff 
> like strings can be again { int length; char data[ length ]; }, arrays 
> similarly, maps can be { int count; X key1, Y value1, X key2, Y 
> value2, .... }. String encoding utf8.
>   
Yes. For the types you are currently using (int, bool, string, 
stringlist) i think this model will suffice.

Nevertheless LVariant has the following advantages:

+ It can send key/value maps containing values of different types. Even 
nested containers. That's where the type-information is necessary on the 
wire.
+ The binary data is easier to debug (becauce of the type-information)
+ The LVariant wire protocol is easy to standardize.
+ Serialization/Unserialization is quite convenient, cause it's running 
recursively.

The disadvantage is that it's slower, but i guess that doesn't matter 
compared to round-trip times (delay of context switching)....

Just an example how to serizalize an array of two strings and one int 
into a buffer:

LVariant * lvaOut = lva_new(LVA_ARRAY,
          lva_new(LVA_STRING, url),
          lva_new(LVA_STRING, localfile),
          lva_new(LVA_INT, someInt),
          LVA_TERM);

int l=lva_calc_serialized_size(lvaOut);
char * buf = malloc(l);
lva_serialize(lvaOut, buf, l);


>  The int seq is there to handle parallel operations, e.g. for two download 
> operations one needs to be able to tell which of the operations actually 
> finished.
>
>   
Hmm. Or just open another connection for parallel operations...

Regards,
Norbert