Pivot
  1. Pivot
  2. PIVOT-851

Verify if move to a more reactive approach for event propagation and loose coupling between components

    Details

      Description

      Verify if move to a more reactive approach for event propagation and loose coupling between components.

      For example, verify (for what it's possible in Java, without a full rewrite in Scala)
      http://www.scala-lang.org/sites/default/files/sids/imaier/Mon,%202009-11-02,%2008:55/scala-swing-design.pdf
      http://lamp.epfl.ch/~imaier/pub/DeprecatingObserversTR2010.pdf

      http://stackoverflow.com/questions/3755453/scala-listener-observer
      http://stackoverflow.com/questions/3084546/design-patterns-for-functional-oo-hybrid-languages

      An innovative frameworks like Play have chosen for its new major release (2.0, released in March 2012) to do a full rewrite in Scala BUT with full compatibility even with Java (and Java 8 should have the same features too ...).
      Last, another interesting point to explore (but again mainly for Scala, or using Akka even from Java) could be to use Actors (local and/or remote), even for events ... just as idea.

      Many other interesting ideas for a more "complete" approach to make applications from Eclise E4 (extension points, mapping controllers to URLs, etc), for example some info here:
      http://www.vogella.com/articles/Eclipse4RCP/article.html
      and of course even from Griffon (in from the Groovy side).

      At the moment this issue is only a pleceholder to share in the same place ideas and links on this subject ... so as always comments are welcome.

        Activity

        Hide
        Sandro Martini added a comment -

        An interesting article on pub/sub in JavaScript (inside the browser): "Going Postal with postal.js", from here: http://sett.ociweb.com/sett/settJun2012.html

        It explains some interesting tricks (implemented in postal.js) on Channels and Topics, and on subscriptions, like no duplication of events, filtering, throttle, delay, timeout on publishing events, etc ...
        Verify even the idea to publish events (but already serialized in json strings) ... maybe as an alternative.

        Show
        Sandro Martini added a comment - An interesting article on pub/sub in JavaScript (inside the browser): "Going Postal with postal.js", from here: http://sett.ociweb.com/sett/settJun2012.html It explains some interesting tricks (implemented in postal.js) on Channels and Topics, and on subscriptions, like no duplication of events, filtering, throttle, delay, timeout on publishing events, etc ... Verify even the idea to publish events (but already serialized in json strings) ... maybe as an alternative.
        Hide
        Sandro Martini added a comment - - edited

        Other great article on this: http://jim-mcbeath.blogspot.it/2009/10/simple-publishsubscribe-example-in.html

        And a paper, from Scala people: http://infoscience.epfl.ch/record/176887 , with a link inside to the updated pdf paper (in 2012)
        and the original (older) version: http://lampwww.epfl.ch%2F~imaier%2Fpub%2FDeprecatingObserversTR2010.pdf , for a more better approach, using reactive concepts ...

        Show
        Sandro Martini added a comment - - edited Other great article on this: http://jim-mcbeath.blogspot.it/2009/10/simple-publishsubscribe-example-in.html And a paper, from Scala people: http://infoscience.epfl.ch/record/176887 , with a link inside to the updated pdf paper (in 2012) and the original (older) version: http://lampwww.epfl.ch%2F~imaier%2Fpub%2FDeprecatingObserversTR2010.pdf , for a more better approach, using reactive concepts ...
        Hide
        Sandro Martini added a comment - - edited

        Some related readings (on Event Sourcing), as a starting point (even without the need to rewrite in a different language):

        http://martinfowler.com/eaaDev/EventSourcing.html

        http://codebetter.com/gregyoung/2010/02/20/why-use-event-sourcing/
        http://blog.zilverline.com/2012/07/04/simple-event-sourcing-introduction-part-1/
        http://lostechies.com/jimmybogard/2011/10/11/event-sourcing-as-a-strategic-advantage/
        http://julienletrouit.com/?cat=4

        Others, more specific to Scala features (for example using Actors):
        http://jonasboner.com/2009/02/12/event-sourcing-using-actors/
        http://debasishg.blogspot.it/2009/02/retroactive-event-processing-with-scala.html

        Generally speaking, using Event Sourcing approach we could have (more) loose coupled components, and probably a simpler approach than Listeners, but of course we have to check at performances, and more important the ability at compile time to discover problems, etc ...

        Note that the Event Store could be pluggable (and by default not persistent), other implementations could use remote storage or even local (maybe with a NoSQL storage) ... and we could process events in a parallel way, etc ...

        In this way for example we could have a simple way to record/playback application events, useful in customer support, and probably even in debug (and in unit tests) for developers.

        Of course this could handle not only GUI Events, but maybe even other kind of events.

        But all this at the moment is only to get some more idea on if / what to do ...

        Show
        Sandro Martini added a comment - - edited Some related readings (on Event Sourcing), as a starting point (even without the need to rewrite in a different language): http://martinfowler.com/eaaDev/EventSourcing.html http://codebetter.com/gregyoung/2010/02/20/why-use-event-sourcing/ http://blog.zilverline.com/2012/07/04/simple-event-sourcing-introduction-part-1/ http://lostechies.com/jimmybogard/2011/10/11/event-sourcing-as-a-strategic-advantage/ http://julienletrouit.com/?cat=4 Others, more specific to Scala features (for example using Actors): http://jonasboner.com/2009/02/12/event-sourcing-using-actors/ http://debasishg.blogspot.it/2009/02/retroactive-event-processing-with-scala.html Generally speaking, using Event Sourcing approach we could have (more) loose coupled components, and probably a simpler approach than Listeners, but of course we have to check at performances, and more important the ability at compile time to discover problems, etc ... Note that the Event Store could be pluggable (and by default not persistent), other implementations could use remote storage or even local (maybe with a NoSQL storage) ... and we could process events in a parallel way, etc ... In this way for example we could have a simple way to record/playback application events, useful in customer support, and probably even in debug (and in unit tests) for developers. Of course this could handle not only GUI Events, but maybe even other kind of events. But all this at the moment is only to get some more idea on if / what to do ...
        Sandro Martini made changes -
        Field Original Value New Value
        Assignee Sandro Martini [ smartini ]
        Show
        Sandro Martini added a comment - Other very interesting ideas: http://debasishg.blogspot.it/2011/01/cqrs-with-akka-actors-and-functional.html http://debasishg.blogspot.it/2012/01/event-sourcing-akka-fsms-and-functional.html
        Sandro Martini created issue -

          People

          • Assignee:
            Sandro Martini
            Reporter:
            Sandro Martini
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:

              Development