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 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
