main idea is to have a common api for different backends; if userA has two apps, one uses vert.x and another one uses stomp/jms the experience would be the same, using the common api, instead of having different apis; also getting rid of some boilerplate code may be a good example (like the (rest) pipe) too. On Fri, Mar 1, 2013 at 6:23 PM, gorkem.ercan <gorkem.ercan(a)gmail.com&gt; wrote: > > This may have been discussed earlier. What is the targeted benefit other > than the unified client? > > Do we see that a single app is using more than one of these backends? Or is > there a target to provide a messaging channel through controller perhaps? > > Just curious. > > -- > Gorkem > > > On Feb 21, 2013, at 7:38 PM, Matthias Wessendorf [via aerogear-dev] <[hidden > email]> 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 > <a href="x-msg://237/user/SendEmail.jtp?type=node&amp;node=1694&amp;i=0" > target="_top" rel="nofollow" link="external">[hidden email] > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > ________________________________ > If you reply to this email, your message will be added to the discussion > below: > http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-AeroGear-Notifier-... > To unsubscribe from aerogear-dev, click here. > NAML > > > > ________________________________ > View this message in context: Re: [aerogear-dev] [AeroGear-Notifier] Client > API > Sent from the aerogear-dev mailing list archive at Nabble.com. > > _______________________________________________ > 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