Re: [aerogear-dev] [AeroGear-Notifier] Client API
I don't see them as different subscribes, just different sets of arguments passed to
callback. Maybe this will help illustrate.
If you look at
https://github.com/kborchers/aerogear-js/blob/Notifier/src/notifier/adapt...,
you'll see that the callback is just passed directly to the underlying library with no
concern for what arguments are used. This will eventually be moved to a subscribe() method
but I just did it in connect right now. Anyway, this means the API for any adapter would
be the same and the difference in arguments would just need to be documented. Does that
make sense? Is that any better?
On Feb 26, 2013, at 7:56 AM, Matthias Wessendorf <matzew(a)apache.org> wrote:
> 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
Attachments:
- attachment.html (text/html — 2.6 KB)