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

Tue Jun 11 04:16:59 EDT 2013

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)

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