On Tue, Jun 11, 2013 at 10:04 AM, Sebastien Blanc <scm.blanc@gmail.com> wrote:



On Tue, Jun 11, 2013 at 9:53 AM, Matthias Wessendorf <matzew@apache.org> wrote:



On Tue, Jun 11, 2013 at 9:25 AM, Sebastien Blanc <scm.blanc@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 :

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@apache.org> wrote:
Hello,

a FIRST version of the Java Sender API is ready:

Two implementations, based on different Java HTTP clients:
* RestEasy:
* AsyncHttpClient:

One will go away, time will tell... not important now...

Tests:


More functionality (e.g. selective send for deviceType, MobileVariant) will follow, hand in hand with the matching endpoints


-Matthias



_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev

_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
aerogear-dev@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