2:53 a.m.
On Tue, Jun 11, 2013 at 9:25 AM, Sebastien Blanc <scm.blanc(a)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"
* 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(a)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/ae...
> * AsyncHttpClient:
>
>
https://github.com/matzew/ag-java-sender/blob/master/src/main/java/org/ae...
>
> One will go away, time will tell... not important now...
>
> Tests:
>
>
https://github.com/matzew/ag-java-sender/tree/master/src/test/java/org/ae...
>
>
> 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(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
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf