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

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

-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; > Implementation 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