From: Scott Woods (scottw_at_[hidden])
Date: 2003-10-30 14:53:34
From: "Hurd, Matthew" <hurdm_at_[hidden]>
> > 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,
> Or have I misunderstood?
Or me. Anyhow, tried to make my side clearer.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk