[aerogear-dev] [Unified Push] Java Sender API

Tue Jun 11 08:53:26 EDT 2013

https://github.com/matzew/ag-java-sender/pull/2

On Tue, Jun 11, 2013 at 2:21 PM, Matthias Wessendorf <matzew at apache.org>wrote:

> +1
>
>
> On Tue, Jun 11, 2013 at 2:18 PM, Sebastien Blanc <scm.blanc at gmail.com>wrote:
>
>> Okay now that we agreed that the client should report in case of failure,
>> I would like to submit a PR for that, throwing a exception is what we want
>> here no ? Custom exception JavaSenderException of smt similar ?
>>
>>
>>
>> On Tue, Jun 11, 2013 at 10:24 AM, Matthias Wessendorf <matzew at apache.org>wrote:
>>
>>>
>>>
>>>
>>> On Tue, Jun 11, 2013 at 10:20 AM, Sebastien Blanc <scm.blanc at gmail.com>wrote:
>>>
>>>>
>>>>
>>>>
>>>> On Tue, Jun 11, 2013 at 10:16 AM, Matthias Wessendorf <
>>>> matzew at apache.org> wrote:
>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Jun 11, 2013 at 10:04 AM, Sebastien Blanc <scm.blanc at gmail.com
>>>>> > wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, Jun 11, 2013 at 9:53 AM, Matthias Wessendorf <
>>>>>> matzew at apache.org> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Jun 11, 2013 at 9:25 AM, Sebastien Blanc <
>>>>>>> scm.blanc at gmail.com> wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>> I start looking at the repo. I have some general questions and then
>>>>>>>> more (not that much implementation detailed ;) ) specific  proposals
>>>>>>>>
>>>>>>>> *  Is our final goal to propose an implementation that we really
>>>>>>>> want the developers to use or is it more providing a reference
>>>>>>>> implementation of the sender API and developer will most of the time
>>>>>>>> implement their own ?
>>>>>>>>
>>>>>>>
>>>>>>> The goal is, to give them a Java Utility to use to for sending. If
>>>>>>> they want, they can still do the HTTP by hand. Ideally we have this
>>>>>>> "client" for other platforms as well:
>>>>>>> * Node.js, Ruby, PHP etc
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> * How are we going to secure the API ?
>>>>>>>>
>>>>>>>
>>>>>>> Once the endpoints are secured, we will leverage that on the client
>>>>>>> side (e.g. function to specifiy the "credentials")
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> * The API looks like now "fire & forget", do we plan to change that
>>>>>>>> ?
>>>>>>>>
>>>>>>> It is fire and forget.
>>>>>>>
>>>>>>>
>>>>>>>> I can imagine that people using the sender need to have some
>>>>>>>> "feedback/return value/response" to manage their flows ?
>>>>>>>>
>>>>>>>
>>>>>>> Well, we do not really have much control there. Apple, for instance,
>>>>>>> does also not really tell you: "I could not deliver the push message to Mr.
>>>>>>> XYZ". Similar is google.
>>>>>>> They all  have "feedback" service, that's more "here is a list of
>>>>>>> invalid device tokens". This info should NEVER be returned, from our
>>>>>>> Sender-Endpoint.
>>>>>>>
>>>>>>> Other cloud providers do similar: HTTP 200 + "Thanks we got your
>>>>>>> job, it is now being processed by our system"
>>>>>>>
>>>>>>
>>>>>> I agree that we don't have control between "our" systems and
>>>>>> Google's/Apple's networks. But, between our push server and our backend
>>>>>> server, the chance is bigger that the dev has more control.
>>>>>>
>>>>>
>>>>> Not nessacarially, the PushEE could be run by the "ops department",
>>>>> and different groups, within one company just use it to send messages.
>>>>>
>>>>>
>>>>>>  The thing is that the sender api now "swallow" the http status, just
>>>>>> making the http status available for the backend app using the sender API
>>>>>> will be a nice benefit (there could be no connection between our pushee and
>>>>>> our backend app for instance) ...
>>>>>>
>>>>>
>>>>> If PushEE is not reachable, the client would fail, and will(should:))
>>>>> report that back. This like that (low level http), we should report back.
>>>>> but nothing about the actual send (the communication from PushEE ->
>>>>> PushNetworks)
>>>>>
>>>>
>>>> Okay :)  "and will(should:)) report that back" was just what I wanted
>>>> to point out !
>>>>
>>>
>>>
>>>  Ah, - OK.
>>>
>>>
>>>
>>>>
>>>>> -M
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> * You say one will go away, why is that ? Do we want to lean toward
>>>>>>>> a single implementation ?
>>>>>>>>
>>>>>>>
>>>>>>> For Java, I do not see a reason in supporting two "client". I did
>>>>>>> start with AsyncHttpClient and RestEasy client. I was hoping to see
>>>>>>> odds/benefits in one....
>>>>>>> Looking at the code, I think I do prefer using the RestEasy inside
>>>>>>> of our Java-Sender....
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>  We could propose different ones (and in different language, like a
>>>>>>>> vertx mod client)
>>>>>>>>
>>>>>>>
>>>>>>> of course, but that's that's outside of the "java lib" we are
>>>>>>> talking about here.  Surely, we can have a vertx-sender, node-sender etc
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> So, now a bit more specific :
>>>>>>>> I've been forking your repo :
>>>>>>>> https://github.com/sebastienblanc/ag-java-sender/tree/refactoring
>>>>>>>>
>>>>>>>> To factor more code and make the sender API really unit testable
>>>>>>>> (running without any server) I've moved a bit things and introduced a sort
>>>>>>>> of Client interface that will implement really the http client we will use,
>>>>>>>> this client is then injected in the sender interface.
>>>>>>>>
>>>>>>>
>>>>>>> that is nice. The project is simple now, and was written while I was
>>>>>>> hacking the sender endpoints - that way I could avoid sending lot's of
>>>>>>> CURLs ;-)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> With Arquillian should be easy to add real integration tests.
>>>>>>>>
>>>>>>>
>>>>>>> sounds good
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Let's discuss !
>>>>>>>> Sebi
>>>>>>>>
>>>>>>>>
>>>>>>>>  On Mon, Jun 3, 2013 at 9:00 PM, Matthias Wessendorf <
>>>>>>>> matzew at apache.org> wrote:
>>>>>>>>
>>>>>>>>>  Hello,
>>>>>>>>>
>>>>>>>>> a FIRST version of the Java Sender API is ready:
>>>>>>>>> https://github.com/matzew/ag-java-sender
>>>>>>>>>
>>>>>>>>> Two implementations, based on different Java HTTP clients:
>>>>>>>>> * RestEasy:
>>>>>>>>>
>>>>>>>>> https://github.com/matzew/ag-java-sender/blob/master/src/main/java/org/aerogear/unifiedpush/resteasy/RestEasyJavaSender.java
>>>>>>>>> * AsyncHttpClient:
>>>>>>>>>
>>>>>>>>> https://github.com/matzew/ag-java-sender/blob/master/src/main/java/org/aerogear/unifiedpush/async/AsyncJavaSender.java
>>>>>>>>>
>>>>>>>>> One will go away, time will tell... not important now...
>>>>>>>>>
>>>>>>>>> Tests:
>>>>>>>>>
>>>>>>>>> https://github.com/matzew/ag-java-sender/tree/master/src/test/java/org/aerogear/unifiedpush
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> More functionality (e.g. selective send for deviceType,
>>>>>>>>> MobileVariant) will follow, hand in hand with the matching endpoints
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -Matthias
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> 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
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> 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
>>
>
>
>
> --
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20130611/0f6c5054/attachment-0001.html 