,
please feel free to comment on it on specific points, for more general
discussions let's keep using this thread.
On Thu, Oct 17, 2013 at 2:23 PM, Sebastien Blanc <scm.blanc(a)gmail.com>wrote:
We could also propose both in the same callback, a bit ala JavaScript
:
meaning offering also an 'onSuccess' (for 2xx) with still the 'complete'
which will be called anyway. Could be a nice convenience method for
slackers.
On Thu, Oct 17, 2013 at 2:20 PM, Lucas Holmquist <lholmqui(a)redhat.com>wrote:
> I'm a bit partial to option 2 since that is how we do it in JS, however;
> there is a pattern in node where there is one callback that is passed an
> error argument( if available ). something like this gist
>
https://gist.github.com/lholmquist/7023904
>
> although either way, we are determining what is an error
>
> On Oct 17, 2013, at 7:25 AM, Apostolos Emmanouilidis <aemmanou(a)redhat.com>
> wrote:
>
> + 1 on letting the client decide what status is considered as success
> (version 1)
>
> On Thu, 2013-10-17 at 13:21 +0200, Sebastien Blanc wrote:
>
> So I started to look more closely to this, and I'm wondering how we want
> the Callback to be. I see 2 options that are described here :
>
https://gist.github.com/sebastienblanc/7023151
>
>
>
> Basically, version 1 has a 'completed' method which will be invoked no
> matter which http status code is returned, the developer has than to
> implement it's own logic of handling the status. The 'failure' method
will
> be invoked in case of an exception is thrown (IOException for instance)
>
>
>
> Version 2 has a 'onSuccess' method which handles the 2xx response codes
> and a 'onError' which handles 4xx, 5xx codes or even if an exception
> has occurred.
>
>
>
> Do you have any preference or even an alternative solution ?
>
>
>
> Seb
>
>
>
>
>
>
>
>
>
>
> On Tue, Oct 8, 2013 at 3:14 PM, Sebastien Blanc <scm.blanc(a)gmail.com>
> wrote:
>
> FYI Karel has created a Jira for this
>
https://issues.jboss.org/browse/AGPUSH-373
>
>
>
>
>
> On Tue, Sep 24, 2013 at 11:43 AM, Karel Piwko <kpiwko(a)redhat.com>
> wrote:
>
> On Thu, 19 Sep 2013 10:13:52 -0400
>
> Summers Pittman <supittma(a)redhat.com> wrote:
>
> > On 09/18/2013 09:37 AM, Karel Piwko wrote:
> > > On Wed, 18 Sep 2013 09:31:36 -0400
> > > Summers Pittman <supittma(a)redhat.com> wrote:
> > >
> > >> On 09/17/2013 11:17 AM, Karel Piwko wrote:
> > >>> Hi,
> > >>>
> > >>> I went once again through
> > >>>
http://lists.jboss.org/pipermail/aerogear-dev/2013-June/002901.html-
> > >>> which says that Sender API should be fire&forget. It feels more
like
> > >>> "maybe fire"&forget, for instance it does not say
that your
> credentials
> > >>> were wrong
> > >>> - or it says, you need parse logs to get that information.
> > >>>
> > >>> If I think about Android, iOS, JS solutions to communicate with
> > >>> UnifiedPush we provide - Pipes - they always provide a callback to
> be
> > >>> executed on success/failure. Could we add callback to Sender API?
Or
> > >>> should not Aerogear rather have something like Pipes abstraction
> for Java
> > >>> developers instead of pretty dumb Sender API?
> > >>>
> > >>> Thoughts?
> > >> In a bit of crazy land perhaps the client could keep a web socket or
> BSD
> > >> Socket open to the server which would let it get callbacks about
> things
> > >> that happen further down the tree.
> > > Isn't this land called vert.x?
> > Maybe I misunderstood. I thought it was wanting to get information from
> > the push server about the status of messages being sent not the response
> > of the commands to the push server itself.
>
>
> I was speaking about the latter.
>
>
> > >
> > >>> Thanks,
> > >>>
> > >>> Karel
> > >>> _______________________________________________
> > >>> 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
> >
> > _______________________________________________
> > 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
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
>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>