RE: [boost] [Threads] Reactive Objects

From: scott (scottw_at_[hidden])
Date: 2004-03-02 19:00:30

> [mailto:boost-bounces_at_[hidden]]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