From: Andreas Huber (ah2003_at_[hidden])
Date: 2003-06-07 17:43:12
Chris Russell wrote:
> 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
> lib doesn't need to support protocol primitives seems reasonable.
Ok, I see that concept checking could be helpful...
> 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?
Errr, while I got what a group is I don't really get what a *morphism is.
The description is too formal for me and the examples don't help either.
Moreover, I also fail to see the connection between groups and FSMs. Have I
been drinking too much lately ;o)?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk