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

Kris Borchers kris at redhat.com
Fri Feb 22 11:35:27 EST 2013


On Feb 22, 2013, at 7:33 AM, Matthias Wessendorf <matzew at apache.org> wrote:

> 
> 
> On Fri, Feb 22, 2013 at 2:28 PM, Kris Borchers <kris at redhat.com> wrote:
> 
> On Feb 22, 2013, at 7:22 AM, Matthias Wessendorf <matzew at apache.org> wrote:
> 
>> 
>> 
>> On Fri, Feb 22, 2013 at 2:08 PM, Kris Borchers <kris at redhat.com> wrote:
>> 
>> On Feb 22, 2013, at 4:04 AM, Matthias Wessendorf <matzew at apache.org> wrote:
>> 
>>> 
>>> 
>>> On Thu, Feb 21, 2013 at 9:00 PM, Sebastien Blanc <scm.blanc at gmail.com> 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/javax/jms/TopicPublisher.html
>>> 
>>> 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 at apache.org> 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 at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>> 
>>> 
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev at 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 at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>> 
>> 
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> 
> 
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20130222/14b5b380/attachment-0001.html 


More information about the aerogear-dev mailing list