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

On Tue, Jun 11, 2013 at 9:25 AM, Sebastien Blanc <scm.blanc(a)gmail.com&gt;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&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

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&gt;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(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 >> >> _______________________________________________ >> 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

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&gt;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 >>> > wrote: >>> >>>> >>>> >>>> >>>> On Tue, Jun 11, 2013 at 9:25 AM, Sebastien Blanc <scm.blanc(a)gmail.com&gt;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

+1 On Tue, Jun 11, 2013 at 2:18 PM, Sebastien Blanc <scm.blanc(a)gmail.com&gt;wrote: > 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&gt; wrote: >>> >>>> >>>> >>>> >>>> On Tue, Jun 11, 2013 at 10:04 AM, Sebastien Blanc <scm.blanc(a)gmail.com >>>> > 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&gt; 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 > -- 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