On Wed, 3 Mar 2004 13:00:30 +1300, scott wrote
* 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.
So you are able to build new types at runtime? Doesn't sound like it below....
...snip example...
I have to say the code snippets aren't helping my understanding much :-(
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.
It sounds like a runtime reflection engine to support things like factory functions?
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.
Sounds more and more like a kind of reflection...
Considered both boost.variant and boost.any. Failed to kickstart.
Because they were limited by the ability to provide a factory function? Full type reflection info? What was the essential limitation...
* saving and loading of network data (persistence)
Robert Ramey has done a huge amount of work on this -- have you checked it
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.
Well, I'm sure the serialization library could be adapted to your case if you have full type information.
At the time I looked I admit that I was somewhat overloaded.
Fair enough.
* 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
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.
Ok...
* 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.
Ok. Well there is obviously some sort of networking infrastructure including a event dispatching as well. Again, these are items that are needed in boost, have had prior work (in the sandbox), but aren't ready for primetime yet. The bottom line for me is that your 'library' seems like alot of libraries that are tightly stitched together with a fairly narrow scope. I suspect they would be very difficult to boostify since they can't be pulled apart easily. Not saying that it isn't a useful framework and I'm not trying to discourage you, but at first blush it doesn't seem like a good fit with Boost 'out of the box'. I for one am much more interested in minimalist components that can be put together flexably into larger components b/c most of the 'all-in-one' frameworks usually are problematic to integrate into larger solutions. Anyway, I'm still interested in a basic Active Object on top of the thread library :-) Jeff