Re: [boost] Re: Serialization and async messaging

From: Scott Woods (scottw_at_[hidden])
Date: 2004-12-29 13:59:17

From: "Robert Ramey" <ramey_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Wednesday, December 29, 2004 6:02 PM
Subject: [boost] Re: Serialization and async messaging

<snip>

> > IMHO the input function (operator>>) needs to be "re-entrant" if
> > serialization can be used in an async environment. Repeated calls
> > should be perfectly acceptable. Ultimately it would return an
> > indication
> > that a complete object has indeed been loaded. Some "state" needs to
> > be held somewhere. My best guess is that this is not the case but I
> > cant
> > find anything conclusive (without wading deeper into code).
> >
> > Can anyone comment?
> >
>
> I'm not sure I'm understanding exactly what you want to do - but that
deters
> me not at all from making a comment.
>
> I envisioned the library would be useful for marshalling data accross
space
> (transmitting/recieving between programs) as well as across time
> (persistence - the most common application).  So I would be pleased to see
> someone apply it in this way.
>
> However, I don't think the concept of transmission protocal should be
mixed
> into the library - which is already very complex.

If you mean here that it would be unwise to couple the serialization to
TCP then yes, I understand that.

> I believe you could easily achive what you want to accomplish by
> serializaiton to a memory buffer (e.g string_stream) and transmitting
this.
> On the other end the inverse of this process would occur.

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.

> > ps:
> > Its a thoroughly amazing library.
> >
>
> Have you concluded this from actually using the library or from just
reading
> the documentation?
>

The documentation, the functionality that has been achieved and my
struggles to achieve less. I hadnt even considered trying to recover
objects including pointers to objects that...

I have done some analogous work in the area of async messaging, i.e.
lots of marshalling inside async frameworks. I have recently tried to
extend this to persistence (or serialization) as supporting two distinct
bodies of code seems ill-directed.

The option that I was exploring here was to apply your serialization
back the other way; to async messaging.

Cheers.