[aerogear-dev] [AeroGear-Notifier] Client API
Kris Borchers
kris at redhat.com
Tue Feb 26 08:46:47 EST 2013
On Feb 26, 2013, at 7:41 AM, Matthias Wessendorf <matzew at apache.org> wrote:
> On Tue, Feb 26, 2013 at 2:37 PM, Kris Borchers <kris at redhat.com> wrote:
>>
>> On Feb 26, 2013, at 7:34 AM, Matthias Wessendorf <matzew at apache.org> wrote:
>>
>>> On Tue, Feb 26, 2013 at 2:24 PM, Kris Borchers <kris at redhat.com> wrote:
>>>>
>>>> On Feb 26, 2013, at 6:56 AM, Kris Borchers <kris at redhat.com> 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 at apache.org> 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.js#L31
>>>>>
>>>>> 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.js#L33
>>>>>>
>>>>>
>>>>> 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);
This is exactly what I'm proposing, but ...
> /// where callback -> function(message)
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.
>
> 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 at redhat.com> 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 at apache.org> 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 at apache.org> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Fri, Feb 22, 2013 at 6:53 PM, Summers Pittman <supittma at redhat.com> 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 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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> 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
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
More information about the aerogear-dev
mailing list