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

[Sebastien Blanc]

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. 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) ...


>
>
>>
>> * 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20130611/9f5a51ff/attachment-0001.html