On Feb 26, 2013, at 7:34 AM, Matthias Wessendorf <matzew(a)apache.org> wrote:
> On Tue, Feb 26, 2013 at 2:24 PM, Kris Borchers <kris(a)redhat.com> wrote:
>>
>> On Feb 26, 2013, at 6:56 AM, Kris Borchers <kris(a)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(a)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.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>
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> 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> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, Feb 22, 2013 at 6:53 PM, Summers Pittman
<supittma(a)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(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