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

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(a)apache.org&gt;wrote: > > > > On Tue, Jun 11, 2013 at 10:20 AM, Sebastien Blanc <scm.blanc(a)gmail.com&gt;wrote: > >> >> >> >> On Tue, Jun 11, 2013 at 10:16 AM, Matthias Wessendorf <matzew(a)apache.org >> > wrote: >> >>> >>> >>> >>> On Tue, Jun 11, 2013 at 10:04 AM, Sebastien Blanc <scm.blanc(a)gmail.com&gt;wrote: >>> >>>> >>>> >>>> >>>> On Tue, Jun 11, 2013 at 9:53 AM, Matthias Wessendorf < >>>> matzew(a)apache.org&gt; wrote: >>>> >>>>> >>>>> >>>>> >>>>> 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" >>>>> >>>> >>>> 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(a)apache.org&gt; 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 >>>>> >>>>> _______________________________________________ >>>>> 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 >>> >>> _______________________________________________ >>> 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 > > _______________________________________________ > 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