(Note: Apologies if there have been multiple copies of this mail. From my end posts to this list have not been getting through. This last attempt is after re-subscribing to the list) Hi, Is there a place in Boost for a library that tackles everything in the subject line? 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.