Hi Andreas (welcome back), > > 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? > > I'm not sure I understand what such a library would do (there's already > boost::signals which covers publish-subscribe pattern, which BTW could be > interesting for certain types of inter-FSM communication too). Can you > elaborate? >
Hmmm. Vocabulary overlap again. My flippant suggestion for a library name came from SDL where "signals" are the objects sent/received by FSMs (should stick to the vocab I suggested myself ;-(. Anyhow. As far as what it would do? I was trying to fill in the next piece of the puzzle. You (correctly, of course ;-) separated your FSM library from anything to do with "comms". If I was to apply your library to implementing some distributed, telephony FSMs then I would have a bit of work to do. From the point where an event is generated until it is presented to a FSM, there may be some mountains and rivers to cross (i.e. a network). This is the area that I was alluding to with my mis-named boost::signaling. Of course there are a bunch of applicable technologies, but that is all tangential. As far as boost::fsm is concerned this stuff is only interesting in that it helps clarify the scope of your work (to me ;-) and how it might mesh with the next piece. Thanks, Scott _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
