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

From: brass goowy (brass_at_[hidden])
Date: 2008-05-25 18:43:46

Scott Woods writes:
>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. 

Shalom
 
From what you've shown it looks like the duplication of data members 
in serialization methods is not needed.  Some have been struggling to 
eliminate the need for that duplication -- http://preview.tinyurl.com/6kpx8t .   
Maybe more details about codec_object<> would be helpful.  


Brian Wood
Ebenezer Enterprises
www.webEbenezer.net