Re: [aerogear-dev] [AeroGear-Notifier] Client API

+1 (and that was what I also suggest in my first reply but maybe was not really clear :) )

On Fri, Feb 22, 2013 at 12:05 PM, Matthias Wessendorf <matzew(a)apache.org&gt;wrote: > VERY NICE ! > > +1 > > > On Fri, Feb 22, 2013 at 5:35 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: > >> >> On Feb 22, 2013, at 7:33 AM, Matthias Wessendorf <matzew(a)apache.org&gt; >> wrote: >> >> >> >> On Fri, Feb 22, 2013 at 2:28 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: >> >>> >>> On Feb 22, 2013, at 7:22 AM, Matthias Wessendorf <matzew(a)apache.org&gt; >>> wrote: >>> >>> >>> >>> On Fri, Feb 22, 2013 at 2:08 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: >>> >>>> >>>> On Feb 22, 2013, at 4:04 AM, Matthias Wessendorf <matzew(a)apache.org&gt; >>>> wrote: >>>> >>>> >>>> >>>> On Thu, Feb 21, 2013 at 9:00 PM, Sebastien Blanc <scm.blanc(a)gmail.com&gt;wrote: >>>> >>>>> That looks great ! >>>>> Maybe one suggestion, like the PipeManager holds Pipe objecst and the >>>>> DataStore hold Store objects, maybe the Notifier could hold Channels ? >>>>> >>>>> >>>>> var myChannel = AeroGear.Notifier.addChannel(String channel); >>>>> >>>>> >>>> >>>> You still want to give that 'channel' object a "notification listener: >>>> >>>> var myChannel = AeroGear.Notifier.addChannel(String channel, func >>>> callback); >>>> >>>> >>>>> >>>>> myChannel.onMessage(data); >>>>> >>>>> >>>> that onMEssage would be only invoked by the 'underlying' app; Or what >>>> do you mean? >>>> >>>> You registered callback receives the payload/ >>>> >>>> >>>> >>>>> >>>>> myChannel.publishMessage(data); >>>>> >>>>> >>>> Usually it's nicer of the object just sets the 'channel' - even JMS >>>> does allow you this: >>>> >>>> >>>> http://docs.oracle.com/cd/E17802_01/products/products/jms/javadoc-102a/ja... >>>> >>>> send(topic, msg); >>>> >>>> >>>> >>>>> >>>>> And maybe pushing the concept further, the notifier could hold "clients" which holds channels ... >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> Not really sure we need to build all this around it; >>>> >>>> >>>> Most libs (that we may wrap: vertx, stomp.js) don't do that... and we >>>> would add (I guess) un-needed API code… >>>> >>>> The reason I would say we need this is that it would better match our >>>> other modular APIs >>>> >>> >>> Not sure that's a too strong reason; >>> >>> >>>> and allow for easier creation, management and use of multiple >>>> messaging services. I'm imagining someone building a stock trading app that >>>> has a messaging system with their back end but they also want the app to >>>> subscribe to a stock ticker type messaging service. This would allow for a >>>> single point for managing those connections. >>>> >>> >>> >>> You can still subscribe to multiple 'channels': >>> notifier.subscribe("channelA", callbackOne); >>> notifier.subscribe("channelB", callbackTwo); >>> >>> I understand that you want to organize the 'channels' in some sorta >>> system; but... the problem is: >>> Most lib's don't do that - so we would have to add "management" code >>> for the underlying libraries, right ? >>> Not sure that's good use of time - and since most libs don't store all >>> the channels in some management - there may be a reason, why messaging libs >>> are not doing it >>> >>> >>> Organization is more a side-effect. I guess my concern is how do I have >>> a vert.x backed notifier and an atmosphere backed notifier in the same app? >>> I think it would be nice for users if they can create both of those in a >>> single statement and just specify which type as an option rather than >>> having to create them separately with 2 different notifiers. >>> >> >> can u share some pseudo code ? >> >> >> How about something like this? >> https://gist.github.com/kborchers/8a8c43a2f927357c467c >> >> >> >> >>> I guess it's not a huge deal I just thought it would add some >>> convenience. >>> >> >> >> sounds reasonable, but with some code it's easier ;-) >> >> >>> >>> -M >>> >>> >>>> >>>> -M >>>> >>>> >>>> >>>>> >>>>> >>>>> On Thu, Feb 21, 2013 at 6:38 PM, Matthias Wessendorf < >>>>> matzew(a)apache.org&gt; wrote: >>>>> >>>>>> Hello! >>>>>> >>>>>> Today, I had a brief chat with Kris about a potential AeroGear * >>>>>> Notifier* Client API... >>>>>> >>>>>> The basic idea is to *wrap* messaging APIs (e.g. Stomp.js, Vertx's >>>>>> eventbus or Socket.io/Engine.io) behind a common client 'interface'. >>>>>> >>>>>> Basically the AeroGear-Notifier should be able to *connect* to a >>>>>> messaging system in order to *subscribe* to a channel to reveice >>>>>> messages from that channel. The AG-Notifier is also able to *publish >>>>>> * messages to ANY channel. Of course,*unsubscribe* and *disconnect* are >>>>>> required too... >>>>>> >>>>>> Sure... the above is not (YET) really a *SPEC*, but it's start.... >>>>>> the JS API of the AG-Notifier (DRAFT 0.0.1) could looks like this: >>>>>> >>>>>> /** * Connects to a given URL. The callback is invoked after a connection has been established. In case of an error, an Error * object will be passed to the callback */AeroGear.Notifier.connect(String url, function callback); >>>>>> /** * Tears down the connection. The callback is invoked after a connection has been closed. In case of an error, an * Error object will be passed to the callback */AeroGear.Notifier.disconnect(function callback); >>>>>> /** * Subscribes to a channel. The callback function is invoked for every message, received on the given channel. */AeroGear.Notifier.subscribe(String channel, function callback); >>>>>> /** * Removes the subscription of the given channel. */AeroGear.Notifier.unsubscribe(String channel); >>>>>> /** * Publishes a message to a given channel */AeroGear.Notifier.publish(String channel, Object message); >>>>>> >>>>>> Perhaps a *STATE-MASHINE* would be nice as well: >>>>>> >>>>>> AeroGear.Notifier.CONNECTING = 0;AeroGear.Notifier.OPEN = 1;AeroGear.Notifier.CLOSING = 2;AeroGear.Notifier.CLOSED = 3; >>>>>> >>>>>> >>>>>> <https://gist.github.com/matzew/bd4f3c41e1114c225eb1#implementation-of-the... >>>>>> of the Adapters >>>>>> The different adapter implementations will be done separately: >>>>>> ag-notifier-vertx.js... >>>>>> >>>>>> >>>>>> Thoughts ? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Matthias Wessendorf >>>>>> >>>>>> blog: http://matthiaswessendorf.wordpress.com/ >>>>>> sessions: http://www.slideshare.net/mwessendorf >>>>>> twitter: http://twitter.com/mwessendorf >>>>>> >>>>>> _______________________________________________ >>>>>> aerogear-dev mailing list >>>>>> aerogear-dev(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> >>>> >>>> >>>> >>>> -- >>>> Matthias Wessendorf >>>> >>>> blog: http://matthiaswessendorf.wordpress.com/ >>>> sessions: http://www.slideshare.net/mwessendorf >>>> twitter: http://twitter.com/mwessendorf___________________________________________... >>>> >>>> aerogear-dev mailing list >>>> aerogear-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>>> >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>> >>> >>> >>> -- >>> Matthias Wessendorf >>> >>> blog: http://matthiaswessendorf.wordpress.com/ >>> sessions: http://www.slideshare.net/mwessendorf >>> twitter: http://twitter.com/mwessendorf___________________________________________... >>> >>> aerogear-dev mailing list >>> aerogear-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf___________________________________________... >> >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev