[aerogear-dev] Java Sender API - fire&forget - adding callback methods?

[Sebastien Blanc]

To give a bit more concrete "material" , I've submitted a first PR
https://github.com/aerogear/aerogear-unifiedpush-java-client/pull/24 ,
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 at 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 at 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 at 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 at 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 at redhat.com>
>> wrote:
>>
>> On Thu, 19 Sep 2013 10:13:52 -0400
>>
>>    Summers Pittman <supittma at 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 at 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 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
>> >
>> > _______________________________________________
>> > 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 listaerogear-dev at lists.jboss.orghttps://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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20131018/fb9d8e9c/attachment-0001.html