Re: [boost] transparent marshalling

From: Scott Woods (scottw_at_[hidden])
Date: 2003-10-30 14:53:34

From: "Hurd, Matthew" <hurdm_at_[hidden]>

> <snip>
> >
> > 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...
>
> I see what you mean.  If the transport destination is multiplexed you need
> to identify either the source or the specific destination by id.
>
> Can't quite see why you would need an id if it was not multiplexed.

Certainly an id for the purpose of multiplexing is an example of what
I was trying to describe. More essentially I was discussing the area
of protocols; an exchange of asynch events between two software
components across some transport. The "asynch events" need to be
uniquely identifiable so that state machine X can invoke its
appropriate transition Y.

The multiplex example is consistent with this model. The mux code
on each end of the transport can be considered to be a pair of state
machines exchanging asynch events.

I am assuming your goal is compile-time dispatch to the transition
function (with all the wonderful optimaizations that can bring) Y.

Dispatch to function Y involves runtime parameters recovered by
the marshalling process.
>
> Could have a policy for generating the id... UUID, address, typeinfo,
> none...
>
> Or have I misunderstood?

Or me. Anyhow, tried to make my side clearer.

Cheers,
Scott