[mailto:boost-bounces@lists.boost.org]On Behalf Of Jeff Garland Sent: Tuesday, March 02, 2004 4:14 PM
In general, large libraries are a problem in boost -- for lots of reasons. I'd encourage you to break things down into useable pieces and focus on getting the most useful parts boostified. If it is really large, it will be a long road...
Ah. Another long and winding road.
* network representation of structured data (variants)
How different from boost.Variant?
Significantly. Boost version I understand to be a template that brings much compile-time checking to the world of discriminated union containers. Very nice. My variant implements something like an interpreter's type system; complete with symbols tables and type codes. The variant's type system has builtin types, e.g. void, integer, time, float and list, but arbitrarily structured types can also be constructed. e.g.; typed_word word( list_type() ); // Ctor builtin list type typed_memory &memory = word; // Get underlying vector symbol_table table; // Symbolic info memory.push_back( "" ); // Build the memory version memory.push_back( 4 ); memory.push_back( 2 ); // Build the symbol info table.push_back( typed_symbol( "data_source", string_hash ) ); table.push_back( typed_symbol( "maximum_clients", integer_hash ) ); table.push_back( typed_symbol( "maximum_workers", integer_hash ) ); word.make( typed_record( "configuration", table ) ); // New type with unique discriminator The call to the "make" method installs all kinds of type-system information into some supporting data structures. That info is used in all sorts of places - serialization, diagnostics and error handling. This may sound like a computationally intensive variant but it isnt. Perfomance o/hs are the same as for any other discriminated union, it just allows the creation of new discriminators. Resorting to the symbolic info is on a "where it would be really cool to know" basis. Note: direct use of make is non-existent in clients of the wider library. Code such as that shown is auto-generated from the schema. Considered both boost.variant and boost.any. Failed to kickstart. BTW: The discriminator is a stable hash value derived from a name mangling of the symbol table and hashing (weinberger) of resultant string
* saving and loading of network data (persistence)
Robert Ramey has done a huge amount of work on this -- have you checked it out? This library has been through one review cycle and I believe Robert has now addressed all the big concerns. My sense is that his library is the 'one' for persistence.
Did check this also. My understanding at the time was that it was a facillity driven by the C++ class info, i.e. the locus of control was the C++ type system (perfectly valid and correct of course :-). Most obviously, my locus of control is the "variant type system". This is something of a simplification; maybe boost.serialization could have been used. I think it is at least reasonable to say that it would have complicated the wider library. At the time I looked I admit that I was somewhat overloaded.
* stateless and stateful machine representation
How does this contrast with the boost.fsm (finite state machine) implementation in the boost-sandbox by Andreas Huber? I think the project has been dormant for awhile although I notice the docs page was update in Feb 2004. Anyway, it is quite interesting.
Looked at the ability to generate state machines from mpl::lists and was involved in some exchanges with Andreas re: his sandbox work. There were couple of reasons I did not incorporate these, neither of which preclude their introduction later on. At the time both my library and Andreas library were work-in-progress. Andreas work is much more formal - something that I would love to benefit from at a later date. The transition_table example using mpl was very interesting. As my state machines are typically driven by schema-generated "events" (i.e. variant hash values) it was pretty easy to extend the generator to accept an FSM (informal) that could refer to the events conveniently. The output of the generator could have been mpl-based. Seemed too cute though; a generator outputting an MPL representation that generated the state machine at compile time. I could just about imagine the eyebrows raised for that one.
* message forwarding (distributed messaging) * transparent remote machines (proxies for inter-process messaging)
Are you talking about multi-cast messaging, publish-subscribe, method invocation, or what?
A reasonable first take on my library is that it implements the ActiveObject pattern. It allows software objects to be implemented that can exchange messages asynchronously. Message forwarding and proxy machines allow the software objects involved in an exchange of messages to be distributed over separate processes and machines.
Hmm, hope I'm not jumping in in the middle without context. In any case, I'm agreeing with the need to focus.
No worries. Cheers, Scott