Hi Cornelius, thanks a lot for the links, I will look into these.
Also, thanks for clarifying the issue I was referring to: "Essentially what gets lost with pub-sub and likely any event-based integrative (EBI) architecture is that interactions are no longer explicit and less visible, but implicit and so it becomes hard to reason about the behavior of the system at a higher level." On Tue, Mar 20, 2012 at 8:58 AM, Cornelius Toole <[email protected]>wrote: > Benoit, > > Have you looked at the DCI(Data, Context and Interaction) architecture > stuff from Trygve Reenskaug and James O. Coplien? I don't know if this is > the best link for it, but I'm in transition(or should be): > http://www.artima.com/articles/dci_vision.html > > Essentially what gets lost with pub-sub and likely any event-based > integrative (EBI) architecture is that interactions are no longer explicit > and less visible, but implicit and so it becomes hard to reason about the > behavior of the system at a higher level. DCI is aimed at making > interactions a first class citizen. > > Also check out Orit Shaer's dissertation, chapter 4, section 3 (there's a > journal paper that is probably more succinct, but I'm on the run): > http://books.google.com/books?id=MQc6WTtulJQC&printsec=frontcover&hl=en#v=onepage&q&f=false > In it, she discusses using high-level states to describe the behavior of > interactive systems that incorporate physical representations (tangible > user interfaces). It's not so much about messaging and pub-sub, but the > model presented in the document relates a UI dialogue (both user-system and > system-system) to a set of interaction patterns that are supported by > system (see > https://skitch.com/corntoole/8miq9/cs.wellesley.edu-oshaer-tuiml.pdf). > Perhaps, a similar model could be used to encapsulate the relationships > between certain message patterns and high-level behavior. (I see that > google books omits part of the book germane to this discussion, so here's a > link to the journal paper: http://cs.wellesley.edu/~oshaer/TUIML.pdf, see > section 2.1.2 ) > > > -- > Cornelius Toole > Sent with Sparrow <http://www.sparrowmailapp.com> > > On Monday, March 19, 2012 at 6:33 PM, Benoît Fleury wrote: > > Hi Casey, > > the decoupling of the event emitters and receivers is what I find the most > interesting in a pub/sub model. The publisher raises an event (in its > semantic domain) and does not know what subscribers are going to receive it > or what they're going to do with it. One of the advantage of this > decoupling is that you can extend a system without modifying existing parts. > > Practically, I also encountered systems where a pub/sub model helped > reducing the amount of code. A lot of objects needed to be aware of events > happening in the system and instead of having to call all these objects > every time something interesting was happening in the system, we raised an > event for each one of them and had the objects subscribe to these events. > > The other advantage I also felt while using pub/sub model is that it > helped me create better object-oriented design: > - because you can't send direct messages, you don't use your objects as > data structures > - and consequently, all the code that changes the state of your object is > located in the object which makes the system easier to understand > > The issue I have with the event systems I encountered so far is that you > gain the decoupling but lose the expressiveness of message passing. The > code in the subscribers often looks like this: > > cause => effect > cause => effect > cause => effect > > If you want to implement a complex behavior, you need to maintain state > and that becomes quickly harder to understand. That's why I was wondering > if you could interleave the "causes" and "effects" in a grammar to describe > the behavior of an object in a more readable way, be able to reuse rules, > having higher-order rules... > > Benoit > > On Mon, Mar 19, 2012 at 3:35 PM, Casey Ransberger < > [email protected]> wrote: > > Here's the real naive question... > > I'm fuzzy about why objects should receive messages but not send them. I > think I can see the mechanics of how it might work, I just don't grok why > it's important. > > What motivates? Are we trying to eliminate the overhead of ST-style > message passing? Is publish/subscribe easier to understand? Does it lead to > simpler artifacts? Looser coupling? Does it simplify matters of concurrency? > > I feel like I'm still missing a pretty important concept, but I have a > feeling that once I've grabbed at it, several things might suddenly fit and > make sense. > _______________________________________________ > fonc mailing list > [email protected] > http://vpri.org/mailman/listinfo/fonc > > > _______________________________________________ > fonc mailing list > [email protected] > http://vpri.org/mailman/listinfo/fonc > > > > _______________________________________________ > fonc mailing list > [email protected] > http://vpri.org/mailman/listinfo/fonc > >
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
