From: Robert Ramey (ramey_at_[hidden])
Date: 2004-12-29 00:02:37
Scott Woods wrote:
> Hi,
>
> I have been doing a lot of async messaging over TCP and have looked
> through the serialization library in the hope that it could be
> applied to the task.
>
> If the serialized representation of an object has an unknown length
> then its reasonable to say that we dont know how many network
> blocks will be consumed, i.e. the receiver may read 1 or more blocks
> before completion. We also cant guarantee that the flurry of recv's
> that might result from an FD_READ (sorry to those non-Windows folks),
> will neatly terminate on an object boundary.
>
> 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.
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.
Robert Ramey
> ps:
> Its a thoroughly amazing library.
>
Have you concluded this from actually using the library or from just reading
the documentation?
Robert Ramey