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

Subject: Re: [boost] [async] messages threads and networks
From: Scott Woods (scott_at_[hidden])
Date: 2010-04-24 23:31:17

Hi,

> #include <boost/fusion/include/adapt_struct.hpp>
>
> struct person
>  {
>      string name;
>      int number;
>  };
>
> BOOST_FUSION_ADAPT_STRUCT(
>  person,
>    (string,name)
>    (int,number)
>  )
> // Probably something to register a name for it too, wrap it all up 
> together
> """
>
> And that is all in the header, no CPP usage needed.  Your system would
> just register to handle the fusion types and you can suddenly
> everything from structs, C static arrays, stl static containers
> (including boost::array), and much more without needing to specialize
> for any of them.

This basically looks appealing. I have one question though. I jumped through
a few hoops so that registration does not need to mention the type - it is
auto-generated from the member name. I would be happy to leverage the work
of Fusion but sad to lose the correctness guarantee offered by 
auto-generating
the type. Can Fusion offer that as well?

As the types get more complicated the chances of a registration error (i.e. 
an
incorrectly associated type ) move from "possible" to "expected".

>
> Also noticed that your enum registrations require a single CPP side
> along with the header side, would it not be a lot easier to just
> register in the header, like how fusion does it?  You could do
> something like use Boost.MPL to save the enums and their values in a
> type declaration instead, needing no operator<</>> overloads or
> anything, and you handle the enum registration type.

Again, this sounds good. From the words you use it sounds like the
Fusion registrations are a compile-time facility? Pact registrations create
information in a runtime database. That database is searched/iterated by
parts of the library (such as the one that generates an XML encoding),
based on a type id. There is no compile-time type information available to
that part of the library. The type database also needs to be something that
can be sent around a network. Are MPL/Fusion-based solutions still a good
direction given these requirements?

>
> Based on this sentence:
> """
> During the "load" function Pact automatically detects the
> non-existence of an expected file and instead of failing with an
> error, it writes the current value of the object into the indicated
> file. That's right; a function that appears to be an input function
> also performs output.
> """
> Would load not be better served by renaming to something consistent,
> like load_or_create (bad name) or something better
> (sync_to_filename?)?

Understand your point. The full name is of course "pact::load". Being
a verb in its own namespace I was hoping it could define its own
specific meaning. Happy to concede to a majority opinion that I
was misdirected.

>
> Heh, nice names for the encodings:
> """
>    *      Lean Text ­­– text, readable, portable
>    *      Neat Bytes – binary, portable
>    *      Byte Blast – binary, non-portable
>    *      Word Markup – text, readable with appropriate tools,
> portable, symbolic.
> """

Well - a bit cutesy but alternatives were unremarkable. Check the
last section of the "extended journey" (Why the silly encoding names) for an
attempt at absolution.

>
>
> The 
> http://groups.google.com/group/pact-serialization/web/the-extended-journey
> link does not exist.

Very unfortunate. I have had a few problems with links in Google Groups. 
They
seem to be a symptom of not being signed in, i.e. do you have a Google 
identity?
This is the subject of the first entry in the group discussions.

Quite why it should make any difference is beyond me. There is nothing in 
any
of the GG documentation that suggests non-signed-in (unsigned?) viewing gets 
a
lower class of service.

I did discover a crude fix so I will look at this again.

>
>
> Based on the description page, the Async I/O work and messaging looks
> interesting.  Have not played with any actual source though, and do
> not see and code examples page (maybe that extended journey missing
> page?).  The type system could easily be vastly simplified with a few
> Boost libraries.
>
>
> Will look at it later when I get more time, looks interesting though,
> but definitely need more information, speed, a lot more code examples,

All the documentation you have seen has been written specifically to
present the library to parties such as Boost (i.e. you). From initial
responses I'm guessing that the time and energy consumed by that
effort is unlikely to result in anything. Thats a lot of effort that could
have been directed into other development.

Apologies for the small rant but requests for documentation are endless.
I deliberately compiled a complete list of supporting documents and then
chopped it down to the set achievable writing at 2am to avoid family
obligations. I would love to finish the full set but there must be a proper
opportunity.

More speed? Always interested in making software faster but where is
it slow?

I also enjoy code examples but have you downloaded the samples
solution yet? You are asking for more code beyond that provided in the
samples?

Thanks,
Scott