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); myChannel.onMessage(data); myChannel.publishMessage(data); And maybe pushing the concept further, the notifier could hold "clients" which holds channels ... On Thu, Feb 21, 2013 at 6:38 PM, Matthias Wessendorf <matzew(a)apache.org&gt; 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

On Thu, Feb 21, 2013 at 9:00 PM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; 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…

-M On Thu, Feb 21, 2013 at 6:38 PM, Matthias Wessendorf <matzew(a)apache.org&gt; 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

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

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

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&gt; 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

VERY NICE ! +1 On Fri, Feb 22, 2013 at 5:35 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: > > On Feb 22, 2013, at 7:33 AM, Matthias Wessendorf <matzew(a)apache.org&gt; > wrote: > > > > On Fri, Feb 22, 2013 at 2:28 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: > >> >> On Feb 22, 2013, at 7:22 AM, Matthias Wessendorf <matzew(a)apache.org&gt; >> wrote: >> >> >> >> On Fri, Feb 22, 2013 at 2:08 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: >> >>> >>> On Feb 22, 2013, at 4:04 AM, Matthias Wessendorf <matzew(a)apache.org&gt; >>> wrote: >>> >>> >>> >>> On Thu, Feb 21, 2013 at 9:00 PM, Sebastien Blanc <scm.blanc(a)gmail.com&gt;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&gt; 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___________________________________________... >> >> 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

On Fri, Feb 22, 2013 at 6:08 PM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; 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(a)apache.org&gt; wrote: VERY NICE ! +1 On Fri, Feb 22, 2013 at 5:35 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: On Feb 22, 2013, at 7:33 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: > > > On Fri, Feb 22, 2013 at 2:28 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: > > On Feb 22, 2013, at 7:22 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: > >> >> >> On Fri, Feb 22, 2013 at 2:08 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: >> >> On Feb 22, 2013, at 4:04 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: >> >>> >>> >>> On Thu, Feb 21, 2013 at 9:00 PM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; 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&gt; 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 _______________________________________________ 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

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

On Fri, Feb 22, 2013 at 6:53 PM, Summers Pittman <supittma(a)redhat.com&gt;wrote: > So, in theory, would I be able to > > 1) Define a message channel (boats) > a 'pipe' :) to a server, yes. Publishing from client works. and receicing msgs on that channel works too > 2) Define a series of systems which implement that channel (websocket, > GCM, carrier pigeon) > this is just 'js' client api... so... there will be only SockJS (websocket and legacy fallbacks). No GCM/APNs receiving in JS land (pure mobile web). > 3) Have AG Auto negotiate systems. (When the app is up use a websocket > system, when it background use GCM, and when the network is down scan QR > codes off pigeons) > I guess anwser to 2) makes sense here ? > > ? > > Summers > > > > On 02/21/2013 12:38 PM, Matthias Wessendorf 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 listaerogear-dev@lists.jboss.orghttps://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

Soooo… That - https://github.com/kborchers/aerogear-js/tree/Notifier and That - https://github.com/kborchers/vertx-push-demo/tree/aerogear Enjoy! :D On Feb 22, 2013, at 12:13 PM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: But, as said on the first email, there is no spec right now... BUT..., yes - that's the idea behind the _abstract_ notifier API. On Fri, Feb 22, 2013 at 6:56 PM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: > > > > On Fri, Feb 22, 2013 at 6:53 PM, Summers Pittman <supittma(a)redhat.com&gt; wrote: >> >> So, in theory, would I be able to >> >> 1) Define a message channel (boats) > > > a 'pipe' :) to a server, yes. Publishing from client works. and receicing msgs on that channel works too > >> >> 2) Define a series of systems which implement that channel (websocket, GCM, carrier pigeon) > > > this is just 'js' client api... so... there will be only SockJS (websocket and legacy fallbacks). No GCM/APNs receiving in JS land (pure mobile web). > >> >> 3) Have AG Auto negotiate systems. (When the app is up use a websocket system, when it background use GCM, and when the network is down scan QR codes off pigeons) > > > I guess anwser to 2) makes sense here ? > >> >> >> ? >> >> Summers >> >> >> >> On 02/21/2013 12:38 PM, Matthias Wessendorf 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 -- 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

These are all good thoughts. I was basically just implementing this far enough to get your example working so there is still a lot missing. Other comments in line. On Feb 26, 2013, at 1:59 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: > Nice, > > a few questions: > > * autoConnect - hrm... looking at the usage, I think for messaging it > may be more desired to have an explicit 'connect()' hook; There is one. I could have set it up with autoConnect: false and then explicitly called connect() when I was ready. > > * setting up everything up front is OK... but usually you want to be > able to 'subscribe' to a channel/topic/queue later on, which the same > 'client' > https://github.com/kborchers/vertx-push-demo/blob/aerogear/www/js/index.j... There will be this feature I just haven't gotten that far yet. I was thinking by adding/removing channels from the client, that would subscribe/unsubscribe them. > > * there is a 'onConnectError' - errors could occur in different ways > (when receiving, subscribing etc) Same as above. This will come (if there is a method for catching those errors). > > * the callback on the channel: here you directly use the 'replyTo' arg > (vertx detail), not every lib (e.g. Stomp.js) has something like that: > https://github.com/kborchers/vertx-push-demo/blob/aerogear/www/js/index.j... > This is where I'll need your help since I don't know those details so I will try to find a way to generalize additional parameters.

> > I am sure, more will come, when I start using it > > > -Matthias > > > On Mon, Feb 25, 2013 at 10:59 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: >> >> Soooo… >> >> That - https://github.com/kborchers/aerogear-js/tree/Notifier >> >> and >> >> That - https://github.com/kborchers/vertx-push-demo/tree/aerogear >> >> Enjoy! :D >> >> On Feb 22, 2013, at 12:13 PM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: >> >> But, as said on the first email, there is no spec right now... >> >> BUT..., yes - that's the idea behind the _abstract_ notifier API. >> >> On Fri, Feb 22, 2013 at 6:56 PM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: >>> >>> >>> >>> On Fri, Feb 22, 2013 at 6:53 PM, Summers Pittman <supittma(a)redhat.com&gt; wrote: >>>> >>>> So, in theory, would I be able to >>>> >>>> 1) Define a message channel (boats) >>> >>> >>> a 'pipe' :) to a server, yes. Publishing from client works. and receicing msgs on that channel works too >>> >>>> >>>> 2) Define a series of systems which implement that channel (websocket, GCM, carrier pigeon) >>> >>> >>> this is just 'js' client api... so... there will be only SockJS (websocket and legacy fallbacks). No GCM/APNs receiving in JS land (pure mobile web). >>> >>>> >>>> 3) Have AG Auto negotiate systems. (When the app is up use a websocket system, when it background use GCM, and when the network is down scan QR codes off pigeons) >>> >>> >>> I guess anwser to 2) makes sense here ? >>> >>>> >>>> >>>> ? >>>> >>>> Summers >>>> >>>> >>>> >>>> On 02/21/2013 12:38 PM, Matthias Wessendorf 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 >> >> >> >> >> -- >> 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

On Tue, Feb 26, 2013 at 2:24 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: > > On Feb 26, 2013, at 6:56 AM, Kris Borchers <kris(a)redhat.com&gt; wrote: > >> These are all good thoughts. I was basically just implementing this far enough to get your example working so there is still a lot missing. Other comments in line. >> >> On Feb 26, 2013, at 1:59 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: >> >>> Nice, >>> >>> a few questions: >>> >>> * autoConnect - hrm... looking at the usage, I think for messaging it >>> may be more desired to have an explicit 'connect()' hook; >> >> There is one. I could have set it up with autoConnect: false and then explicitly called connect() when I was ready. >>> >>> * setting up everything up front is OK... but usually you want to be >>> able to 'subscribe' to a channel/topic/queue later on, which the same >>> 'client' >>> https://github.com/kborchers/vertx-push-demo/blob/aerogear/www/js/index.j... >> >> There will be this feature I just haven't gotten that far yet. I was thinking by adding/removing channels from the client, that would subscribe/unsubscribe them. >>> >>> * there is a 'onConnectError' - errors could occur in different ways >>> (when receiving, subscribing etc) >> >> Same as above. This will come (if there is a method for catching those errors). >>> >>> * the callback on the channel: here you directly use the 'replyTo' arg >>> (vertx detail), not every lib (e.g. Stomp.js) has something like that: >>> https://github.com/kborchers/vertx-push-demo/blob/aerogear/www/js/index.j... >>> >> >> This is where I'll need your help since I don't know those details so I will try to find a way to generalize additional parameters. > > Actually, looking at this more, this callback is triggered by the underlying library (vert.x) so I think have that specific param here is ok because they know they are using the vert.x adapter. I think we would just need to document the parameters for this callback in our docs. not sure I like that; I think - to have some more abstractness - chaining them is better: So that ours just really needs the 'message' and we can (if we want) ignore the replyTo…

> >> >>> >>> I am sure, more will come, when I start using it >>> >>> >>> -Matthias >>> >>> >>> On Mon, Feb 25, 2013 at 10:59 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: >>>> >>>> Soooo… >>>> >>>> That - https://github.com/kborchers/aerogear-js/tree/Notifier >>>> >>>> and >>>> >>>> That - https://github.com/kborchers/vertx-push-demo/tree/aerogear >>>> >>>> Enjoy! :D >>>> >>>> On Feb 22, 2013, at 12:13 PM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: >>>> >>>> But, as said on the first email, there is no spec right now... >>>> >>>> BUT..., yes - that's the idea behind the _abstract_ notifier API. >>>> >>>> On Fri, Feb 22, 2013 at 6:56 PM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: >>>>> >>>>> >>>>> >>>>> On Fri, Feb 22, 2013 at 6:53 PM, Summers Pittman <supittma(a)redhat.com&gt; wrote: >>>>>> >>>>>> So, in theory, would I be able to >>>>>> >>>>>> 1) Define a message channel (boats) >>>>> >>>>> >>>>> a 'pipe' :) to a server, yes. Publishing from client works. and receicing msgs on that channel works too >>>>> >>>>>> >>>>>> 2) Define a series of systems which implement that channel (websocket, GCM, carrier pigeon) >>>>> >>>>> >>>>> this is just 'js' client api... so... there will be only SockJS (websocket and legacy fallbacks). No GCM/APNs receiving in JS land (pure mobile web). >>>>> >>>>>> >>>>>> 3) Have AG Auto negotiate systems. (When the app is up use a websocket system, when it background use GCM, and when the network is down scan QR codes off pigeons) >>>>> >>>>> >>>>> I guess anwser to 2) makes sense here ? >>>>> >>>>>> >>>>>> >>>>>> ? >>>>>> >>>>>> Summers >>>>>> >>>>>> >>>>>> >>>>>> On 02/21/2013 12:38 PM, Matthias Wessendorf 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 >>>> >>>> >>>> >>>> >>>> -- >>>> 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 > > > _______________________________________________ > 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

On Tue, Feb 26, 2013 at 2:37 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: > > On Feb 26, 2013, at 7:34 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: > >> On Tue, Feb 26, 2013 at 2:24 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: >>> >>> On Feb 26, 2013, at 6:56 AM, Kris Borchers <kris(a)redhat.com&gt; wrote: >>> >>>> These are all good thoughts. I was basically just implementing this far enough to get your example working so there is still a lot missing. Other comments in line. >>>> >>>> On Feb 26, 2013, at 1:59 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: >>>> >>>>> Nice, >>>>> >>>>> a few questions: >>>>> >>>>> * autoConnect - hrm... looking at the usage, I think for messaging it >>>>> may be more desired to have an explicit 'connect()' hook; >>>> >>>> There is one. I could have set it up with autoConnect: false and then explicitly called connect() when I was ready. >>>>> >>>>> * setting up everything up front is OK... but usually you want to be >>>>> able to 'subscribe' to a channel/topic/queue later on, which the same >>>>> 'client' >>>>> https://github.com/kborchers/vertx-push-demo/blob/aerogear/www/js/index.j... >>>> >>>> There will be this feature I just haven't gotten that far yet. I was thinking by adding/removing channels from the client, that would subscribe/unsubscribe them. >>>>> >>>>> * there is a 'onConnectError' - errors could occur in different ways >>>>> (when receiving, subscribing etc) >>>> >>>> Same as above. This will come (if there is a method for catching those errors). >>>>> >>>>> * the callback on the channel: here you directly use the 'replyTo' arg >>>>> (vertx detail), not every lib (e.g. Stomp.js) has something like that: >>>>> https://github.com/kborchers/vertx-push-demo/blob/aerogear/www/js/index.j... >>>>> >>>> >>>> This is where I'll need your help since I don't know those details so I will try to find a way to generalize additional parameters. >>> >>> Actually, looking at this more, this callback is triggered by the underlying library (vert.x) so I think have that specific param here is ok because they know they are using the vert.x adapter. I think we would just need to document the parameters for this callback in our docs. but not all 'messaging' providers do have such a 'replyTo' arg, on their callbacks. Thinking 'clean interfaces' (java weenie) it would be something like: AeroGear.Notifier.subscribe(String channel, function callback);

/// where callback -> function(message)

Or.... is it, with java script, that the different IMPLs (atmo, vertx, stomp.js, etc) would have different version of the 'subscribe'? If so... wouldn't that be (very) ugly ? >> >> not sure I like that; I think - to have some more abstractness - >> chaining them is better: >> >> So that ours just really needs the 'message' and we can (if we want) >> ignore the replyTo… > > I guess my point is that the replyTo is not in our library, that was just in the example implementation. If the user left it out, then it would still work. I don't think I would be a fan of documenting the callback as only receiving a message parameter and ignoring the replyTo since someone specifically using the vertx adapter may expect that to be available. >> >> >>> >>>> >>>>> >>>>> I am sure, more will come, when I start using it >>>>> >>>>> >>>>> -Matthias >>>>> >>>>> >>>>> On Mon, Feb 25, 2013 at 10:59 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: >>>>>> >>>>>> Soooo… >>>>>> >>>>>> That - https://github.com/kborchers/aerogear-js/tree/Notifier >>>>>> >>>>>> and >>>>>> >>>>>> That - https://github.com/kborchers/vertx-push-demo/tree/aerogear >>>>>> >>>>>> Enjoy! :D >>>>>> >>>>>> On Feb 22, 2013, at 12:13 PM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: >>>>>> >>>>>> But, as said on the first email, there is no spec right now... >>>>>> >>>>>> BUT..., yes - that's the idea behind the _abstract_ notifier API. >>>>>> >>>>>> On Fri, Feb 22, 2013 at 6:56 PM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Fri, Feb 22, 2013 at 6:53 PM, Summers Pittman <supittma(a)redhat.com&gt; wrote: >>>>>>>> >>>>>>>> So, in theory, would I be able to >>>>>>>> >>>>>>>> 1) Define a message channel (boats) >>>>>>> >>>>>>> >>>>>>> a 'pipe' :) to a server, yes. Publishing from client works. and receicing msgs on that channel works too >>>>>>> >>>>>>>> >>>>>>>> 2) Define a series of systems which implement that channel (websocket, GCM, carrier pigeon) >>>>>>> >>>>>>> >>>>>>> this is just 'js' client api... so... there will be only SockJS (websocket and legacy fallbacks). No GCM/APNs receiving in JS land (pure mobile web). >>>>>>> >>>>>>>> >>>>>>>> 3) Have AG Auto negotiate systems. (When the app is up use a websocket system, when it background use GCM, and when the network is down scan QR codes off pigeons) >>>>>>> >>>>>>> >>>>>>> I guess anwser to 2) makes sense here ? >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ? >>>>>>>> >>>>>>>> Summers >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 02/21/2013 12:38 PM, Matthias Wessendorf 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 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> 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 >>> >>> >>> _______________________________________________ >>> 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

> we have no control over what the underlying library passes to the callback. I guess we could write some intermediary process that intercepts the callback and reformats it to just provide a message but I > feel like that would limit people that want access to those other parameters that the library for which we provide an "adapter" is providing. I think the real problem is this, having different impls: vert.x -> subscribe("channel", function(msg, replyTo)); stomp.js -> subscribe("channel", function(msg)); but how to 'hide' behind a unified API ? a) ignoring 'un common' args (e.g. the replyTo, on vertx) b) having different subscribes -> ugly API Or am I not seeing something, obvious, specific to JS ? -- 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