From: "Robert Ramey" <ramey@rrsd.com> To: <boost@lists.boost.org> 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.
I believe you could easily achive what you want to accomplish by serializaiton to a memory buffer (e.g string_stream) and transmitting
If you mean here that it would be unwise to couple the serialization to TCP then yes, I understand that. 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.