Re: [boost] Question regarding logging, persistence,threadcommunication, network messaging and async frameworks
Scott Woods writes:
I looked through the thread at "for each member of a sturcture/class ?" and not sure how to respond; the issue being dealt with in that thread (while interesting) is subordinate to my goals. 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. 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. 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. Regards, Brian Wood Ebenezer Enterprises www.webEbenezer.net
----- Original Message ----- From: "brass goowy" <brass@goowy.com> To: <boost@lists.boost.org> 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
participants (2)
-
brass goowy -
Scott Woods