[snip] Andreas wrote: > 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. >
... 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 [1] and Group Theory [2] 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? - Chris Morphisms [1] http://www.wikipedia.org/wiki/Morphism Group Theory [2] http://www.wikipedia.org/wiki/Group_Theory _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
