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
-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;
>>
>>
>>
<
https://gist.github.com/matzew/bd4f3c41e1114c225eb1#implementation-of-the...
>> 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