Re: [boost] transparent marshalling

From: Scott Woods (scottw_at_[hidden])
Date: 2003-10-29 22:14:35

> > > I see the serialization w.i.p. library will be useful here.  Any tips
on
> > > some useful boost libs / techniques to do this?
> >
> > Cant offer any tips but can support your interest. A question though;
> >
> > * have you looked at the state-machine work done by Andreas Huber
>
> Yep.  Doing a new workflow thing.  Did one a while back using hierarchical
> graphs using a customized GGCL (now BGL).  Did a topological sort and then
> event like dynamic execution in a thread pool.
>
> Thinking of making the same extensions to BGL.  The state machine might be
a
> bit too compile time oriented, but perhaps that can fit in with BGL in a
way
> that I need to find.
>
> Hmmm, a compile time hierarchical graph library that can result in parts
> being a state machine or other representation and rest being "dynamic"
would
> do it, but is probably too big to contemplate.
>
> Am considering doing a code generator from the graph representation...
> haven't thought about doing that at compile time... sounds hard.
>
> > I ask because you mention "strictly asynch". Or are you hoping to
> > integrate "boost transparent marshalling" with your own async event
> > system?
>
> Basically I wish to find an abstraction for compile time that results in a
> function/functor call, a call to queue fed threaded worker pool, a call to
> another process, or, a call to an external machine.
>
> I think of it as another type of sequence point where you can break out
into
> a different mode of execution...  Changing the policy lets you simply
change
> the system architecture.

Very cool. Or at least what I could follow ;-)

Generally understand and "mesh" with your goals around transparent
marshalling.

It might be premature to jump to this point but it is a
fundamental clash of "where you might be headed" and some things
that "seem to be basic truths". Here goes.

The goal of "abstraction for compile time that results in a
function/functor call,..." is a damn good one. In everything I've
tried in my library I have been scuttled by this "truth"; something
recovered (marshalled) off a transport needs to be uniquely
identifiable, I haven't been able to do better than variations
of integer codes and that is *runtime*, i.e. the desirable
benefits of compile-time dispatch do not seem to be achievable
at the receive end of a marshalling process.

So currently my library does not target that :-( If you have
figured out some workaround then I will be throwing all my
toys out of the cot...

cheers,
Scott