On Feb 22, 2013, at 7:33 AM, Matthias Wessendorf <matzew(a)apache.org> wrote:
On Fri, Feb 22, 2013 at 2:28 PM, Kris Borchers <kris(a)redhat.com> wrote:
On Feb 22, 2013, at 7:22 AM, Matthias Wessendorf <matzew(a)apache.org> wrote:
>
>
> On Fri, Feb 22, 2013 at 2:08 PM, Kris Borchers <kris(a)redhat.com> wrote:
>
> On Feb 22, 2013, at 4:04 AM, Matthias Wessendorf <matzew(a)apache.org> wrote:
>
>>
>>
>> On Thu, Feb 21, 2013 at 9:00 PM, Sebastien Blanc <scm.blanc(a)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/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>
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
_______________________________________________
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