Re: [boost] Question regarding logging, persistence, threadcommunication, network messaging and async frameworks

From: Scott Woods (scott.suzuki_at_[hidden])
Date: 2008-05-26 20:19:41

----- Original Message ----- 
From: "brass goowy" <brass_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Tuesday, May 27, 2008 10:45 AM
Subject: Re: [boost]Question regarding logging, 
persistence,threadcommunication, network messaging and async frameworks

>>I do not have any magic technique for avoiding duplication of member
>>information. Any C++ type that wishes to play within my library
>>must define the following two global operators;
>>inline network_variant &
>>operator<<( network_variant &nv, const person &p )
>>{
>>network_memory::iterator i = network_output<3>()( nv );
>>*i++ << p.name;
>>*i++ << p.score;
>>*i++ << p.team;
>>return nv;
>>}
>>inline person &
>>operator>>( network_variant &nv, person &p )
>>{
>>network_memory::iterator i = network_input<3>()( nv );
>>*i++ >> p.name;
>>*i++ >> p.score;
>>*i++ >> p.team;
>>return p;
>>}
>>My library for persistence, thread communication and network messaging
>>deals with the movement and representation of "network_variants", i.e.
>>by providing transform functions as above, the type acquires persistence,
>>transfer-between-threads and transfer-across-networks capabilities, in
>>one hit.
>
> It would have been good to include those in your original post.

It's never the right amount.

When you said,
> "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,"  I wondered if that meant you had developed an alternative
> approach.
>
> It isn't clear to me how what you have is better than what is already in 
> Boost.

Hmmm. I have looked at components such as serialization and asio 
individually
and it was some time ago. So a refresh cycle is called for <pause>

I am still thoroughly impressed by these packages. I am still unable to see
how they combine *as is* to deliver code of the following nature;

struct person { ... };

configuration << person();            // Yes serialization does this. 
Included for completeness only

send( person(), other_thread );

my_thread::received( person & );

send( person(), thread_in_other_process );

my_thread_in_other_process::received( person & );

Asio examples include buffering references and "which write" function is
the correct one to be used. Within the asio architecture this is completely
appropriate. It is an express goal of my approach to ensure that 
considerations
of this type never manifest themselves in application code.

Asio cites Proactor as an underlying concept. My underlying model for
async operation comes from SDL. A comparison of these alternatives
is beyond the scope of this message thread.

>>From what you've said I guess it is more flexible, but it isn't obvious to 
>>me how.
> You could also consider integration with http://s11n.net.

Fair enough. I suspected that the materials I was hoping to present are
just too involved and broad in scope. We have not even touched on the 
logging
side of my work (which would inevitably be compared with John Torjo's).
The reason for sending to the list at all is the seamless nature in which I
can deliver persistence, thread communication and network messaging.
A more useful tack for me might appear to be the integration of existing
Boost components such that they achieve a similar coherence. Some
initial research and discussion with others led me to believe that (as is)
it could not be done. At the very least it would be a "long long" process.

Regards,
Scott