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

Subject: Re: [boost] [async] messages threads and networks
From: Robert Ramey (ramey_at_[hidden])
Date: 2010-04-26 01:05:56

Scott Woods wrote:
>>> encoding? Given the example it would take a recompilation.
>>
>> nope.
>
> Well "given the example" - it would.
>
> You also make no mention of my related point that there is no
> standard archive registry.

Honestly, I don't know what this would be and what utility
it might have. Archive instatiations are local objects only.

> I made the same point about a Pact version of a similar operation. It
> was never about whether users of Boost.Serialization could add the
> code you have added. It was about the fact that there is no
> Boost.ArchiveFactory.

I don't seen the need for any archive factory. In nine years
no one has asked for such a thing either.  Either because no
one needs one, or making one is such trivial task.

> At the important levels they are apples and oranges. When someone
> chooses a serialization solution out of Protobuf, Boost.Serialization and
> s11n they are choosing much more than a function that converts an
> application type to a sequence of bytes.

Hmm - I would say just the opposite.  A serialization library derives its
utility from it's clearly defined narrow purpose.  It is for this reason
that it can be used in a variety of contexts.  It has been used for
persistence, marshalling (e.g. see MPI library) and probably others.
It can be used with any stream type.  Stream types can use any
encoding and (almost) any protocol.

>They are choosing a model of operation for the related serialization 
>activity.

Not here - they can plug in the other parts according to their requirements.

> My response to Sohail was an attempt at saying that Pact deliberately
> targets runtime selection of encoding and the associated mobility of 
> encoded
> data. This is within the "model of operation" for Pact.- out of the box. 
> If I am
> wrong to suggest that Boost.Serialization had different design goals
> and consequently does not deliver this (/out of the box/) then I am happy 
> to retract.

I think your documentation should focus more on what your library does 
rather
than what you believe other libraries can't do.  I did read through the 
links
you posted and didn't think I could say much that would be constructive.
But now that I've been sucked into the discussion, I would make the 
following
comment.

I think that your proposal suffers from a common failing that is shares with
many proposals received here. It is focused on solving a fairly specific
programming problem. As the work progresses, more and more
"features" have to be added to make it's application wider. This often
seen in commercial products which continually get bigger and harder
to use.

 This turns out to be the exact wrong approach.  A good library is simple
to explain and use.  When a feature is needed, it should be obvious
how to compose the particular library with another one.  For an
example of a good library - look at iterators:

a) iterator_facade
b) iterator_adaptor

examples
filter_iterator
counting_iterator
..
and finally, iterators_adaptors are composable so that one can
"stick" them together without re-writting anything.  If I want
to add some special facility (e.g. insert a space every 4 characters)
I can make an iterator which does that - and compose with
all the others.  That's power!!!

Another example - *nix text processsing tools.  After 30 years
grep is probably the single most frequently invoked program
on the planet !!!  And it's composable with all the other
*nix tools.  Compare this with microsoft word a behemouth
which I would have to read the manual/help for a day just
get the equivalent of "grep -i Ramey <my_file" | count to how
many time I've mentioned my own name in this post.

The classic example: algebra - four operations + ( and ) and
a high school student can express a calculation which would
have take euclid pages to describe.  That's Power!!!

That is what we should strive for.  Those should be our
inspiration.  I realize this thinking is out of style and that
I sort of got carried away.  Sorry, but I feel better now.

Robert Ramey