Re: [boost] Re: Re: Re: Some questions on the FSM submission

From: Scott Woods (scottw_at_[hidden])
Date: 2003-06-08 21:30:33

Hi Andreas,

> I don't know what part in the UML specs you're referring to (I don't
really
> know UML apart from class diagrams and state charts). A quick search did
not
> reveal much apart from protocol state machines which AFAICT don't have
> anything to do with FSM interaction.

Confusion is (again ;-) my fault. I will try to do better this time round.

I was back-predaling on the different capabilities of SDL and UML with
respect
to their potential to deal with the issue of "free-protocols" (in the manner
of free-
functions). After reading;

http://www.rational.com/media/uml/resources/documentation/umlrt.pdf

I felt it was unreasonable to make the broad statements I had made
previously
about UML's (or SDL's) inability to treat protocols as substantive. While
the
document above is not part of the UML specification it is obviously quality
work that applies UML to the modeling of protocols.

It isnt a built-in facility of UML and their model for protocols (and
capsules and
ports and connectors) was not what I had envisaged. But it seemed to be a
successful modeling and I had to concede; why should a "niche" concept such
as "protocols" foul the "global namespace" of a generic modeling language?

> SDL defines channels, gates and connections which sort of define a
protocol.
> To me, these primitives are only necessary to *document* which FSM is
> talking to which other FSM. There's little semantics behind them. Maybe
I'm
> seeing this too easy but I think in C++ all you need for inter-FSM
> communication is:

Yes. Agree with significance/usefulness of channels, gates and connections.
And
this is part of why I consider SDL (& UML) "weak" in their "out-of-the-box"
abilities
to specify FSM interaction (i.e. protocols).

> 1. Events that can carry parameters
> 2. A call-back mechanism a la boost::function, so that an FSM that is
> answering a request does not have to know who it is answering to.
>
[snip]
>
> boost::intrusive_ptr< Request > pRequest = new Request();
> // set params
> A & machine = context< A >();
> pRequest->callback = boost::bind( &A::queue_event, machine, _1 );
>
> B::instance().queue_event( pRequest );
>
>
> So, IMO there's no need for boost::fsm to provide communication protocol
> primitives, because their functionality is pretty orthogonal to what my
> library does. Users would want to use what they're accustomed to. Most
would
> presumably use boost::function.
>

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?

Of course, this does not directly meet the requirements I have (so badly)
articulated but it does not preclude related work in the future (I'm
thinking
decades). I suspect that some of my inability to define a "protocol" (a
collection
of events) is related to different apparent areas of work; i.e. real-time
events vs
distributed message processing, e.g. FTP or IMAP4. A significant difference
is
that the former is less likely to involve well-defined sets of messages that
will be
re-used from one project to the next (or even surfacing in several parts of
a single
project).

I feel responsible for something of a detour into the subject of SDL and the
comparison of UML with SDL. I hope that this detour has uncovered something
of
use for you (certainly has for me) but really exactly where these languages
are going and their relative advantages are secondary to getting your
library
accepted ;-)

Thanks,
Scott