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

Fri Feb 22 12:09:48 EST 2013

On Fri, Feb 22, 2013 at 6:08 PM, Sebastien Blanc <scm.blanc at gmail.com>wrote:

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

ah, ok - glad we do agree on this, now :)

>
>
> On Fri, Feb 22, 2013 at 12:05 PM, Matthias Wessendorf <matzew at apache.org>wrote:
>
>> VERY NICE !
>>
>> +1
>>
>>
>> On Fri, Feb 22, 2013 at 5:35 PM, Kris Borchers <kris at redhat.com> wrote:
>>
>>>
>>> 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;
>>>>>>>
>>>>>>>
>>>>>>> <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_______________________________________________
>>>>
>>>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20130222/69afba77/attachment-0001.html 