Hi Scott, point well taken. I think we're talking at different levels in the great abstraction foodchain. When you speak of protocols, you're talking about a specification (like one published by the ITU) that you need to implement. If I understand you correctly, you're saying that in practice you don't actually implement the entire specification for all targets under all circumstances. So in code you might have alternate implementations of FSM's that each more-or-less implement parts of the specification, and by extension their event signaling semantics may differ?
What I'm talking about is a mechanism for formally describing the event/signaling interaction semantics between specific sets of FSM's - a specific object-level protocol if you will. By my way of thinking then, for you to go off and use this to implement, for example, an ITU telco protocol for different targets (you cite the example of four different ITU protocol implementations on four different hardware platforms) would require alternate FSM implementations (and by extension alternate inter-FSM object-level event signaling protocols) be defined for each target platform. Worst case the implementations are completely orthogonal in which case this idea would only help you on a per-target basis and that's really the limit of the scope of what I'm talking about. The whole business of doing high-level concept checking on mappings between sets of objects is something I'm struggling with in another context right now so it's useful to try to explain this stuff. Does this make more sense now knowing that I'm talking at the level of abstraction of specific FSM's and specific event/signaling protocols and not the more general full-blown ITU style protocol? Sorry for the overloading, but I can't think of a better way to describe it. - Chris "Scott Woods" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > "A category is given by two pieces of data: a class of objects and, for > any > > two objects X and Y, a set of morphisms from X to Y." > > > > What I was trying to suggest is that the objects in the category are > FSM's, > > and the set of morphisms defined for any two FSM's X and Y is a concept > that > > needs to be checked. Speaking as a layman, and not a discrete math > theorist, > > at first glimpse it would seem reasonable to think that the various > flavors > > of morphism might provide us with a nomenclature for describing the set(s) > > of inter-FSM event exchanges that a protocol could legally define without > > violating the semantics of any of the FSM objects in the category. > > > > Hi Chris, > Interesting. With a minimal understanding of discrete math theory (read > zip) am concerned that I am about to say something stupid but did have 2 > to offer anyway. > > 1) With low uptake of FSM approach to coding - adding grouping and > *morphing? > Think I can see the same light and with a childhood fear of the dark would > probably stumble in the same direction. The end of the tunnel could be a > lonely > place though;-) > 2) Having worked on multiple implementations of several protocols one > (painfully) > delayed revelation went something like this. If you are required to > implement Q.931 > on 4 hardware devices from 4 different vendors then you will produce 4 > distinct > implementations. Targeting a set of common semantics is somewhat "flawed". > In > FSM terms an implementation of a protocol may have some transitions missing. > In practice there are specifics about a device or even the implementation by > the > telco (yep, implementations of ITU standards on PSTNs vary) that mean a full > implementation is impossible. Have you ever dealt with minutely varying > behaviours > of mail servers (all fully POP3 or IMAP4 conformant)? Anyhow my point is; > with > your goal of defining permissible semantics, will there be the latitude to > cope with > previously described circumstances? > > SW > > > > > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost > _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
