From: Chris Russell (cdr_at_[hidden])
Date: 2003-06-07 12:57:21
> 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
> presumably use boost::function.
... but given some set of two or more FSM's for which you want to define a
new protocol, it seems like some sort of concept checking would be useful.
This will likely have some impact on the design of the FSM framework
itself - maybe... Perhaps it's just some metadata that non-invasively
characterizes the FSM? If the later, then Andreas' assertion that the FSM
lib doesn't need to support protocol primitives seems reasonable.
I've been staring at the Wikipedia sections on Morphisms  and Group
Theory  looking for a suitable nomenclature for describing these protocol
concepts. Basically my idea is that the actual protocol would formally
specify what flavor of *morphism it's attempting to establish and use
information from FSM's in the group to determine if such a mapping is
possible (the concept check) and if so, affect the mapping generically
somehow (i.e. the protocol itself doesn't doesn't get involved with event
types and data semantics directly). Unclear to me if this is done at compile
time, runtime, or <gasp> both...
What do you guys think of these ideas?