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

Fri Feb 22 08:22:48 EST 2013

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

-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;
>>>
>>>
>>> <https://gist.github.com/matzew/bd4f3c41e1114c225eb1#implementation-of-the-adapters>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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20130222/d928af52/attachment.html 