Re: [boost] Re: Re: Serialization and async messaging

From: Scott Woods (scottw_at_[hidden])
Date: 2004-12-29 16:08:00

----- Original Message ----- 
From: "Robert Ramey" <ramey_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Thursday, December 30, 2004 8:34 AM
Subject: [boost] Re: Re: Serialization and async messaging

> > On the transmit side your suggestion seems completely workable. On the
> > receive side you have the problem (i.e. in async environment) of not
> > knowing whether the data available at any point will be enough to
> > complete the
> > call to operator>>. You cant make a call that is going to "block" in
> > some way.
> >
> 
> 
> I have to say I just can't see this understand this.  I envision such a
> process as functioning in the following way.
> 
> transmitting program
> ==============
> serialize to a string.  we now have its total length.
> transmit a string using what ever method syncronous/asyncronous whatever.
> 
> recieving program
> ============
> retrieve a string - using what ever method async, sync or whatever.
> when a complete string is retrieved/reassembled or whatever
> de-serialize to the original structure.
> 
> Honestly, I can't see any thing about this that is less than optimal.
> 

Aha. After Gennadiy's version of this I can now see it for what it is.

Yes, the simple response is that this will work. A pedantic response
is that it feels like duplication; why implement another layer (the
envelopes) just to detect completion of objects, ignoring the
potential in the existing serialization format (e.g. XML). A more
useful response would point out the higher memory requirements,
two scanning phases and increased incidence of copying.

A comparative analysis is probably impossible. Given opportunity
I would probably explore the non-envelope version buts thats
curiosity and the sex appeal of "doing tricky stuff that results in
less lines".

Commercially the envelope version seems like a winner.

Thanks.