|
Boost : |
From: Scott Woods (scottw_at_[hidden])
Date: 2003-06-15 17:39:07
Hi Andreas (welcome back),
> > Yes. Think with 1, 2 and putting distance between boost::fsm and comms
> > you have nailed something for me. Maybe there will eventually be a
> > boost::signaling (damn
> > thats somewhat overused) or boost::eventing (sounds like a horse
> > race) that will
> > complement your current targets?
>
> I'm not sure I understand what such a library would do (there's already
> boost::signals which covers publish-subscribe pattern, which BTW could be
> interesting for certain types of inter-FSM communication too). Can you
> elaborate?
>
Hmmm. Vocabulary overlap again. My flippant suggestion for a library name
came from SDL where "signals" are the objects sent/received by FSMs (should
stick to the vocab I suggested myself ;-(.
Anyhow. As far as what it would do? I was trying to fill in the next piece
of
the puzzle. You (correctly, of course ;-) separated your FSM library from
anything to do
with "comms". If I was to apply your library to implementing some
distributed, telephony
FSMs then I would have a bit of work to do. From the point where an event is
generated until it is presented to a FSM, there may be some mountains and
rivers
to cross (i.e. a network). This is the area that I was alluding to with my
mis-named
boost::signaling.
Of course there are a bunch of applicable technologies, but that is all
tangential.
As far as boost::fsm is concerned this stuff is only interesting in that it
helps clarify
the scope of your work (to me ;-) and how it might mesh with the next piece.
Thanks,
Scott
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk