Re: [boost] [async] messages threads and networks

Subject: Re: [boost] [async] messages threads and networks
From: Scott Woods (scott_at_[hidden])
Date: 2010-04-25 17:32:14

Hi Sohail,

>> Also, in some cases I had goals that were simply not included in Boost
>> implementations. Boost.Serialization does not have
>> runtime encoding selection.
>
> The polymorphic archives do allow this.

They assist you towards that goal. But considering the two libraries somehow
equivalent in this area would be misleading.

In the docs it describes the motivation/solution according to polymorphic
archives. It describes the construction of sets of archive implementations, 
e.g.
you can build an application with text and wide text or text and binary, 
etc.

It also shows the selection of a specific archive (e.g. text);

   boost::archive::polymorphic_text_oarchive oa(ss);
   boost::archive::polymorphic_oarchive & oa_interface = oa;
How does the user of the application or even the developer select a 
different
encoding? Given the example it would take a recompilation.

The Pact library selection is innately runtime strings;

   load( object, "file", "Neat Bytes" );

While changing the line above would also require a recompilation there is
an obvious potential to pass strings into an application from command line
arguments, environment variables or configuration data. The Pact library
implements a "codec_factory" that takes care of all of that. This might seem
trivial but there are pitfalls and some further issues.

It's not enough to say that Boost.Serialization has the potential to do 
something
similar (which is still unclear). Until it is a part of Boost.Serialization 
you cannot
rely on any /standard/ collection of encodings and /standard/ naming of 
encodings.
It would be interesting to get a survey of all uses of 
boost::archive::polymorphic.
I'm sure there will be a variety of deployments - different sets of 
archives, different
runtime selector types (enums, strings) and different values for those 
types. Now
imagine trying to get these deployments to agree to a Boost /standard/ and 
you
might see what I am trying to explain. Any software component developed in
Pact can use any encoding available at any site. All the I/O primitives have 
the
necessary selection parameters, the parameter type is fixed and the basic 
set of
encodings available are standard. Using Boost you would have to ship a DLL
with your components. And the user of your component may have to accept
this arrangement for multiple components.

The last point is how Boost.Serialization handles UDTs/ADTs. My 
understanding
of this area is sketchy - it appears to rely on pointers to methods for 
archiving of
such objects. The polymorphic interface passes a bald object through to the
archive implementation and I'm guessing, onto a registered method pointer. 
The Pact
library converts all objects including UDTs into a generic form before they 
enter the
encoding machinery and there are no registered per-type method pointers.

Once an object enters the "Pact world" it is type-less.Objects can travel 
between
threads and across networks. As they pass between processes they can be 
serialized
and de-serialized multiple times and in several different formats (i.e. 
archives/encodings).

Achieving the same mobility with Boost.Serialization is at the very least 
difficult.

Thanks for highlighting the issue,
Scott