[boost] Question regarding logging, persistence, thread communication, network messaging and async frameworks

From: Scott Woods (scott.suzuki_at_[hidden])
Date: 2008-05-25 06:34:47

Hi,

Is there a place in Boost for a library that tackles all of the above? I 
believe the realistic
answer is no but I would be happy to be proven wrong.

Work in the different areas mentioned in the subject line recently collapsed 
into a single
underlying technique. Given the example UDT below;

    struct person
    {
        std::string name;
        std::vector<unsigned> score;
        std::set<string> team;
    };

persistence is achieved using;

    person new_member;
    codec_object<person> configuration( "profile" )

    configuration << new_member;        // Save in a disk file name 
"profile"

    configuration >> new_member;        // Load from the same disk file

transmitting the same object between threads looks like;

    send( new_member, other_thread );

while receiving that transmission occurs in code that looks like;

    my_thread::received( person &new_member )
    {
        ..
    }

Transmission of messages across networks looks like;

    send( new_member, socket_proxy );

Yes, its the same as for inter-thread communications. The "socket_proxy" 
just
happens to be a variation on "my_thread" that forwards materials it receives
onto a socket connection.

Logging looks like;

    WINSOCK( socket, AF_INET << SOCK_STREAM << 0 );
    COMMENTARY( "connection to " << address_entered << " failed (" << 
failure << ")" );

Logging messages can be routed anywhere based on the type and unique 
identity of
the originating party.

The fragments of code provided above hide a lot. While that's technically 
desirable
I can appreciate that it might not flesh out my question at all (i.e. 
...room in Boost). But
actually this is precisely the most compelling thing about the library - it 
reduces code
that traditionally can be quite difficult into fragments such as those 
shown. The actual
implementation of the "send" primitive appears below;

    // from a header

    class active_point
    {
        void send( type_hash, network_variant &, point_id );

        template<typename S>
        void
        send( const S &s, point_id a )
        {
            if( !a )
            {
                return;
            }
            send( type_of<S>::hash(), network_variant() << s, a );
        }

    // from the related cpp

    void
    active_point::send( type_hash h, network_variant &nv, point_id a )
    {
        network_variant s;
        network_memory::iterator i = network_output<3>()( s );

        *i++ << h;
        i++->swap( nv );
        *i++ << self;

        point_register().send( s, a );
    }

This is only provided to give a tiny bit more substance to my code 
fragments.

The catalyst for my question is that this work is about to be shelved. If 
any
part of this work could be a contribution to Boost then that is much better
(from my POV) than nothing. Of course there has to be a place for it and
it has to pass the wonderfully rigorous Boost review process.

Some of the technical selling points;

* basic async model is taken from SDL (system description language).
* the technique is non-intrusive; e.g. it is possible to "send" instances of 
types from third-party libraries
* externalized data (i.e. in disk files and on network connections) is 
subject to formalized encoding/decoding
* the technique appears to be reasonably efficient - certainly no worse than 
code it replaced.
* the technique copes with the storage and transmission of arbitrarily 
complex C++ objects, easing design constraints
* the technique removes the need  for data translation (i.e. the code that 
appears around SQL servers, Windows registry and DCOM).

I appreciate that Boost already has components that solve different parts of
the same puzzle. Those components are major contributions to C++ that I
am not trying to compete with. If there is anything of value in what I have, 
I
suspect it's in achieving the trilogy; persistence, thread communications 
and
network messaging with a single unifying technique.

Any questions welcome,

Scott.