From qmx at qmx.me Sat Feb 1 16:08:00 2014 From: qmx at qmx.me (Douglas Campos) Date: Sat, 1 Feb 2014 19:08:00 -0200 Subject: [aerogear-dev] [aerogear-js] portable/fallback-able data migrations? Message-ID: <20140201210800.GM61817@rohan.local> There's a nice feature on IndexedDB which is the version thing + 'upgrade needed' event[1], which we're using for creating the database automagically[2]. Any ideas on how could we provide an API for something like this, but which could potentially work with WebSQL too? var dm = AeroGear.DataManager(); dm.add({ name: "newStore", storageType: "IndexedDB", settings: { dbVersion: 3, upgradeHandler: function (evt) { // evt.oldVersion // evt.newVersion // evt.store // do data migration stuff, just caring about objects } } }); How does this sounds? Am I crazier than usual? :) [1]:https://developer.mozilla.org/en/docs/IndexedDB/Using_IndexedDB#Creating_or_updating_the_version_of_the_database [2]:https://github.com/aerogear/aerogear-js/blob/master/src/data-manager/adapters/indexeddb.js#L181-L184 -- qmx -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 527 bytes Desc: not available Url : http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140201/4efb3410/attachment.bin From kpiwko at redhat.com Mon Feb 3 03:49:41 2014 From: kpiwko at redhat.com (Karel Piwko) Date: Mon, 3 Feb 2014 09:49:41 +0100 Subject: [aerogear-dev] Sync Day 3 Sync takes Manhattan In-Reply-To: <52EA7A28.1050404@redhat.com> References: <52EA6E63.5060505@redhat.com> <52EA7A28.1050404@redhat.com> Message-ID: <20140203094941.4161d323@kapy-ntb-x220> On Thu, 30 Jan 2014 11:13:28 -0500 Summers Pittman wrote: > On 01/30/2014 11:03 AM, Matthias Wessendorf wrote: > > > > > > > > On Thu, Jan 30, 2014 at 4:23 PM, Summers Pittman > > wrote: > > > > I rolled up the feedback to the email I sent yesterday. > > > > One quick note, this is not a 0.1.0 plan nor a 1.0.0 plan. It is > > probably closer to a 1.5 or 2.0 plan in terms of scope. > > > > > > ahm... thinking about 2.0.0 before we have a 1.0.0 ? Not sure I > > understand that > The point I was trying to make is that I'm not expecting everything on > here to get done quickly from top to bottom and slap 1.0 on it sometime > in May. Also that I am expecting to have several releases made during > the production of points on this list. Yay! That's was exactly my point for QE CI challenges. From daniel.bevenius at gmail.com Mon Feb 3 07:35:39 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Mon, 3 Feb 2014 13:35:39 +0100 Subject: [aerogear-dev] Team meeting agenda Message-ID: http://oksoclap.com/p/aerogear-team-mgt-20140203 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140203/a7f2d0e5/attachment.html From lholmqui at redhat.com Mon Feb 3 08:38:18 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Mon, 3 Feb 2014 08:38:18 -0500 Subject: [aerogear-dev] bower repos for custom builds In-Reply-To: <20140131204202.GG61817@rohan.local> References: <8B1AE989-453D-456E-8911-D1E4F31084D1@redhat.com> <20140128190852.GH20528@rohan.local> <20140131204202.GG61817@rohan.local> Message-ID: On Jan 31, 2014, at 3:42 PM, Douglas Campos wrote: > On Tue, Jan 28, 2014 at 02:13:05PM -0500, Lucas Holmquist wrote: >> >> On Jan 28, 2014, at 2:08 PM, Douglas Campos wrote: >> >>> On Tue, Jan 28, 2014 at 09:40:47AM -0500, Lucas Holmquist wrote: >>>> so i created this JIRA https://issues.jboss.org/browse/AGJS-133 >>>> >>>> It would kind of neat if we offered some custom builds in bower, >>>> >>>> this way it could make it super easy for someone to pull in just data >>>> manager for example >>>> >>>> $ bower install aerogear-datamanager > > One of the things we briefly talked on IRC that I promised to post here: > > I was (naively) thinking that this command would bring this to the app: > > - aerogear-datamanager.js > +-- aerogear-core.js (as a dependency) currently the builds in the AeroGear-components repo's are basically the result of running $ grunt data-manager // or pipeline, or whatever so aerogear.core.js and all related dependencies are built it. since bower is basically just a front end on top of curl this is nice if someone is just using one thing, but if they want more than 1 "component", code will start to get duplicated, although each "component" is in it's own closure(IIFE), so they shouldn't mess with each other, but still. 1 solution is to break core into it's own repo and add it to the components dependency so only one copy would exist, but the user would have to remember to include that in there script declarations and that would sort of break the IIFE that is suppose to enclose the whole thing this is where AMD might come in, not sure. i know dojo breaks there components into pieces and each one has to be included, although i haven't played with it. At this point i'm not really sure if AMDifiying the library is worth it, i need to do more research on how to break things up > > So, what do we need to do to have something like this? Is AMD-ifying the > project the only solution for having this? > >> at the moment we only have "official releases", but it would be >> interesting to have the "development release" also available since >> these are really just tags > > Hmm, but wouldn't this mean we just end up with a ton of tags? if people > want to use development builds they can point to the repo, can't they? > > -- > qmx > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From lholmqui at redhat.com Mon Feb 3 08:40:49 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Mon, 3 Feb 2014 08:40:49 -0500 Subject: [aerogear-dev] [aerogear-js] portable/fallback-able data migrations? In-Reply-To: <20140201210800.GM61817@rohan.local> References: <20140201210800.GM61817@rohan.local> Message-ID: On Feb 1, 2014, at 4:08 PM, Douglas Campos wrote: > There's a nice feature on IndexedDB which is the version thing + > 'upgrade needed' event[1], which we're using for creating the database > automagically[2]. > > Any ideas on how could we provide an API for something like this, but > which could potentially work with WebSQL too? > > var dm = AeroGear.DataManager(); > dm.add({ > name: "newStore", > storageType: "IndexedDB", > settings: { > dbVersion: 3, > upgradeHandler: function (evt) { > // evt.oldVersion > // evt.newVersion > // evt.store > // do data migration stuff, just caring about objects > } > } > }); > > How does this sounds? Am I crazier than usual? :) not sure we really need this since the user doesn't actually created and of the "fields". there is a field for an id and the other is the json data, so the user never interacts with modifying the db > > > [1]:https://developer.mozilla.org/en/docs/IndexedDB/Using_IndexedDB#Creating_or_updating_the_version_of_the_database > [2]:https://github.com/aerogear/aerogear-js/blob/master/src/data-manager/adapters/indexeddb.js#L181-L184 > > -- > qmx_______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From hbons at redhat.com Mon Feb 3 08:44:38 2014 From: hbons at redhat.com (Hylke Bons) Date: Mon, 03 Feb 2014 13:44:38 +0000 Subject: [aerogear-dev] Let's change the AeroGear Twitter account handle In-Reply-To: References: <52EA3687.2050601@redhat.com> <52EA39C6.8020607@redhat.com> Message-ID: <52EF9D46.6000306@redhat.com> I've compiled a list of handles that are less problematic and available. From short to long: @_AeroGear_ @AeroGearOrg @AeroGearTeam @AeroGearNews @JBossAeroGear @AeroGearMobile @AeroGearTweets Hylke On 30/01/2014 12:33, Matthias Wessendorf wrote: > > > > On Thu, Jan 30, 2014 at 12:38 PM, Hylke Bons > wrote: > > You are right that it may be a bit long for replies. > "@AGTeam" or "@AGProject" could work too (if they weren't already > taken but something amongst those line :). > > > not sure if AGTeam/Project is really 'cool' > > > > Hylke > > > On 30/01/2014 11:29, Matthias Wessendorf wrote: >> >> >> >> On Thu, Jan 30, 2014 at 12:24 PM, Hylke Bons > > wrote: >> >> "@AeroGears" can cause confusion about what the project name >> really is. >> >> >> All the JUGs I presented at, and some conferences call the >> project already "AeroGears", due to the tiwtter handle :-) >> >> >> Options to fix: >> - Ask the owner of @AeroGear if he or she want to give up the >> handle >> >> >> are we also offering 50k ? :) >> >> - Change the handle to "@AeroGearTeam" or "@AeroGearProject", or >> something else >> >> >> I think the 'concern' was that the name is too long, but on the >> other hand, there is some sort of confusion w/ our actual name :-0 >> >> If I had to pick one out of those that you suggested it would be >> 'AeroGearTeam', that's exactly just three chars longer than the >> current :) >> >> -M >> >> >> >> >> Thoughts? >> >> Hylke >> _______________________________________________ >> 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 > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140203/cd6825a7/attachment-0001.html From hbons at redhat.com Mon Feb 3 08:50:17 2014 From: hbons at redhat.com (Hylke Bons) Date: Mon, 03 Feb 2014 13:50:17 +0000 Subject: [aerogear-dev] Website restructure In-Reply-To: <9BBFBABA-AE49-45B4-B835-5B1F6F65BE5C@gmail.com> References: <2A4CF6B8-B8DD-4E31-B764-C7452CD99D19@redhat.com> <20140120123559.3a3aec13@kapy-ntb-x220> <52DE6B7B.6050202@redhat.com> <20140122130302.233deb81@kapy-ntb-x220> <52DFC3ED.2060405@redhat.com> <52E2AC04.1010306@redhat.com> <08ABCD4D-AF15-4D55-92B3-CC46A4BD9E08@gmail.com> <3B1CEC27-5A2C-48BA-A016-877A2987CD9E@gmail.com> <9BBFBABA-AE49-45B4-B835-5B1F6F65BE5C@gmail.com> Message-ID: <52EF9E99.1080503@redhat.com> On 28/01/2014 08:26, Corinne Krych wrote: >> >>> >>> Actually if you setup the sass batch link[1], you run your >>> environment and then you go to link[2] loclhost as it's running on >>> our instance, you will see i've tried it out for Pipes. In order to >>> do it i needed to split the documentation for iOS/Android (I haven't >>> done completely JS part). with this exercice what i understand is: >>> 1. the first view should contain code snippet with shows the unified >>> aspect of client lib. those sippet are not complete code, it should >>> be simplified. >>> 2. this simplified view is not enough for a developer. Selecting his >>> platform tab, he will be redirected to android for ex complete >>> description on Pipes. Ideally this description is based on a >>> cookbook exemple. >>> 3. if the developer want to test it himself he'll have the option to >>> download the complete sample code (github link to cookbook repo) and >>> just run it >>> >>> So the explantion goes through 3 layers from 1)high level >>> description (cross platform), 2) detailled explanation linked to a >>> platform to 3) sample code implementation (obvious linked to a >>> platform). >>> >>> My question is How to make the transition from 1) to 2) ? See >>> picture below >>> > > > https://www.dropbox.com/s/tz25vzu8doh6jkk/agorg2.png > > Alright, that makes sense. I have some ideas about this. I'll update the mockups and send the to you. Hylke -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140203/17956d24/attachment.html From lholmqui at redhat.com Mon Feb 3 08:52:23 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Mon, 3 Feb 2014 08:52:23 -0500 Subject: [aerogear-dev] Let's change the AeroGear Twitter account handle In-Reply-To: <52EF9D46.6000306@redhat.com> References: <52EA3687.2050601@redhat.com> <52EA39C6.8020607@redhat.com> <52EF9D46.6000306@redhat.com> Message-ID: <953401D5-1AA2-44BB-8240-859183299450@redhat.com> On Feb 3, 2014, at 8:44 AM, Hylke Bons wrote: > I've compiled a list of handles that are less problematic and available. Seriously though, is this really problematic? > From short to long: > > @_AeroGear_ > @AeroGearOrg > @AeroGearTeam > @AeroGearNews > @JBossAeroGear > @AeroGearMobile > @AeroGearTweets > > Hylke > > > > On 30/01/2014 12:33, Matthias Wessendorf wrote: >> >> >> >> On Thu, Jan 30, 2014 at 12:38 PM, Hylke Bons wrote: >> You are right that it may be a bit long for replies. >> "@AGTeam" or "@AGProject" could work too (if they weren't already taken but something amongst those line :). >> >> not sure if AGTeam/Project is really 'cool' >> >> >> Hylke >> >> >> On 30/01/2014 11:29, Matthias Wessendorf wrote: >>> >>> >>> >>> On Thu, Jan 30, 2014 at 12:24 PM, Hylke Bons wrote: >>> "@AeroGears" can cause confusion about what the project name really is. >>> >>> All the JUGs I presented at, and some conferences call the project already "AeroGears", due to the tiwtter handle :-) >>> >>> >>> Options to fix: >>> - Ask the owner of @AeroGear if he or she want to give up the handle >>> >>> are we also offering 50k ? :) >>> >>> - Change the handle to "@AeroGearTeam" or "@AeroGearProject", or >>> something else >>> >>> I think the 'concern' was that the name is too long, but on the other hand, there is some sort of confusion w/ our actual name :-0 >>> >>> If I had to pick one out of those that you suggested it would be 'AeroGearTeam', that's exactly just three chars longer than the current :) >>> >>> -M >>> >>> >>> >>> >>> >>> Thoughts? >>> >>> Hylke >>> _______________________________________________ >>> 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 >> >> >> _______________________________________________ >> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140203/be3aff85/attachment.html From matzew at apache.org Mon Feb 3 08:56:13 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 3 Feb 2014 14:56:13 +0100 Subject: [aerogear-dev] Let's change the AeroGear Twitter account handle In-Reply-To: <953401D5-1AA2-44BB-8240-859183299450@redhat.com> References: <52EA3687.2050601@redhat.com> <52EA39C6.8020607@redhat.com> <52EF9D46.6000306@redhat.com> <953401D5-1AA2-44BB-8240-859183299450@redhat.com> Message-ID: On Mon, Feb 3, 2014 at 2:52 PM, Lucas Holmquist wrote: > > On Feb 3, 2014, at 8:44 AM, Hylke Bons wrote: > > I've compiled a list of handles that are less problematic and available. > > Seriously though, is this really problematic? > Not sure if it is problematic, but since we use @AerogearS, 90% of the folks think that is the actual name of the project :-) > > From short to long: > > @_AeroGear_ > @AeroGearOrg > @AeroGearTeam > @AeroGearNews > @JBossAeroGear > @AeroGearMobile > @AeroGearTweets > > Hylke > > > > On 30/01/2014 12:33, Matthias Wessendorf wrote: > > > > > On Thu, Jan 30, 2014 at 12:38 PM, Hylke Bons wrote: > >> You are right that it may be a bit long for replies. >> "@AGTeam" or "@AGProject" could work too (if they weren't already taken >> but something amongst those line :). >> > > not sure if AGTeam/Project is really 'cool' > >> >> >> Hylke >> >> >> On 30/01/2014 11:29, Matthias Wessendorf wrote: >> >> >> >> >> On Thu, Jan 30, 2014 at 12:24 PM, Hylke Bons wrote: >> >>> "@AeroGears" can cause confusion about what the project name really is. >>> >> >> All the JUGs I presented at, and some conferences call the project >> already "AeroGears", due to the tiwtter handle :-) >> >> >>> >>> Options to fix: >>> - Ask the owner of @AeroGear if he or she want to give up the handle >>> >> >> are we also offering 50k ? :) >> >> >>> - Change the handle to "@AeroGearTeam" or "@AeroGearProject", or >>> something else >>> >> >> I think the 'concern' was that the name is too long, but on the other >> hand, there is some sort of confusion w/ our actual name :-0 >> >> If I had to pick one out of those that you suggested it would be >> 'AeroGearTeam', that's exactly just three chars longer than the current :) >> >> -M >> >> >> >> >> >>> >>> Thoughts? >>> >>> Hylke >>> _______________________________________________ >>> 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 listaerogear-dev at lists.jboss.orghttps://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 listaerogear-dev at lists.jboss.orghttps://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 > > > > _______________________________________________ > 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/20140203/bc8b17cd/attachment-0001.html From hbons at redhat.com Mon Feb 3 08:56:28 2014 From: hbons at redhat.com (Hylke Bons) Date: Mon, 03 Feb 2014 13:56:28 +0000 Subject: [aerogear-dev] Let's change the AeroGear Twitter account handle In-Reply-To: <953401D5-1AA2-44BB-8240-859183299450@redhat.com> References: <52EA3687.2050601@redhat.com> <52EA39C6.8020607@redhat.com> <52EF9D46.6000306@redhat.com> <953401D5-1AA2-44BB-8240-859183299450@redhat.com> Message-ID: <52EFA00C.9010404@redhat.com> On 03/02/2014 13:52, Lucas Holmquist wrote: > > On Feb 3, 2014, at 8:44 AM, Hylke Bons > wrote: > >> I've compiled a list of handles that are less problematic and available. > Seriously though, is this really problematic? > According to Matthew: "All the JUGs I presented at, and some conferences call the project already "AeroGears", due to the tiwtter handle :-)" I also saw you mentioning the wrong account: https://twitter.com/sienaluke/status/428541775163035651 If we're having trouble with it, others will have too. So yes, I believe it is, and it's a trivial change. Hylke >> From short to long: >> >> @_AeroGear_ >> @AeroGearOrg >> @AeroGearTeam >> @AeroGearNews >> @JBossAeroGear >> @AeroGearMobile >> @AeroGearTweets >> >> Hylke >> >> >> >> On 30/01/2014 12:33, Matthias Wessendorf wrote: >>> >>> >>> >>> On Thu, Jan 30, 2014 at 12:38 PM, Hylke Bons >> > wrote: >>> >>> You are right that it may be a bit long for replies. >>> "@AGTeam" or "@AGProject" could work too (if they weren't >>> already taken but something amongst those line :). >>> >>> >>> not sure if AGTeam/Project is really 'cool' >>> >>> >>> >>> Hylke >>> >>> >>> On 30/01/2014 11:29, Matthias Wessendorf wrote: >>>> >>>> >>>> >>>> On Thu, Jan 30, 2014 at 12:24 PM, Hylke Bons >>> > wrote: >>>> >>>> "@AeroGears" can cause confusion about what the project >>>> name really is. >>>> >>>> >>>> All the JUGs I presented at, and some conferences call the >>>> project already "AeroGears", due to the tiwtter handle :-) >>>> >>>> >>>> Options to fix: >>>> - Ask the owner of @AeroGear if he or she want to give up >>>> the handle >>>> >>>> >>>> are we also offering 50k ? :) >>>> >>>> - Change the handle to "@AeroGearTeam" or >>>> "@AeroGearProject", or >>>> something else >>>> >>>> >>>> I think the 'concern' was that the name is too long, but on the >>>> other hand, there is some sort of confusion w/ our actual name :-0 >>>> >>>> If I had to pick one out of those that you suggested it would >>>> be 'AeroGearTeam', that's exactly just three chars longer than >>>> the current :) >>>> >>>> -M >>>> >>>> >>>> >>>> >>>> Thoughts? >>>> >>>> Hylke >>>> _______________________________________________ >>>> 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 >>> >>> >>> _______________________________________________ >>> 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 > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140203/ac69ce7a/attachment.html From hbons at redhat.com Mon Feb 3 09:16:16 2014 From: hbons at redhat.com (Hylke Bons) Date: Mon, 03 Feb 2014 14:16:16 +0000 Subject: [aerogear-dev] Website restructure In-Reply-To: <74EC3F01-08E4-4612-ACCB-7E86D4A95FA2@gmail.com> References: <2A4CF6B8-B8DD-4E31-B764-C7452CD99D19@redhat.com> <20140120123559.3a3aec13@kapy-ntb-x220> <52E29F6F.7080300@redhat.com> <74EC3F01-08E4-4612-ACCB-7E86D4A95FA2@gmail.com> Message-ID: <52EFA4B0.8060506@redhat.com> On 28/01/2014 08:49, Corinne Krych wrote: > Hello Hylke, > > Somehow I can?t make AG core work in the proposed page2 and page 3 as per your screen shot, I rather have page3 in your page3 and then page 3 will be a detailled example with download link to cookbook. > > In the page2 we could have download button at the top and documentation with code snippet at he bottom. I'm a bit confused. With "page 2", do you mean the "Get it" page in the middle? What's not working out exactly? Hylke From supittma at redhat.com Mon Feb 3 09:22:00 2014 From: supittma at redhat.com (Summers Pittman) Date: Mon, 03 Feb 2014 09:22:00 -0500 Subject: [aerogear-dev] [aerogear-js] portable/fallback-able data migrations? In-Reply-To: <20140201210800.GM61817@rohan.local> References: <20140201210800.GM61817@rohan.local> Message-ID: <52EFA608.7070204@redhat.com> On 02/01/2014 04:08 PM, Douglas Campos wrote: > There's a nice feature on IndexedDB which is the version thing + > 'upgrade needed' event[1], which we're using for creating the database > automagically[2]. > > Any ideas on how could we provide an API for something like this, but > which could potentially work with WebSQL too? > > var dm = AeroGear.DataManager(); > dm.add({ > name: "newStore", > storageType: "IndexedDB", > settings: { > dbVersion: 3, > upgradeHandler: function (evt) { > // evt.oldVersion > // evt.newVersion > // evt.store > // do data migration stuff, just caring about objects > } > } > }); > > How does this sounds? Am I crazier than usual? :) Well Android does something similar so it isn't too crazy. > > > [1]:https://developer.mozilla.org/en/docs/IndexedDB/Using_IndexedDB#Creating_or_updating_the_version_of_the_database > [2]:https://github.com/aerogear/aerogear-js/blob/master/src/data-manager/adapters/indexeddb.js#L181-L184 > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140203/77fb428d/attachment.html From corinnekrych at gmail.com Mon Feb 3 09:22:23 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Mon, 3 Feb 2014 15:22:23 +0100 Subject: [aerogear-dev] Website restructure In-Reply-To: <52EFA4B0.8060506@redhat.com> References: <2A4CF6B8-B8DD-4E31-B764-C7452CD99D19@redhat.com> <20140120123559.3a3aec13@kapy-ntb-x220> <52E29F6F.7080300@redhat.com> <74EC3F01-08E4-4612-ACCB-7E86D4A95FA2@gmail.com> <52EFA4B0.8060506@redhat.com> Message-ID: <02449385-8ECC-4FE5-8313-42019DC63D49@gmail.com> ok true it?s confusing, let?s name the,: page 1 - Home page page 2- get it page 3- examples Trying to refactor page-3 in code snippets is feasable but you loose lot?s of usefull documentation which is speciific to the platform. Page-3 is some shallow exemple. in ag.org we?ve got lots of detailled docuemntation i don?t want to throw again so my suggestion was: - either aff page-4 level with detailled doc - or remove/change page-2(level-2) to be the shallow example anf page-3(level-3) become detailled ex Does it make more sense? can you see my pb on this refactoring documentation exercice? ++ Corinne On 03 Feb 2014, at 15:16, Hylke Bons wrote: > On 28/01/2014 08:49, Corinne Krych wrote: >> Hello Hylke, >> >> Somehow I can?t make AG core work in the proposed page2 and page 3 as per your screen shot, I rather have page3 in your page3 and then page 3 will be a detailled example with download link to cookbook. >> >> In the page2 we could have download button at the top and documentation with code snippet at he bottom. > I'm a bit confused. With "page 2", do you mean the "Get it" page in the middle? > What's not working out exactly? > > Hylke > From supittma at redhat.com Mon Feb 3 09:27:58 2014 From: supittma at redhat.com (Summers Pittman) Date: Mon, 03 Feb 2014 09:27:58 -0500 Subject: [aerogear-dev] Sync Day 4 Sync or Swim Message-ID: <52EFA76E.3000106@redhat.com> So This should be all of the JIRAs (epics plus sub tasks) * https://issues.jboss.org/browse/AEROGEAR-1428?jql=project%20%3D%20AEROGEAR%20AND%20component%20%3D%20data-sync%20AND%20created%20%3E%3D%20-1w%20ORDER%20BY%20created%20DESC Now we need to figure out things like versions, release dates, project specific JIRAs, etc. Me PERSONALLY I think that * https://issues.jboss.org/browse/AEROGEAR-1405 and * https://issues.jboss.org/browse/AEROGEAR-1409 leave us in a great place for a 0.1.0 release. It will have enough stuff done that we can say "yes this a product" but isn't so feature rich that we get bogged down in minutia. WDYT? From lholmqui at redhat.com Mon Feb 3 09:33:17 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Mon, 3 Feb 2014 09:33:17 -0500 Subject: [aerogear-dev] Sync Day 4 Sync or Swim In-Reply-To: <52EFA76E.3000106@redhat.com> References: <52EFA76E.3000106@redhat.com> Message-ID: <91EE6BCE-B105-46D0-9D75-4B6E8D2ECBFC@redhat.com> On Feb 3, 2014, at 9:27 AM, Summers Pittman wrote: > So This should be all of the JIRAs (epics plus sub tasks) > > * > https://issues.jboss.org/browse/AEROGEAR-1428?jql=project%20%3D%20AEROGEAR%20AND%20component%20%3D%20data-sync%20AND%20created%20%3E%3D%20-1w%20ORDER%20BY%20created%20DESC > > Now we need to figure out things like versions, release dates, project > specific JIRAs, etc. > > Me PERSONALLY I think that > * https://issues.jboss.org/browse/AEROGEAR-1405 and > * https://issues.jboss.org/browse/AEROGEAR-1409 > those look pretty good and i think we have some of POC'd already > leave us in a great place for a 0.1.0 release. It will have enough > stuff done that we can say "yes this a product" but isn't so feature > rich that we get bogged down in minutia. > > WDYT? > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From daniel.bevenius at gmail.com Mon Feb 3 09:41:25 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Mon, 3 Feb 2014 15:41:25 +0100 Subject: [aerogear-dev] Sync Day 4 Sync or Swim In-Reply-To: <91EE6BCE-B105-46D0-9D75-4B6E8D2ECBFC@redhat.com> References: <52EFA76E.3000106@redhat.com> <91EE6BCE-B105-46D0-9D75-4B6E8D2ECBFC@redhat.com> Message-ID: Just catching up on all this, but I think this looks good. On 3 February 2014 15:33, Lucas Holmquist wrote: > > On Feb 3, 2014, at 9:27 AM, Summers Pittman wrote: > > > So This should be all of the JIRAs (epics plus sub tasks) > > > > * > > > https://issues.jboss.org/browse/AEROGEAR-1428?jql=project%20%3D%20AEROGEAR%20AND%20component%20%3D%20data-sync%20AND%20created%20%3E%3D%20-1w%20ORDER%20BY%20created%20DESC > > > > Now we need to figure out things like versions, release dates, project > > specific JIRAs, etc. > > > > Me PERSONALLY I think that > > * https://issues.jboss.org/browse/AEROGEAR-1405 and > > * https://issues.jboss.org/browse/AEROGEAR-1409 > > > those look pretty good and i think we have some of POC'd already > > > > > leave us in a great place for a 0.1.0 release. It will have enough > > stuff done that we can say "yes this a product" but isn't so feature > > rich that we get bogged down in minutia. > > > > WDYT? > > _______________________________________________ > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140203/6a7a4716/attachment.html From supittma at redhat.com Mon Feb 3 09:44:54 2014 From: supittma at redhat.com (Summers Pittman) Date: Mon, 03 Feb 2014 09:44:54 -0500 Subject: [aerogear-dev] Sync Day 4 Sync or Swim In-Reply-To: References: <52EFA76E.3000106@redhat.com> <91EE6BCE-B105-46D0-9D75-4B6E8D2ECBFC@redhat.com> Message-ID: <52EFAB66.4020707@redhat.com> On Mon 03 Feb 2014 09:41:25 AM EST, Daniel Bevenius wrote: > Just catching up on all this, but I think this looks good. One quick note, I did not pay THAT much attention to what the server needs to have. I think it may be "good enough" for a 0.1.0 to have the protocol defined and the server be just an RI instead of a full product for a bit. > > > On 3 February 2014 15:33, Lucas Holmquist > wrote: > > > On Feb 3, 2014, at 9:27 AM, Summers Pittman > wrote: > > > So This should be all of the JIRAs (epics plus sub tasks) > > > > * > > > https://issues.jboss.org/browse/AEROGEAR-1428?jql=project%20%3D%20AEROGEAR%20AND%20component%20%3D%20data-sync%20AND%20created%20%3E%3D%20-1w%20ORDER%20BY%20created%20DESC > > > > Now we need to figure out things like versions, release dates, > project > > specific JIRAs, etc. > > > > Me PERSONALLY I think that > > * https://issues.jboss.org/browse/AEROGEAR-1405 and > > * https://issues.jboss.org/browse/AEROGEAR-1409 > > > those look pretty good and i think we have some of POC'd already > > > > > leave us in a great place for a 0.1.0 release. It will have enough > > stuff done that we can say "yes this a product" but isn't so feature > > rich that we get bogged down in minutia. > > > > WDYT? > > _______________________________________________ > > 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 > > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From qmx at qmx.me Mon Feb 3 09:52:02 2014 From: qmx at qmx.me (Douglas Campos) Date: Mon, 3 Feb 2014 12:52:02 -0200 Subject: [aerogear-dev] Sync Day 4 Sync or Swim In-Reply-To: <52EFAB66.4020707@redhat.com> References: <52EFA76E.3000106@redhat.com> <91EE6BCE-B105-46D0-9D75-4B6E8D2ECBFC@redhat.com> <52EFAB66.4020707@redhat.com> Message-ID: <20140203145202.GE75920@rohan.local> Could we stop even mentioning "product"? :) -- qmx From corinnekrych at gmail.com Mon Feb 3 09:53:38 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Mon, 3 Feb 2014 15:53:38 +0100 Subject: [aerogear-dev] Sync Day 4 Sync or Swim In-Reply-To: <52EFAB66.4020707@redhat.com> References: <52EFA76E.3000106@redhat.com> <91EE6BCE-B105-46D0-9D75-4B6E8D2ECBFC@redhat.com> <52EFAB66.4020707@redhat.com> Message-ID: <0C68E922-30E5-4E68-A4F4-E20B1F2BA0A6@gmail.com> On 03 Feb 2014, at 15:44, Summers Pittman wrote: > On Mon 03 Feb 2014 09:41:25 AM EST, Daniel Bevenius wrote: >> Just catching up on all this, but I think this looks good. > > One quick note, I did not pay THAT much attention to what the server > needs to have. > > I think it may be "good enough" for a 0.1.0 to have the protocol > defined and the server be just an RI instead of a full product for a What do you mean by RI? > bit. > >> >> >> On 3 February 2014 15:33, Lucas Holmquist > > wrote: >> >> >> On Feb 3, 2014, at 9:27 AM, Summers Pittman > > wrote: >> >>> So This should be all of the JIRAs (epics plus sub tasks) >>> >>> * >>> >> https://issues.jboss.org/browse/AEROGEAR-1428?jql=project%20%3D%20AEROGEAR%20AND%20component%20%3D%20data-sync%20AND%20created%20%3E%3D%20-1w%20ORDER%20BY%20created%20DESC >>> >>> Now we need to figure out things like versions, release dates, >> project >>> specific JIRAs, etc. >>> >>> Me PERSONALLY I think that >>> * https://issues.jboss.org/browse/AEROGEAR-1405 and >>> * https://issues.jboss.org/browse/AEROGEAR-1409 >>> >> those look pretty good and i think we have some of POC'd already >> >> >> >>> leave us in a great place for a 0.1.0 release. It will have enough >>> stuff done that we can say "yes this a product" but isn't so feature >>> rich that we get bogged down in minutia. >>> >>> WDYT? >>> _______________________________________________ >>> 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 >> >> >> >> >> _______________________________________________ >> 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 From supittma at redhat.com Mon Feb 3 09:54:46 2014 From: supittma at redhat.com (Summers Pittman) Date: Mon, 03 Feb 2014 09:54:46 -0500 Subject: [aerogear-dev] Sync Day 4 Sync or Swim In-Reply-To: <20140203145202.GE75920@rohan.local> References: <52EFA76E.3000106@redhat.com> <91EE6BCE-B105-46D0-9D75-4B6E8D2ECBFC@redhat.com> <52EFAB66.4020707@redhat.com> <20140203145202.GE75920@rohan.local> Message-ID: <52EFADB6.4000804@redhat.com> On Mon 03 Feb 2014 09:52:02 AM EST, Douglas Campos wrote: > Could we stop even mentioning "product"? :) > Great, now my mine car like mind is imaging a sync server with micro-transactions. For free we will sync 20 kib/s of your data. If you want to speed it up use 30 Gears. You get 600 when you install the app and can buy 20,000 more for only $100 ? From supittma at redhat.com Mon Feb 3 09:55:27 2014 From: supittma at redhat.com (Summers Pittman) Date: Mon, 03 Feb 2014 09:55:27 -0500 Subject: [aerogear-dev] Sync Day 4 Sync or Swim In-Reply-To: <0C68E922-30E5-4E68-A4F4-E20B1F2BA0A6@gmail.com> References: <52EFA76E.3000106@redhat.com> <91EE6BCE-B105-46D0-9D75-4B6E8D2ECBFC@redhat.com> <52EFAB66.4020707@redhat.com> <0C68E922-30E5-4E68-A4F4-E20B1F2BA0A6@gmail.com> Message-ID: <52EFADDF.6080306@redhat.com> On 02/03/2014 09:53 AM, Corinne Krych wrote: > On 03 Feb 2014, at 15:44, Summers Pittman wrote: > >> On Mon 03 Feb 2014 09:41:25 AM EST, Daniel Bevenius wrote: >>> Just catching up on all this, but I think this looks good. >> One quick note, I did not pay THAT much attention to what the server >> needs to have. >> >> I think it may be "good enough" for a 0.1.0 to have the protocol >> defined and the server be just an RI instead of a full product for a > > What do you mean by RI? Reference implementation. > >> bit. >> >>> >>> On 3 February 2014 15:33, Lucas Holmquist >> > wrote: >>> >>> >>> On Feb 3, 2014, at 9:27 AM, Summers Pittman >> > wrote: >>> >>>> So This should be all of the JIRAs (epics plus sub tasks) >>>> >>>> * >>>> >>> https://issues.jboss.org/browse/AEROGEAR-1428?jql=project%20%3D%20AEROGEAR%20AND%20component%20%3D%20data-sync%20AND%20created%20%3E%3D%20-1w%20ORDER%20BY%20created%20DESC >>>> Now we need to figure out things like versions, release dates, >>> project >>>> specific JIRAs, etc. >>>> >>>> Me PERSONALLY I think that >>>> * https://issues.jboss.org/browse/AEROGEAR-1405 and >>>> * https://issues.jboss.org/browse/AEROGEAR-1409 >>>> >>> those look pretty good and i think we have some of POC'd already >>> >>> >>> >>>> leave us in a great place for a 0.1.0 release. It will have enough >>>> stuff done that we can say "yes this a product" but isn't so feature >>>> rich that we get bogged down in minutia. >>>> >>>> WDYT? >>>> _______________________________________________ >>>> 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 >>> >>> >>> >>> >>> _______________________________________________ >>> 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 > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From qmx at qmx.me Mon Feb 3 09:58:30 2014 From: qmx at qmx.me (Douglas Campos) Date: Mon, 3 Feb 2014 12:58:30 -0200 Subject: [aerogear-dev] [aerogear-js] portable/fallback-able data migrations? In-Reply-To: References: <20140201210800.GM61817@rohan.local> Message-ID: <20140203145830.GF75920@rohan.local> On Mon, Feb 03, 2014 at 08:40:49AM -0500, Lucas Holmquist wrote: > > On Feb 1, 2014, at 4:08 PM, Douglas Campos wrote: > > > There's a nice feature on IndexedDB which is the version thing + > > 'upgrade needed' event[1], which we're using for creating the database > > automagically[2]. > > > > Any ideas on how could we provide an API for something like this, but > > which could potentially work with WebSQL too? > > > > var dm = AeroGear.DataManager(); > > dm.add({ > > name: "newStore", > > storageType: "IndexedDB", > > settings: { > > dbVersion: 3, > > upgradeHandler: function (evt) { > > // evt.oldVersion > > // evt.newVersion > > // evt.store > > // do data migration stuff, just caring about objects > > } > > } > > }); > > > > How does this sounds? Am I crazier than usual? :) > > not sure we really need this since the user doesn't actually created > and of the "fields". there is a field for an id and the other is the > json data, so the user never interacts with modifying the db Suppose we have an ACME inventory list app, which underwent structural changes during the upgrade from 0.0.2 to 0.0.3 and now uses kilograms to represent weight instead of pounds ;) I want to have this "data migration" thing so I can do the conversion the first time the database is open. Makes sense now? -- qmx From lholmqui at redhat.com Mon Feb 3 10:06:54 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Mon, 3 Feb 2014 10:06:54 -0500 Subject: [aerogear-dev] [aerogear-js] portable/fallback-able data migrations? In-Reply-To: <20140203145830.GF75920@rohan.local> References: <20140201210800.GM61817@rohan.local> <20140203145830.GF75920@rohan.local> Message-ID: On Feb 3, 2014, at 9:58 AM, Douglas Campos wrote: > On Mon, Feb 03, 2014 at 08:40:49AM -0500, Lucas Holmquist wrote: >> >> On Feb 1, 2014, at 4:08 PM, Douglas Campos wrote: >> >>> There's a nice feature on IndexedDB which is the version thing + >>> 'upgrade needed' event[1], which we're using for creating the database >>> automagically[2]. >>> >>> Any ideas on how could we provide an API for something like this, but >>> which could potentially work with WebSQL too? >>> >>> var dm = AeroGear.DataManager(); >>> dm.add({ >>> name: "newStore", >>> storageType: "IndexedDB", >>> settings: { >>> dbVersion: 3, >>> upgradeHandler: function (evt) { >>> // evt.oldVersion >>> // evt.newVersion >>> // evt.store >>> // do data migration stuff, just caring about objects >>> } >>> } >>> }); >>> >>> How does this sounds? Am I crazier than usual? :) >> >> not sure we really need this since the user doesn't actually created >> and of the "fields". there is a field for an id and the other is the >> json data, so the user never interacts with modifying the db > > Suppose we have an ACME inventory list app, which underwent structural > changes during the upgrade from 0.0.2 to 0.0.3 and now uses kilograms to > represent weight instead of pounds ;) > > I want to have this "data migration" thing so I can do the conversion > the first time the database is open. > > Makes sense now? yup, makes sense, then we would need to expose the "version" to the user, so they can increase the value or say to upgrade or something, also adding the event listener to upgrade it would also need to work with the sessionLocal adapter. On a related note, IndexedDB allows you to define keys for searching and other neat IndexedDBy things. it would be nice to be able to get some of these things in too, maybe > > -- > qmx > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From matzew at apache.org Mon Feb 3 10:28:33 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 3 Feb 2014 16:28:33 +0100 Subject: [aerogear-dev] Sync Day 4 Sync or Swim In-Reply-To: <52EFA76E.3000106@redhat.com> References: <52EFA76E.3000106@redhat.com> Message-ID: On Mon, Feb 3, 2014 at 3:27 PM, Summers Pittman wrote: > So This should be all of the JIRAs (epics plus sub tasks) > > * > > https://issues.jboss.org/browse/AEROGEAR-1428?jql=project%20%3D%20AEROGEAR%20AND%20component%20%3D%20data-sync%20AND%20created%20%3E%3D%20-1w%20ORDER%20BY%20created%20DESC > > If we figure out something else, or change our mind, we can always move/create some JIRAs. Overall these items you created here are looking good. However I think the server needs a bit more definition, e.g. what type of adapters (e.g. Couch-Adapter, Hibernate-Adapter), assuming we agreed on this architecture, instead of embedding w/in an application (e.g. on-top of JPA/Hibernate) > Now we need to figure out things like versions, release dates, project > specific JIRAs, etc. > > Me PERSONALLY I think that > * https://issues.jboss.org/browse/AEROGEAR-1405 and > * https://issues.jboss.org/browse/AEROGEAR-1409 sounds like a good starting point > > > leave us in a great place for a 0.1.0 release. It will have enough > stuff done that we can say "yes this a product" but isn't so feature > rich that we get bogged down in minutia. > > WDYT? > _______________________________________________ > 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/20140203/407fa142/attachment.html From matzew at apache.org Mon Feb 3 10:28:55 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 3 Feb 2014 16:28:55 +0100 Subject: [aerogear-dev] Sync Day 4 Sync or Swim In-Reply-To: <20140203145202.GE75920@rohan.local> References: <52EFA76E.3000106@redhat.com> <91EE6BCE-B105-46D0-9D75-4B6E8D2ECBFC@redhat.com> <52EFAB66.4020707@redhat.com> <20140203145202.GE75920@rohan.local> Message-ID: On Mon, Feb 3, 2014 at 3:52 PM, Douglas Campos wrote: > Could we stop even mentioning "product"? :) > yes !! :-) > > -- > qmx > _______________________________________________ > 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/20140203/dcf3032c/attachment.html From qmx at qmx.me Mon Feb 3 10:29:12 2014 From: qmx at qmx.me (Douglas Campos) Date: Mon, 3 Feb 2014 13:29:12 -0200 Subject: [aerogear-dev] Team meeting agenda In-Reply-To: References: Message-ID: <20140203152912.GG75920@rohan.local> [13:28:18] Meeting ended Mon Feb 3 15:17:58 2014 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) [13:28:18] Minutes: http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-02-03-15.05.html [13:28:18] Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-02-03-15.05.txt [13:28:18] Log: http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-02-03-15.05.log.html -- qmx From matzew at apache.org Mon Feb 3 10:33:50 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 3 Feb 2014 16:33:50 +0100 Subject: [aerogear-dev] Team meeting agenda In-Reply-To: <20140203152912.GG75920@rohan.local> References: <20140203152912.GG75920@rohan.local> Message-ID: yay - meeting logs :-) thanks for sharing On Mon, Feb 3, 2014 at 4:29 PM, Douglas Campos wrote: > [13:28:18] Meeting ended Mon Feb 3 15:17:58 2014 UTC. > Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) > [13:28:18] Minutes: > http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-02-03-15.05.html > [13:28:18] Minutes (text): > http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-02-03-15.05.txt > [13:28:18] Log: > http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-02-03-15.05.log.html > > > -- > qmx > _______________________________________________ > 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/20140203/3fdf7d90/attachment.html From supittma at redhat.com Mon Feb 3 10:34:04 2014 From: supittma at redhat.com (Summers Pittman) Date: Mon, 03 Feb 2014 10:34:04 -0500 Subject: [aerogear-dev] Sync Day 4 Sync or Swim In-Reply-To: References: <52EFA76E.3000106@redhat.com> Message-ID: <52EFB6EC.6080406@redhat.com> On 02/03/2014 10:28 AM, Matthias Wessendorf wrote: > > > > On Mon, Feb 3, 2014 at 3:27 PM, Summers Pittman > wrote: > > So This should be all of the JIRAs (epics plus sub tasks) > > * > https://issues.jboss.org/browse/AEROGEAR-1428?jql=project%20%3D%20AEROGEAR%20AND%20component%20%3D%20data-sync%20AND%20created%20%3E%3D%20-1w%20ORDER%20BY%20created%20DESC > > > If we figure out something else, or change our mind, we can always > move/create some JIRAs. > > Overall these items you created here are looking good. However I think > the server needs a bit more definition, e.g. what type of adapters > (e.g. Couch-Adapter, Hibernate-Adapter), assuming we agreed on this > architecture, instead of embedding w/in an application (e.g. on-top of > JPA/Hibernate) I mentioned that in response to DanBev TL;DR; I didn't think of the server beyond "the data has to come from somewhere". I heavily prefer having a protocol and a reference implementation that having a "you have to use this server to use this client" setup. But that is still up for discussion. I feel like push struck a good balance. We have Unified push as our default implementation, but it is easy to plug in your own. > > Now we need to figure out things like versions, release dates, project > specific JIRAs, etc. > > Me PERSONALLY I think that > * https://issues.jboss.org/browse/AEROGEAR-1405 and > * https://issues.jboss.org/browse/AEROGEAR-1409 > > > sounds like a good starting point > > > > leave us in a great place for a 0.1.0 release. It will have enough > stuff done that we can say "yes this a product" but isn't so feature > rich that we get bogged down in minutia. > > WDYT? > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140203/26ad10de/attachment-0001.html From corinnekrych at gmail.com Mon Feb 3 10:40:25 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Mon, 3 Feb 2014 16:40:25 +0100 Subject: [aerogear-dev] Sync Day 4 Sync or Swim In-Reply-To: <52EFB6EC.6080406@redhat.com> References: <52EFA76E.3000106@redhat.com> <52EFB6EC.6080406@redhat.com> Message-ID: <877E7FCB-88D2-46CA-BCCB-C6FB6F3E0CA9@gmail.com> It?ll help to move our client libs/ define protocol in the same direction sharing an common impl of ag-sync-server. imo, progress need to be done here too. ++ Corinne On 03 Feb 2014, at 16:34, Summers Pittman wrote: > On 02/03/2014 10:28 AM, Matthias Wessendorf wrote: >> >> >> >> On Mon, Feb 3, 2014 at 3:27 PM, Summers Pittman wrote: >> So This should be all of the JIRAs (epics plus sub tasks) >> >> * >> https://issues.jboss.org/browse/AEROGEAR-1428?jql=project%20%3D%20AEROGEAR%20AND%20component%20%3D%20data-sync%20AND%20created%20%3E%3D%20-1w%20ORDER%20BY%20created%20DESC >> >> >> If we figure out something else, or change our mind, we can always move/create some JIRAs. >> >> Overall these items you created here are looking good. However I think the server needs a bit more definition, e.g. what type of adapters (e.g. Couch-Adapter, Hibernate-Adapter), assuming we agreed on this architecture, instead of embedding w/in an application (e.g. on-top of JPA/Hibernate) > I mentioned that in response to DanBev > > TL;DR; I didn't think of the server beyond "the data has to come from somewhere". I heavily prefer having a protocol and a reference implementation that having a "you have to use this server to use this client" setup. But that is still up for discussion. > > I feel like push struck a good balance. We have Unified push as our default implementation, but it is easy to plug in your own. >> >> >> Now we need to figure out things like versions, release dates, project >> specific JIRAs, etc. >> >> Me PERSONALLY I think that >> * https://issues.jboss.org/browse/AEROGEAR-1405 and >> * https://issues.jboss.org/browse/AEROGEAR-1409 >> >> sounds like a good starting point >> >> >> >> leave us in a great place for a 0.1.0 release. It will have enough >> stuff done that we can say "yes this a product" but isn't so feature >> rich that we get bogged down in minutia. >> >> WDYT? >> _______________________________________________ >> 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 From matzew at apache.org Mon Feb 3 10:50:01 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 3 Feb 2014 16:50:01 +0100 Subject: [aerogear-dev] Sync Day 4 Sync or Swim In-Reply-To: <52EFB6EC.6080406@redhat.com> References: <52EFA76E.3000106@redhat.com> <52EFB6EC.6080406@redhat.com> Message-ID: On Mon, Feb 3, 2014 at 4:34 PM, Summers Pittman wrote: > On 02/03/2014 10:28 AM, Matthias Wessendorf wrote: > > > > > On Mon, Feb 3, 2014 at 3:27 PM, Summers Pittman wrote: > >> So This should be all of the JIRAs (epics plus sub tasks) >> >> * >> >> https://issues.jboss.org/browse/AEROGEAR-1428?jql=project%20%3D%20AEROGEAR%20AND%20component%20%3D%20data-sync%20AND%20created%20%3E%3D%20-1w%20ORDER%20BY%20created%20DESC >> >> > If we figure out something else, or change our mind, we can always > move/create some JIRAs. > > Overall these items you created here are looking good. However I think > the server needs a bit more definition, e.g. what type of adapters (e.g. > Couch-Adapter, Hibernate-Adapter), assuming we agreed on this architecture, > instead of embedding w/in an application (e.g. on-top of JPA/Hibernate) > > I mentioned that in response to DanBev > > TL;DR; I didn't think of the server beyond "the data has to come from > somewhere". I heavily prefer having a protocol and a reference > implementation that having a "you have to use this server to use this > client" setup. But that is still up for discussion. > yeah not sure on just providing an RI > > I feel like push struck a good balance. We have Unified push as our > default implementation, but it is easy to plug in your own. > hrm, sync based on UnifiedPush ? I was hope for this being a bit more flexible, or optional. hrm not sure > > > > >> Now we need to figure out things like versions, release dates, project >> specific JIRAs, etc. >> >> Me PERSONALLY I think that >> * https://issues.jboss.org/browse/AEROGEAR-1405 and >> * https://issues.jboss.org/browse/AEROGEAR-1409 > > > sounds like a good starting point > > >> >> >> leave us in a great place for a 0.1.0 release. It will have enough >> stuff done that we can say "yes this a product" but isn't so feature >> rich that we get bogged down in minutia. >> >> WDYT? >> _______________________________________________ >> 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 listaerogear-dev at lists.jboss.orghttps://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/20140203/06222322/attachment.html From lholmqui at redhat.com Mon Feb 3 10:52:10 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Mon, 3 Feb 2014 10:52:10 -0500 Subject: [aerogear-dev] Sync Day 4 Sync or Swim In-Reply-To: References: <52EFA76E.3000106@redhat.com> <52EFB6EC.6080406@redhat.com> Message-ID: On Feb 3, 2014, at 10:50 AM, Matthias Wessendorf wrote: > > > > On Mon, Feb 3, 2014 at 4:34 PM, Summers Pittman wrote: > On 02/03/2014 10:28 AM, Matthias Wessendorf wrote: >> >> >> >> On Mon, Feb 3, 2014 at 3:27 PM, Summers Pittman wrote: >> So This should be all of the JIRAs (epics plus sub tasks) >> >> * >> https://issues.jboss.org/browse/AEROGEAR-1428?jql=project%20%3D%20AEROGEAR%20AND%20component%20%3D%20data-sync%20AND%20created%20%3E%3D%20-1w%20ORDER%20BY%20created%20DESC >> >> >> If we figure out something else, or change our mind, we can always move/create some JIRAs. >> >> Overall these items you created here are looking good. However I think the server needs a bit more definition, e.g. what type of adapters (e.g. Couch-Adapter, Hibernate-Adapter), assuming we agreed on this architecture, instead of embedding w/in an application (e.g. on-top of JPA/Hibernate) > I mentioned that in response to DanBev > > TL;DR; I didn't think of the server beyond "the data has to come from somewhere". I heavily prefer having a protocol and a reference implementation that having a "you have to use this server to use this client" setup. But that is still up for discussion. > > yeah not sure on just providing an RI > > > I feel like push struck a good balance. We have Unified push as our default implementation, but it is easy to plug in your own. > > hrm, sync based on UnifiedPush ? I was hope for this being a bit more flexible, or optional. hrm not sure i read that as the UPS being a good RI for our push server protocol, not a sync thing > > > >> >> >> Now we need to figure out things like versions, release dates, project >> specific JIRAs, etc. >> >> Me PERSONALLY I think that >> * https://issues.jboss.org/browse/AEROGEAR-1405 and >> * https://issues.jboss.org/browse/AEROGEAR-1409 >> >> sounds like a good starting point >> >> >> >> leave us in a great place for a 0.1.0 release. It will have enough >> stuff done that we can say "yes this a product" but isn't so feature >> rich that we get bogged down in minutia. >> >> WDYT? >> _______________________________________________ >> 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 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140203/5a446345/attachment-0001.html From corinnekrych at gmail.com Mon Feb 3 10:54:09 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Mon, 3 Feb 2014 16:54:09 +0100 Subject: [aerogear-dev] Sync Day 4 Sync or Swim In-Reply-To: References: <52EFA76E.3000106@redhat.com> <52EFB6EC.6080406@redhat.com> Message-ID: <6267A8E7-AE48-4A2E-9156-8D246FE3806F@gmail.com> On 03 Feb 2014, at 16:52, Lucas Holmquist wrote: > > On Feb 3, 2014, at 10:50 AM, Matthias Wessendorf wrote: > >> >> >> >> On Mon, Feb 3, 2014 at 4:34 PM, Summers Pittman wrote: >> On 02/03/2014 10:28 AM, Matthias Wessendorf wrote: >>> >>> >>> >>> On Mon, Feb 3, 2014 at 3:27 PM, Summers Pittman wrote: >>> So This should be all of the JIRAs (epics plus sub tasks) >>> >>> * >>> https://issues.jboss.org/browse/AEROGEAR-1428?jql=project%20%3D%20AEROGEAR%20AND%20component%20%3D%20data-sync%20AND%20created%20%3E%3D%20-1w%20ORDER%20BY%20created%20DESC >>> >>> >>> If we figure out something else, or change our mind, we can always move/create some JIRAs. >>> >>> Overall these items you created here are looking good. However I think the server needs a bit more definition, e.g. what type of adapters (e.g. Couch-Adapter, Hibernate-Adapter), assuming we agreed on this architecture, instead of embedding w/in an application (e.g. on-top of JPA/Hibernate) >> I mentioned that in response to DanBev >> >> TL;DR; I didn't think of the server beyond "the data has to come from somewhere". I heavily prefer having a protocol and a reference implementation that having a "you have to use this server to use this client" setup. But that is still up for discussion. >> >> yeah not sure on just providing an RI >> >> >> I feel like push struck a good balance. We have Unified push as our default implementation, but it is easy to plug in your own. >> >> hrm, sync based on UnifiedPush ? I was hope for this being a bit more flexible, or optional. hrm not sure > > i read that as the UPS being a good RI for our push server protocol, not a sync thing Same here, but moving forward server part will help define Ri imo > > >> >> >> >>> >>> >>> Now we need to figure out things like versions, release dates, project >>> specific JIRAs, etc. >>> >>> Me PERSONALLY I think that >>> * https://issues.jboss.org/browse/AEROGEAR-1405 and >>> * https://issues.jboss.org/browse/AEROGEAR-1409 >>> >>> sounds like a good starting point >>> >>> >>> >>> leave us in a great place for a 0.1.0 release. It will have enough >>> stuff done that we can say "yes this a product" but isn't so feature >>> rich that we get bogged down in minutia. >>> >>> WDYT? >>> _______________________________________________ >>> 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 >> _______________________________________________ >> 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 From supittma at redhat.com Mon Feb 3 10:55:39 2014 From: supittma at redhat.com (Summers Pittman) Date: Mon, 03 Feb 2014 10:55:39 -0500 Subject: [aerogear-dev] Sync Day 4 Sync or Swim In-Reply-To: References: <52EFA76E.3000106@redhat.com> <52EFB6EC.6080406@redhat.com> Message-ID: <52EFBBFB.5060406@redhat.com> On 02/03/2014 10:52 AM, Lucas Holmquist wrote: > > On Feb 3, 2014, at 10:50 AM, Matthias Wessendorf > wrote: > >> >> >> >> On Mon, Feb 3, 2014 at 4:34 PM, Summers Pittman > > wrote: >> >> On 02/03/2014 10:28 AM, Matthias Wessendorf wrote: >>> >>> >>> >>> On Mon, Feb 3, 2014 at 3:27 PM, Summers Pittman >>> > wrote: >>> >>> So This should be all of the JIRAs (epics plus sub tasks) >>> >>> * >>> https://issues.jboss.org/browse/AEROGEAR-1428?jql=project%20%3D%20AEROGEAR%20AND%20component%20%3D%20data-sync%20AND%20created%20%3E%3D%20-1w%20ORDER%20BY%20created%20DESC >>> >>> >>> If we figure out something else, or change our mind, we can >>> always move/create some JIRAs. >>> >>> Overall these items you created here are looking good. However I >>> think the server needs a bit more definition, e.g. what type of >>> adapters (e.g. Couch-Adapter, Hibernate-Adapter), assuming we >>> agreed on this architecture, instead of embedding w/in an >>> application (e.g. on-top of JPA/Hibernate) >> I mentioned that in response to DanBev >> >> TL;DR; I didn't think of the server beyond "the data has to come >> from somewhere". I heavily prefer having a protocol and a >> reference implementation that having a "you have to use this >> server to use this client" setup. But that is still up for >> discussion. >> >> >> yeah not sure on just providing an RI >> >> >> I feel like push struck a good balance. We have Unified push as >> our default implementation, but it is easy to plug in your own. >> >> >> hrm, sync based on UnifiedPush ? I was hope for this being a bit more >> flexible, or optional. hrm not sure > > i read that as the UPS being a good RI for our push server protocol, > not a sync thing I was more talking about the interaction among APIs, implementations, protocols and servers. It is easy to add your own messaging system into the Push APIs (on Android anyway). We provide an implementation for connecting to the Unified push server however. > > >> >> >>> >>> Now we need to figure out things like versions, release >>> dates, project >>> specific JIRAs, etc. >>> >>> Me PERSONALLY I think that >>> * https://issues.jboss.org/browse/AEROGEAR-1405 and >>> * https://issues.jboss.org/browse/AEROGEAR-1409 >>> >>> >>> sounds like a good starting point >>> >>> >>> >>> leave us in a great place for a 0.1.0 release. It will have >>> enough >>> stuff done that we can say "yes this a product" but isn't so >>> feature >>> rich that we get bogged down in minutia. >>> >>> WDYT? >>> _______________________________________________ >>> 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 >> _______________________________________________ >> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140203/fed71d9c/attachment.html From lholmqui at redhat.com Mon Feb 3 11:24:07 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Mon, 3 Feb 2014 11:24:07 -0500 Subject: [aerogear-dev] [aerogear-js] portable/fallback-able data migrations? In-Reply-To: References: <20140201210800.GM61817@rohan.local> <20140203145830.GF75920@rohan.local> Message-ID: <3F959B90-1EAD-4455-BCD5-663801284DA2@redhat.com> On Feb 3, 2014, at 10:06 AM, Lucas Holmquist wrote: > > On Feb 3, 2014, at 9:58 AM, Douglas Campos wrote: > >> On Mon, Feb 03, 2014 at 08:40:49AM -0500, Lucas Holmquist wrote: >>> >>> On Feb 1, 2014, at 4:08 PM, Douglas Campos wrote: >>> >>>> There's a nice feature on IndexedDB which is the version thing + >>>> 'upgrade needed' event[1], which we're using for creating the database >>>> automagically[2]. >>>> >>>> Any ideas on how could we provide an API for something like this, but >>>> which could potentially work with WebSQL too? >>>> >>>> var dm = AeroGear.DataManager(); >>>> dm.add({ >>>> name: "newStore", >>>> storageType: "IndexedDB", >>>> settings: { >>>> dbVersion: 3, >>>> upgradeHandler: function (evt) { >>>> // evt.oldVersion >>>> // evt.newVersion >>>> // evt.store >>>> // do data migration stuff, just caring about objects >>>> } >>>> } >>>> }); >>>> >>>> How does this sounds? Am I crazier than usual? :) >>> >>> not sure we really need this since the user doesn't actually created >>> and of the "fields". there is a field for an id and the other is the >>> json data, so the user never interacts with modifying the db >> >> Suppose we have an ACME inventory list app, which underwent structural >> changes during the upgrade from 0.0.2 to 0.0.3 and now uses kilograms to >> represent weight instead of pounds ;) >> >> I want to have this "data migration" thing so I can do the conversion >> the first time the database is open. >> >> Makes sense now? > > yup, makes sense, then we would need to expose the "version" to the user, so they can increase the value or say to upgrade or something, also adding the event listener to upgrade > > it would also need to work with the sessionLocal adapter. qmx, maybe want to JIRA that shizznit > > > On a related note, IndexedDB allows you to define keys for searching and other neat IndexedDBy things. it would be nice to be able to get some of these things in too, maybe > >> >> -- >> qmx >> _______________________________________________ >> 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 From matzew at apache.org Mon Feb 3 11:49:53 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 3 Feb 2014 17:49:53 +0100 Subject: [aerogear-dev] Sync Day 4 Sync or Swim In-Reply-To: <52EFBBFB.5060406@redhat.com> References: <52EFA76E.3000106@redhat.com> <52EFB6EC.6080406@redhat.com> <52EFBBFB.5060406@redhat.com> Message-ID: On Mon, Feb 3, 2014 at 4:55 PM, Summers Pittman wrote: > On 02/03/2014 10:52 AM, Lucas Holmquist wrote: > > > On Feb 3, 2014, at 10:50 AM, Matthias Wessendorf > wrote: > > > > > On Mon, Feb 3, 2014 at 4:34 PM, Summers Pittman wrote: > >> On 02/03/2014 10:28 AM, Matthias Wessendorf wrote: >> >> >> >> >> On Mon, Feb 3, 2014 at 3:27 PM, Summers Pittman wrote: >> >>> So This should be all of the JIRAs (epics plus sub tasks) >>> >>> * >>> >>> https://issues.jboss.org/browse/AEROGEAR-1428?jql=project%20%3D%20AEROGEAR%20AND%20component%20%3D%20data-sync%20AND%20created%20%3E%3D%20-1w%20ORDER%20BY%20created%20DESC >>> >>> >> If we figure out something else, or change our mind, we can always >> move/create some JIRAs. >> >> Overall these items you created here are looking good. However I think >> the server needs a bit more definition, e.g. what type of adapters (e.g. >> Couch-Adapter, Hibernate-Adapter), assuming we agreed on this architecture, >> instead of embedding w/in an application (e.g. on-top of JPA/Hibernate) >> >> I mentioned that in response to DanBev >> >> TL;DR; I didn't think of the server beyond "the data has to come from >> somewhere". I heavily prefer having a protocol and a reference >> implementation that having a "you have to use this server to use this >> client" setup. But that is still up for discussion. >> > > yeah not sure on just providing an RI > > >> >> I feel like push struck a good balance. We have Unified push as our >> default implementation, but it is easy to plug in your own. >> > > hrm, sync based on UnifiedPush ? I was hope for this being a bit more > flexible, or optional. hrm not sure > > > i read that as the UPS being a good RI for our push server protocol, not > a sync thing > > I was more talking about the interaction among APIs, implementations, > protocols and servers. > > It is easy to add your own messaging system into the Push APIs (on Android > anyway). > yep - but not on iOS/SimplePush clients And than I really 'fear' that our different client API might really be Android versus iOS/SimplePush at the end of the day; Not sure, but I feel at the end they are all really different. > We provide an implementation for connecting to the Unified push server > however. > > > > > > >> >> >> >> >>> Now we need to figure out things like versions, release dates, project >>> specific JIRAs, etc. >>> >>> Me PERSONALLY I think that >>> * https://issues.jboss.org/browse/AEROGEAR-1405 and >>> * https://issues.jboss.org/browse/AEROGEAR-1409 >> >> >> sounds like a good starting point >> >> >>> >>> >>> leave us in a great place for a 0.1.0 release. It will have enough >>> stuff done that we can say "yes this a product" but isn't so feature >>> rich that we get bogged down in minutia. >>> >>> WDYT? >>> _______________________________________________ >>> 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 listaerogear-dev at lists.jboss.orghttps://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 listaerogear-dev at lists.jboss.orghttps://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/20140203/59131d15/attachment.html From matzew at apache.org Mon Feb 3 13:18:09 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 3 Feb 2014 19:18:09 +0100 Subject: [aerogear-dev] SimplePush CLI Message-ID: Hi, while thinking about potential refactorings, and moving some of the java 'sender' code into subprojects I played w/ the ideas of also offering CLI for: * SimplePush * UnifiedPush An early (hacky) version of a SimplePush CLI is located here: https://github.com/matzew/simplepush-cli The neat thing - I think - you can ignore the nasty version string, in that case the current timestamp is used. The CLI has been tested w/ our Quickstart on SimplePush ([1]) The actual code for the "SimplePushClient.java" file could be than also be reused inside of the UnifiedPush Server - my current code here is very much the code from the UnifiedPush Server (except here I am using OKHttp) thoughts? -Matthias [1] https://github.com/aerogear/aerogear-simplepush-quickstart -- 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/20140203/29135b7d/attachment.html From qmx at qmx.me Mon Feb 3 13:19:55 2014 From: qmx at qmx.me (Douglas Campos) Date: Mon, 3 Feb 2014 16:19:55 -0200 Subject: [aerogear-dev] [aerogear-js] portable/fallback-able data migrations? In-Reply-To: <3F959B90-1EAD-4455-BCD5-663801284DA2@redhat.com> References: <20140201210800.GM61817@rohan.local> <20140203145830.GF75920@rohan.local> <3F959B90-1EAD-4455-BCD5-663801284DA2@redhat.com> Message-ID: <20140203181955.GH75920@rohan.local> On Mon, Feb 03, 2014 at 11:24:07AM -0500, Lucas Holmquist wrote: > qmx, maybe want to JIRA that shizznit Will do, mildew -- qmx -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 527 bytes Desc: not available Url : http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140203/1c201858/attachment.bin From lholmqui at redhat.com Mon Feb 3 13:23:47 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Mon, 3 Feb 2014 13:23:47 -0500 Subject: [aerogear-dev] SimplePush CLI In-Reply-To: References: Message-ID: <099DA0A2-DD97-4C8F-90B8-665F20F98B19@redhat.com> looks pretty neat, i think we can also adapt the node.js versions to also be "installable" for CLI use, similar to how you can also use plugman/cordova cli's api and not just on the command line On Feb 3, 2014, at 1:18 PM, Matthias Wessendorf wrote: > Hi, > > while thinking about potential refactorings, and moving some of the java 'sender' code into subprojects I played w/ the ideas of also offering CLI for: > > * SimplePush > * UnifiedPush > > An early (hacky) version of a SimplePush CLI is located here: > > https://github.com/matzew/simplepush-cli > > The neat thing - I think - you can ignore the nasty version string, in that case the current timestamp is used. The CLI has been tested w/ our Quickstart on SimplePush ([1]) > > The actual code for the "SimplePushClient.java" file could be than also be reused inside of the UnifiedPush Server - my current code here is very much the code from the UnifiedPush Server (except here I am using OKHttp) > > thoughts? > > -Matthias > > [1] https://github.com/aerogear/aerogear-simplepush-quickstart > > > -- > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140203/509ffda1/attachment-0001.html From jrconlin at gmail.com Mon Feb 3 13:26:57 2014 From: jrconlin at gmail.com (JR Conlin) Date: Mon, 03 Feb 2014 10:26:57 -0800 Subject: [aerogear-dev] SimplePush CLI In-Reply-To: References: Message-ID: <52EFDF71.5080404@gmail.com> Neat! That's send only, right? (Pretty sure, but my head is wonky today. Sadly it has nothing to do with yesterday, either.) On 2014/2/3 10:18 AM, Matthias Wessendorf wrote: > Hi, > > while thinking about potential refactorings, and moving some of the > java 'sender' code into subprojects I played w/ the ideas of also > offering CLI for: > > * SimplePush > * UnifiedPush > > An early (hacky) version of a SimplePush CLI is located here: > > https://github.com/matzew/simplepush-cli > > The neat thing - I think - you can ignore the nasty version string, in > that case the current timestamp is used. The CLI has been tested w/ > our Quickstart on SimplePush ([1]) > > The actual code for the "SimplePushClient.java" file could be than > also be reused inside of the UnifiedPush Server - my current code here > is very much the code from the UnifiedPush Server (except here I am > using OKHttp) > > thoughts? > > -Matthias > > [1] https://github.com/aerogear/aerogear-simplepush-quickstart > > > -- > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140203/37317bb9/attachment.html From matzew at apache.org Mon Feb 3 13:36:51 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 3 Feb 2014 19:36:51 +0100 Subject: [aerogear-dev] SimplePush CLI In-Reply-To: <099DA0A2-DD97-4C8F-90B8-665F20F98B19@redhat.com> References: <099DA0A2-DD97-4C8F-90B8-665F20F98B19@redhat.com> Message-ID: On Monday, February 3, 2014, Lucas Holmquist wrote: > looks pretty neat, > > i think we can also adapt the node.js versions to also be "installable" > for CLI use, similar to how you can also use plugman/cordova cli's api and > not just on the command line > I had brew in mind for this; will look into this later this week > > On Feb 3, 2014, at 1:18 PM, Matthias Wessendorf > > wrote: > > Hi, > > while thinking about potential refactorings, and moving some of the java > 'sender' code into subprojects I played w/ the ideas of also offering CLI > for: > > * SimplePush > * UnifiedPush > > An early (hacky) version of a SimplePush CLI is located here: > > https://github.com/matzew/simplepush-cli > > The neat thing - I think - you can ignore the nasty version string, in > that case the current timestamp is used. The CLI has been tested w/ our > Quickstart on SimplePush ([1]) > > The actual code for the "SimplePushClient.java" file could be than also be > reused inside of the UnifiedPush Server - my current code here is very much > the code from the UnifiedPush Server (except here I am using OKHttp) > > thoughts? > > -Matthias > > [1] https://github.com/aerogear/aerogear-simplepush-quickstart > > > -- > 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 > > > -- Sent from Gmail Mobile -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140203/31c86964/attachment.html From matzew at apache.org Mon Feb 3 13:38:37 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 3 Feb 2014 19:38:37 +0100 Subject: [aerogear-dev] SimplePush CLI In-Reply-To: <52EFDF71.5080404@gmail.com> References: <52EFDF71.5080404@gmail.com> Message-ID: On Monday, February 3, 2014, JR Conlin wrote: > Neat! That's send only, right? > > > (Pretty sure, but my head is wonky today. Sadly it has nothing to do with > yesterday, either.) > > On 2014/2/3 10:18 AM, Matthias Wessendorf wrote: > Yep, this is just sending However we also have a java lib (no cli) for receiving; at JavaOne we got asked for a JsvaSE client lib of SimplePush, for low-level notifications > Hi, > > while thinking about potential refactorings, and moving some of the java > 'sender' code into subprojects I played w/ the ideas of also offering CLI > for: > > * SimplePush > * UnifiedPush > > An early (hacky) version of a SimplePush CLI is located here: > > https://github.com/matzew/simplepush-cli > > The neat thing - I think - you can ignore the nasty version string, in > that case the current timestamp is used. The CLI has been tested w/ our > Quickstart on SimplePush ([1]) > > The actual code for the "SimplePushClient.java" file could be than also > be reused inside of the UnifiedPush Server - my current code here is very > much the code from the UnifiedPush Server (except here I am using OKHttp) > > thoughts? > > -Matthias > > [1] https://github.com/aerogear/aerogear-simplepush-quickstart > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > > _______________________________________________ > aerogear-dev mailing listaerogear-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > -- Sent from Gmail Mobile -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140203/5ef850d5/attachment.html From scm.blanc at gmail.com Mon Feb 3 13:40:56 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Mon, 3 Feb 2014 19:40:56 +0100 Subject: [aerogear-dev] SimplePush CLI In-Reply-To: References: Message-ID: Really cool ! I think I could easily use the SimplePushClient .java to be able to create a Forge 2.0 Addon, it will integrate with Forge's CLI and having cool stuff like code completion. On Mon, Feb 3, 2014 at 7:18 PM, Matthias Wessendorf wrote: > Hi, > > while thinking about potential refactorings, and moving some of the java > 'sender' code into subprojects I played w/ the ideas of also offering CLI > for: > > * SimplePush > * UnifiedPush > > An early (hacky) version of a SimplePush CLI is located here: > > https://github.com/matzew/simplepush-cli > > The neat thing - I think - you can ignore the nasty version string, in > that case the current timestamp is used. The CLI has been tested w/ our > Quickstart on SimplePush ([1]) > > The actual code for the "SimplePushClient.java" file could be than also be > reused inside of the UnifiedPush Server - my current code here is very much > the code from the UnifiedPush Server (except here I am using OKHttp) > > thoughts? > > -Matthias > > [1] https://github.com/aerogear/aerogear-simplepush-quickstart > > > -- > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140203/f98854a5/attachment.html From jrconlin at gmail.com Mon Feb 3 13:54:06 2014 From: jrconlin at gmail.com (JR Conlin) Date: Mon, 03 Feb 2014 10:54:06 -0800 Subject: [aerogear-dev] SimplePush CLI In-Reply-To: References: <099DA0A2-DD97-4C8F-90B8-665F20F98B19@redhat.com> Message-ID: <52EFE5CE.40209@gmail.com> One other note: I don't know if this would work for UnifiedPush, but for testing remote REST calls, I tend to use curl http://curl.haxx.se/ It's available for nearly every platform known. It's pretty easy to use on the command line, so sending a PUT would be: curl -X PUT -d "version=123" http://push.services.mozilla.org/longStringOfCrap where -X specifies the method to use -d specifies the "data" to send in the request Curl is amazingly powerful once you dig into it and can save a lot of time. Just figured I should share the knowledge. On 2014/2/3 10:36 AM, Matthias Wessendorf wrote: > > > On Monday, February 3, 2014, Lucas Holmquist > wrote: > > looks pretty neat, > > i think we can also adapt the node.js versions to also be > "installable" for CLI use, similar to how you can also use > plugman/cordova cli's api and not just on the command line > > > > I had brew in mind for this; will look into this later thisweek > > > > On Feb 3, 2014, at 1:18 PM, Matthias Wessendorf > wrote: > >> Hi, >> >> while thinking about potential refactorings, and moving some of >> the java 'sender' code into subprojects I played w/ the ideas of >> also offering CLI for: >> >> * SimplePush >> * UnifiedPush >> >> An early (hacky) version of a SimplePush CLI is located here: >> >> https://github.com/matzew/simplepush-cli >> >> The neat thing - I think - you can ignore the nasty version >> string, in that case the current timestamp is used. The CLI has >> been tested w/ our Quickstart on SimplePush ([1]) >> >> The actual code for the "SimplePushClient.java" file could be >> than also be reused inside of the UnifiedPush Server - my current >> code here is very much the code from the UnifiedPush Server >> (except here I am using OKHttp) >> >> thoughts? >> >> -Matthias >> >> [1] https://github.com/aerogear/aerogear-simplepush-quickstart >> >> >> -- >> 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 > > > > -- > Sent from Gmail Mobile > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140203/4a8ebbd4/attachment-0001.html From matzew at apache.org Mon Feb 3 14:03:05 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 3 Feb 2014 20:03:05 +0100 Subject: [aerogear-dev] SimplePush CLI In-Reply-To: <52EFE5CE.40209@gmail.com> References: <099DA0A2-DD97-4C8F-90B8-665F20F98B19@redhat.com> <52EFE5CE.40209@gmail.com> Message-ID: Yep, works w/ UnifiedPush, and we use thst for testing as well However we need/have java libs fir sending, hence turning that into less verbose CLIs is just a few lines of code :-) On Monday, February 3, 2014, JR Conlin wrote: > One other note: > > I don't know if this would work for UnifiedPush, but for testing remote > REST calls, I tend to use curl > > http://curl.haxx.se/ > > It's available for nearly every platform known. > > It's pretty easy to use on the command line, so sending a PUT would be: > > curl -X PUT -d "version=123" > http://push.services.mozilla.org/longStringOfCrap > > where -X specifies the method to use > -d specifies the "data" to send in the request > > Curl is amazingly powerful once you dig into it and can save a lot of > time. Just figured I should share the knowledge. > > On 2014/2/3 10:36 AM, Matthias Wessendorf wrote: > > > > On Monday, February 3, 2014, Lucas Holmquist > > wrote: > >> looks pretty neat, >> >> i think we can also adapt the node.js versions to also be "installable" >> for CLI use, similar to how you can also use plugman/cordova cli's api and >> not just on the command line >> > > > I had brew in mind for this; will look into this later this week > > >> >> On Feb 3, 2014, at 1:18 PM, Matthias Wessendorf >> wrote: >> >> Hi, >> >> while thinking about potential refactorings, and moving some of the >> java 'sender' code into subprojects I played w/ the ideas of also offering >> CLI for: >> >> * SimplePush >> * UnifiedPush >> >> An early (hacky) version of a SimplePush CLI is located here: >> >> https://github.com/matzew/simplepush-cli >> >> The neat thing - I think - you can ignore the nasty version string, in >> that case the current timestamp is used. The CLI has been tested w/ our >> Quickstart on SimplePush ([1]) >> >> The actual code for the "SimplePushClient.java" file could be than also >> be reused inside of the UnifiedPush Server - my current code here is very >> much the code from the UnifiedPush Server (except here I am using OKHttp) >> >> thoughts? >> >> -Matthias >> >> [1] https://github.com/aerogear/aerogear-simplepush-quickstart >> >> >> -- >> 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 >> >> >> > > -- > Sent from Gmail Mobile > > > _______________________________________________ > aerogear-dev mailing listaerogear-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > -- Sent from Gmail Mobile -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140203/bd2c774a/attachment.html From jrconlin at gmail.com Mon Feb 3 14:18:00 2014 From: jrconlin at gmail.com (JR Conlin) Date: Mon, 03 Feb 2014 11:18:00 -0800 Subject: [aerogear-dev] SimplePush CLI In-Reply-To: References: <099DA0A2-DD97-4C8F-90B8-665F20F98B19@redhat.com> <52EFE5CE.40209@gmail.com> Message-ID: <52EFEB68.5010203@gmail.com> Ah, makes perfect sense. I'll go back to lurking. On 2014/2/3 11:03 AM, Matthias Wessendorf wrote: > Yep, works w/ UnifiedPush, and we use thst for testing as well > > > However we need/have java libs fir sending, hence turning that into > less verbose CLIs is just a few lines of code :-) > > On Monday, February 3, 2014, JR Conlin > wrote: > > One other note: > > I don't know if this would work for UnifiedPush, but for testing > remote REST calls, I tend to use curl > > http://curl.haxx.se/ > > It's available for nearly every platform known. > > It's pretty easy to use on the command line, so sending a PUT > would be: > > curl -X PUT -d "version=123" > http://push.services.mozilla.org/longStringOfCrap > > where -X specifies the method to use > -d specifies the "data" to send in the request > > Curl is amazingly powerful once you dig into it and can save a lot > of time. Just figured I should share the knowledge. > > On 2014/2/3 10:36 AM, Matthias Wessendorf wrote: >> >> >> On Monday, February 3, 2014, Lucas Holmquist > > wrote: >> >> looks pretty neat, >> >> i think we can also adapt the node.js versions to also be >> "installable" for CLI use, similar to how you can also use >> plugman/cordova cli's api and not just on the command line >> >> >> >> I had brew in mind for this; will look into this later thisweek >> >> >> >> On Feb 3, 2014, at 1:18 PM, Matthias Wessendorf >> wrote: >> >>> Hi, >>> >>> while thinking about potential refactorings, and moving some >>> of the java 'sender' code into subprojects I played w/ the >>> ideas of also offering CLI for: >>> >>> * SimplePush >>> * UnifiedPush >>> >>> An early (hacky) version of a SimplePush CLI is located here: >>> >>> https://github.com/matzew/simplepush-cli >>> >>> The neat thing - I think - you can ignore the nasty version >>> string, in that case the current timestamp is used. The CLI >>> has been tested w/ our Quickstart on SimplePush ([1]) >>> >>> The actual code for the "SimplePushClient.java" file could >>> be than also be reused inside of the UnifiedPush Server - my >>> current code here is very much the code from the UnifiedPush >>> Server (except here I am using OKHttp) >>> >>> thoughts? >>> >>> -Matthias >>> >>> [1] https://github.com/aerogear/aerogear-simplepush-quickstart >>> >>> >>> -- >>> 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 >> >> >> >> -- >> Sent from Gmail Mobile >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > -- > Sent from Gmail Mobile > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140203/b7a4de72/attachment.html From matzew at apache.org Mon Feb 3 16:50:23 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 3 Feb 2014 22:50:23 +0100 Subject: [aerogear-dev] SimplePush CLI In-Reply-To: <52EFEB68.5010203@gmail.com> References: <099DA0A2-DD97-4C8F-90B8-665F20F98B19@redhat.com> <52EFE5CE.40209@gmail.com> <52EFEB68.5010203@gmail.com> Message-ID: Did a (temporary?) upload of the binary: https://github.com/matzew/simplepush-cli/raw/dist/bin/simple-push -M On Mon, Feb 3, 2014 at 8:18 PM, JR Conlin wrote: > Ah, makes perfect sense. I'll go back to lurking. > > > On 2014/2/3 11:03 AM, Matthias Wessendorf wrote: > > Yep, works w/ UnifiedPush, and we use thst for testing as well > > > However we need/have java libs fir sending, hence turning that into less > verbose CLIs is just a few lines of code :-) > > On Monday, February 3, 2014, JR Conlin wrote: > >> One other note: >> >> I don't know if this would work for UnifiedPush, but for testing remote >> REST calls, I tend to use curl >> >> http://curl.haxx.se/ >> >> It's available for nearly every platform known. >> >> It's pretty easy to use on the command line, so sending a PUT would be: >> >> curl -X PUT -d "version=123" >> http://push.services.mozilla.org/longStringOfCrap >> >> where -X specifies the method to use >> -d specifies the "data" to send in the request >> >> Curl is amazingly powerful once you dig into it and can save a lot of >> time. Just figured I should share the knowledge. >> >> On 2014/2/3 10:36 AM, Matthias Wessendorf wrote: >> >> >> >> On Monday, February 3, 2014, Lucas Holmquist wrote: >> >>> looks pretty neat, >>> >>> i think we can also adapt the node.js versions to also be >>> "installable" for CLI use, similar to how you can also use plugman/cordova >>> cli's api and not just on the command line >>> >> >> >> I had brew in mind for this; will look into this later this week >> >> >>> >>> On Feb 3, 2014, at 1:18 PM, Matthias Wessendorf >>> wrote: >>> >>> Hi, >>> >>> while thinking about potential refactorings, and moving some of the >>> java 'sender' code into subprojects I played w/ the ideas of also offering >>> CLI for: >>> >>> * SimplePush >>> * UnifiedPush >>> >>> An early (hacky) version of a SimplePush CLI is located here: >>> >>> https://github.com/matzew/simplepush-cli >>> >>> The neat thing - I think - you can ignore the nasty version string, in >>> that case the current timestamp is used. The CLI has been tested w/ our >>> Quickstart on SimplePush ([1]) >>> >>> The actual code for the "SimplePushClient.java" file could be than >>> also be reused inside of the UnifiedPush Server - my current code here is >>> very much the code from the UnifiedPush Server (except here I am using >>> OKHttp) >>> >>> thoughts? >>> >>> -Matthias >>> >>> [1] https://github.com/aerogear/aerogear-simplepush-quickstart >>> >>> >>> -- >>> 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 >>> >>> >>> >> >> -- >> Sent from Gmail Mobile >> >> >> _______________________________________________ >> aerogear-dev mailing listaerogear-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> > > -- > Sent from Gmail Mobile > > > _______________________________________________ > aerogear-dev mailing listaerogear-dev at lists.jboss.orghttps://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/20140203/8f39b6d6/attachment-0001.html From daniel.bevenius at gmail.com Tue Feb 4 02:44:48 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Tue, 4 Feb 2014 08:44:48 +0100 Subject: [aerogear-dev] SimplePush CLI In-Reply-To: References: <099DA0A2-DD97-4C8F-90B8-665F20F98B19@redhat.com> <52EFE5CE.40209@gmail.com> <52EFEB68.5010203@gmail.com> Message-ID: Cool, will try it out later today! On 3 February 2014 22:50, Matthias Wessendorf wrote: > Did a (temporary?) upload of the binary: > > https://github.com/matzew/simplepush-cli/raw/dist/bin/simple-push > > -M > > > On Mon, Feb 3, 2014 at 8:18 PM, JR Conlin wrote: > >> Ah, makes perfect sense. I'll go back to lurking. >> >> >> On 2014/2/3 11:03 AM, Matthias Wessendorf wrote: >> >> Yep, works w/ UnifiedPush, and we use thst for testing as well >> >> >> However we need/have java libs fir sending, hence turning that into >> less verbose CLIs is just a few lines of code :-) >> >> On Monday, February 3, 2014, JR Conlin wrote: >> >>> One other note: >>> >>> I don't know if this would work for UnifiedPush, but for testing remote >>> REST calls, I tend to use curl >>> >>> http://curl.haxx.se/ >>> >>> It's available for nearly every platform known. >>> >>> It's pretty easy to use on the command line, so sending a PUT would be: >>> >>> curl -X PUT -d "version=123" >>> http://push.services.mozilla.org/longStringOfCrap >>> >>> where -X specifies the method to use >>> -d specifies the "data" to send in the request >>> >>> Curl is amazingly powerful once you dig into it and can save a lot of >>> time. Just figured I should share the knowledge. >>> >>> On 2014/2/3 10:36 AM, Matthias Wessendorf wrote: >>> >>> >>> >>> On Monday, February 3, 2014, Lucas Holmquist >>> wrote: >>> >>>> looks pretty neat, >>>> >>>> i think we can also adapt the node.js versions to also be >>>> "installable" for CLI use, similar to how you can also use plugman/cordova >>>> cli's api and not just on the command line >>>> >>> >>> >>> I had brew in mind for this; will look into this later this week >>> >>> >>>> >>>> On Feb 3, 2014, at 1:18 PM, Matthias Wessendorf >>>> wrote: >>>> >>>> Hi, >>>> >>>> while thinking about potential refactorings, and moving some of the >>>> java 'sender' code into subprojects I played w/ the ideas of also offering >>>> CLI for: >>>> >>>> * SimplePush >>>> * UnifiedPush >>>> >>>> An early (hacky) version of a SimplePush CLI is located here: >>>> >>>> https://github.com/matzew/simplepush-cli >>>> >>>> The neat thing - I think - you can ignore the nasty version string, >>>> in that case the current timestamp is used. The CLI has been tested w/ our >>>> Quickstart on SimplePush ([1]) >>>> >>>> The actual code for the "SimplePushClient.java" file could be than >>>> also be reused inside of the UnifiedPush Server - my current code here is >>>> very much the code from the UnifiedPush Server (except here I am using >>>> OKHttp) >>>> >>>> thoughts? >>>> >>>> -Matthias >>>> >>>> [1] https://github.com/aerogear/aerogear-simplepush-quickstart >>>> >>>> >>>> -- >>>> 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 >>>> >>>> >>>> >>> >>> -- >>> Sent from Gmail Mobile >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing listaerogear-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >>> >> >> -- >> Sent from Gmail Mobile >> >> >> _______________________________________________ >> aerogear-dev mailing listaerogear-dev at lists.jboss.orghttps://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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140204/33938c39/attachment.html From corinnekrych at gmail.com Tue Feb 4 02:50:08 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Tue, 4 Feb 2014 08:50:08 +0100 Subject: [aerogear-dev] iOS weekly meeting Message-ID: <2B45D240-C2CA-4E20-825A-63579B79DBD5@gmail.com> Hello folks As usually meeting will be at 2pm (CET time zone). Agenda could be found here: http://oksoclap.com/p/iOS-meeting-04-02-2014 Feel free to add items, meet you there. ++ Corinne From matzew at apache.org Tue Feb 4 03:00:05 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 4 Feb 2014 09:00:05 +0100 Subject: [aerogear-dev] iOS weekly meeting In-Reply-To: <2B45D240-C2CA-4E20-825A-63579B79DBD5@gmail.com> References: <2B45D240-C2CA-4E20-825A-63579B79DBD5@gmail.com> Message-ID: When do we plan on releasing the 1.4 ? On Tuesday, February 4, 2014, Corinne Krych wrote: > Hello folks > > As usually meeting will be at 2pm (CET time zone). > Agenda could be found here: > http://oksoclap.com/p/iOS-meeting-04-02-2014 > > Feel free to add items, meet you there. > > ++ > Corinne > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Sent from Gmail Mobile -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140204/fefc63a4/attachment.html From corinnekrych at gmail.com Tue Feb 4 03:04:32 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Tue, 4 Feb 2014 09:04:32 +0100 Subject: [aerogear-dev] [sync] To pipe or not to pipe? Message-ID: Hello all, I started doing demo app Buddies and Hobbies [1] (same idea than luke?s one [2]). But instead of usin gcomplete separate chanel I wrapped Pipe within SyncPipe [3]. Questions: 1. looking at Luke?s work I didn?t see the usage of pipe at all. 2. do we want to reuse Pipe protocol/interface for sync Pipe or use a different one? I rather use the pipe underneath as we don?t want to reimplement Paging, upload etc... wdyt guys? With our actual server [4], we need adjust to serve REST endpoint. Ugly harcoded it (for now) to serve my purpose. ++ Corinne [1] https://github.com/corinnekrych/aerogear-ios-cookbook/tree/sync.demo.recipe/Hobbies [2] https://github.com/lholmquist/ag-js-ds-poc [3] https://github.com/corinnekrych/aerogear-sync-ios [4] https://github.com/corinnekrych/aerogear-sync-server/blob/master/server/src/main/java/org/jboss/aerogear/sync/rest/RestChannelHandler.java#L49 From matzew at apache.org Tue Feb 4 03:10:30 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 4 Feb 2014 09:10:30 +0100 Subject: [aerogear-dev] [sync] To pipe or not to pipe? In-Reply-To: References: Message-ID: I can delete my iOS-sync-poc, right? On Tuesday, February 4, 2014, Corinne Krych wrote: > Hello all, > > I started doing demo app Buddies and Hobbies [1] (same idea than luke's > one [2]). But instead of usin gcomplete separate chanel I wrapped Pipe > within SyncPipe [3]. Questions: > 1. looking at Luke's work I didn't see the usage of pipe at all. > 2. do we want to reuse Pipe protocol/interface for sync Pipe or use a > different one? > I rather use the pipe underneath as we don't want to reimplement Paging, > upload etc... > wdyt guys? > > With our actual server [4], we need adjust to serve REST endpoint. Ugly > harcoded it (for now) to serve my purpose. > > ++ > Corinne > [1] > https://github.com/corinnekrych/aerogear-ios-cookbook/tree/sync.demo.recipe/Hobbies > [2] https://github.com/lholmquist/ag-js-ds-poc > [3] https://github.com/corinnekrych/aerogear-sync-ios > [4] > https://github.com/corinnekrych/aerogear-sync-server/blob/master/server/src/main/java/org/jboss/aerogear/sync/rest/RestChannelHandler.java#L49 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Sent from Gmail Mobile -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140204/821943d4/attachment-0001.html From corinnekrych at gmail.com Tue Feb 4 03:11:27 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Tue, 4 Feb 2014 09:11:27 +0100 Subject: [aerogear-dev] [iOS] small libs Message-ID: Hello iOS folks I?ve started looking at sync part, I?ve created a separate repo [1]. For now, this lib is dependant on iOS-core. does is worth having it separate for folks that what to use core without sync? Same question applies for encrypted store. Right no encrypted store are part of iOS-core. do we want to separate it for people who want core without encrypted store ? what about people who all it all, encrypted store+sync, we?ll have to manage correctly transitive dependencies. wdty? ++ Corinne [1] https://github.com/corinnekrych/aerogear-sync-ios From corinnekrych at gmail.com Tue Feb 4 03:12:43 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Tue, 4 Feb 2014 09:12:43 +0100 Subject: [aerogear-dev] iOS weekly meeting In-Reply-To: References: <2B45D240-C2CA-4E20-825A-63579B79DBD5@gmail.com> Message-ID: a question for our meeting, lots left items crypto related, i think. On 04 Feb 2014, at 09:00, Matthias Wessendorf wrote: > When do we plan on releasing the 1.4 ? > > On Tuesday, February 4, 2014, Corinne Krych wrote: > Hello folks > > As usually meeting will be at 2pm (CET time zone). > Agenda could be found here: > http://oksoclap.com/p/iOS-meeting-04-02-2014 > > Feel free to add items, meet you there. > > ++ > Corinne > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > -- > Sent from Gmail Mobile > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From corinnekrych at gmail.com Tue Feb 4 03:13:45 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Tue, 4 Feb 2014 09:13:45 +0100 Subject: [aerogear-dev] [sync] To pipe or not to pipe? In-Reply-To: References: Message-ID: <548066C6-FC90-4B03-8A21-F5D02399A313@gmail.com> Please don?t, your version (close to mine for interface) but is without pipe. So it depends the way we want to go. ++ Corinne On 04 Feb 2014, at 09:10, Matthias Wessendorf wrote: > I can delete my iOS-sync-poc, right? > > On Tuesday, February 4, 2014, Corinne Krych wrote: > Hello all, > > I started doing demo app Buddies and Hobbies [1] (same idea than luke?s one [2]). But instead of usin gcomplete separate chanel I wrapped Pipe within SyncPipe [3]. Questions: > 1. looking at Luke?s work I didn?t see the usage of pipe at all. > 2. do we want to reuse Pipe protocol/interface for sync Pipe or use a different one? > I rather use the pipe underneath as we don?t want to reimplement Paging, upload etc... > wdyt guys? > > With our actual server [4], we need adjust to serve REST endpoint. Ugly harcoded it (for now) to serve my purpose. > > ++ > Corinne > [1] https://github.com/corinnekrych/aerogear-ios-cookbook/tree/sync.demo.recipe/Hobbies > [2] https://github.com/lholmquist/ag-js-ds-poc > [3] https://github.com/corinnekrych/aerogear-sync-ios > [4] https://github.com/corinnekrych/aerogear-sync-server/blob/master/server/src/main/java/org/jboss/aerogear/sync/rest/RestChannelHandler.java#L49 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > -- > Sent from Gmail Mobile > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From matzew at apache.org Tue Feb 4 03:15:31 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 4 Feb 2014 09:15:31 +0100 Subject: [aerogear-dev] [iOS] small libs In-Reply-To: References: Message-ID: On Tue, Feb 4, 2014 at 9:11 AM, Corinne Krych wrote: > Hello iOS folks > > I've started looking at sync part, I've created a separate repo [1]. For > now, this lib is dependant on iOS-core. does is worth having it separate > for folks that what to use core without sync? > yes > Same question applies for encrypted store. Right now encrypted store are > part of iOS-core. do we want to separate it for people who want core > without encrypted store ? > I do like the idea of separation > what about people who all it all, encrypted store+sync, we'll have to > manage correctly transitive dependencies. > could we bundle something like an 'AeroGear-All-You-Can-Eat-iOS' (similar like something you can do w/ the maven-shade-plugin?). Adding Andrea, perhaps he has an idea on that > > wdty? > > ++ > Corinne > [1] https://github.com/corinnekrych/aerogear-sync-ios > _______________________________________________ > 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/20140204/2b1297db/attachment.html From matzew at apache.org Tue Feb 4 03:16:01 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 4 Feb 2014 09:16:01 +0100 Subject: [aerogear-dev] [sync] To pipe or not to pipe? In-Reply-To: <548066C6-FC90-4B03-8A21-F5D02399A313@gmail.com> References: <548066C6-FC90-4B03-8A21-F5D02399A313@gmail.com> Message-ID: Ok, does not hurt to keep it around :-) On Tue, Feb 4, 2014 at 9:13 AM, Corinne Krych wrote: > Please don't, your version (close to mine for interface) but is without > pipe. > So it depends the way we want to go. > ++ > Corinne > On 04 Feb 2014, at 09:10, Matthias Wessendorf wrote: > > > I can delete my iOS-sync-poc, right? > > > > On Tuesday, February 4, 2014, Corinne Krych > wrote: > > Hello all, > > > > I started doing demo app Buddies and Hobbies [1] (same idea than luke's > one [2]). But instead of usin gcomplete separate chanel I wrapped Pipe > within SyncPipe [3]. Questions: > > 1. looking at Luke's work I didn't see the usage of pipe at all. > > 2. do we want to reuse Pipe protocol/interface for sync Pipe or use a > different one? > > I rather use the pipe underneath as we don't want to reimplement Paging, > upload etc... > > wdyt guys? > > > > With our actual server [4], we need adjust to serve REST endpoint. Ugly > harcoded it (for now) to serve my purpose. > > > > ++ > > Corinne > > [1] > https://github.com/corinnekrych/aerogear-ios-cookbook/tree/sync.demo.recipe/Hobbies > > [2] https://github.com/lholmquist/ag-js-ds-poc > > [3] https://github.com/corinnekrych/aerogear-sync-ios > > [4] > https://github.com/corinnekrych/aerogear-sync-server/blob/master/server/src/main/java/org/jboss/aerogear/sync/rest/RestChannelHandler.java#L49 > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > -- > > Sent from Gmail Mobile > > _______________________________________________ > > 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/20140204/4a74ea14/attachment.html From daniel.bevenius at gmail.com Tue Feb 4 04:23:20 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Tue, 4 Feb 2014 10:23:20 +0100 Subject: [aerogear-dev] [sync] To pipe or not to pipe? In-Reply-To: References: <548066C6-FC90-4B03-8A21-F5D02399A313@gmail.com> Message-ID: Regarding the issue with the sync-server and the context path, I've tried to adress it here: https://github.com/danbev/aerogear-sync-server/tree/context-path-support I'll take a shot at running the your demo and see if the above works but I need to update my env first (cocoapods version etc). On 4 February 2014 09:16, Matthias Wessendorf wrote: > Ok, does not hurt to keep it around :-) > > > On Tue, Feb 4, 2014 at 9:13 AM, Corinne Krych wrote: > >> Please don't, your version (close to mine for interface) but is without >> pipe. >> So it depends the way we want to go. >> ++ >> Corinne >> On 04 Feb 2014, at 09:10, Matthias Wessendorf wrote: >> >> > I can delete my iOS-sync-poc, right? >> > >> > On Tuesday, February 4, 2014, Corinne Krych >> wrote: >> > Hello all, >> > >> > I started doing demo app Buddies and Hobbies [1] (same idea than luke's >> one [2]). But instead of usin gcomplete separate chanel I wrapped Pipe >> within SyncPipe [3]. Questions: >> > 1. looking at Luke's work I didn't see the usage of pipe at all. >> > 2. do we want to reuse Pipe protocol/interface for sync Pipe or use a >> different one? >> > I rather use the pipe underneath as we don't want to reimplement >> Paging, upload etc... >> > wdyt guys? >> > >> > With our actual server [4], we need adjust to serve REST endpoint. Ugly >> harcoded it (for now) to serve my purpose. >> > >> > ++ >> > Corinne >> > [1] >> https://github.com/corinnekrych/aerogear-ios-cookbook/tree/sync.demo.recipe/Hobbies >> > [2] https://github.com/lholmquist/ag-js-ds-poc >> > [3] https://github.com/corinnekrych/aerogear-sync-ios >> > [4] >> https://github.com/corinnekrych/aerogear-sync-server/blob/master/server/src/main/java/org/jboss/aerogear/sync/rest/RestChannelHandler.java#L49 >> > _______________________________________________ >> > aerogear-dev mailing list >> > aerogear-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > >> > >> > -- >> > Sent from Gmail Mobile >> > _______________________________________________ >> > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140204/4b34285b/attachment-0001.html From corinnekrych at gmail.com Tue Feb 4 06:26:05 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Tue, 4 Feb 2014 12:26:05 +0100 Subject: [aerogear-dev] [sync] To pipe or not to pipe? In-Reply-To: References: <548066C6-FC90-4B03-8A21-F5D02399A313@gmail.com> Message-ID: Cool I've tested with your modified sync-server, modify parseJason stuff (temporary hack) and it works just fine. ++ Corinne On 4 February 2014 10:23, Daniel Bevenius wrote: > Regarding the issue with the sync-server and the context path, I've tried > to adress it here: > https://github.com/danbev/aerogear-sync-server/tree/context-path-support > > I'll take a shot at running the your demo and see if the above works but I > need to update my env first (cocoapods version etc). > > > > > On 4 February 2014 09:16, Matthias Wessendorf wrote: > >> Ok, does not hurt to keep it around :-) >> >> >> On Tue, Feb 4, 2014 at 9:13 AM, Corinne Krych wrote: >> >>> Please don't, your version (close to mine for interface) but is without >>> pipe. >>> So it depends the way we want to go. >>> ++ >>> Corinne >>> On 04 Feb 2014, at 09:10, Matthias Wessendorf wrote: >>> >>> > I can delete my iOS-sync-poc, right? >>> > >>> > On Tuesday, February 4, 2014, Corinne Krych >>> wrote: >>> > Hello all, >>> > >>> > I started doing demo app Buddies and Hobbies [1] (same idea than >>> luke's one [2]). But instead of usin gcomplete separate chanel I wrapped >>> Pipe within SyncPipe [3]. Questions: >>> > 1. looking at Luke's work I didn't see the usage of pipe at all. >>> > 2. do we want to reuse Pipe protocol/interface for sync Pipe or use a >>> different one? >>> > I rather use the pipe underneath as we don't want to reimplement >>> Paging, upload etc... >>> > wdyt guys? >>> > >>> > With our actual server [4], we need adjust to serve REST endpoint. >>> Ugly harcoded it (for now) to serve my purpose. >>> > >>> > ++ >>> > Corinne >>> > [1] >>> https://github.com/corinnekrych/aerogear-ios-cookbook/tree/sync.demo.recipe/Hobbies >>> > [2] https://github.com/lholmquist/ag-js-ds-poc >>> > [3] https://github.com/corinnekrych/aerogear-sync-ios >>> > [4] >>> https://github.com/corinnekrych/aerogear-sync-server/blob/master/server/src/main/java/org/jboss/aerogear/sync/rest/RestChannelHandler.java#L49 >>> > _______________________________________________ >>> > aerogear-dev mailing list >>> > aerogear-dev at lists.jboss.org >>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> > >>> > >>> > -- >>> > Sent from Gmail Mobile >>> > _______________________________________________ >>> > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140204/f3b702d5/attachment.html From corinnekrych at gmail.com Tue Feb 4 07:39:29 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Tue, 4 Feb 2014 13:39:29 +0100 Subject: [aerogear-dev] [iOS] small libs In-Reply-To: References: Message-ID: <3E247C9A-880A-4411-9D68-264565C78FE0@gmail.com> On 04 Feb 2014, at 09:15, Matthias Wessendorf wrote: > > > > On Tue, Feb 4, 2014 at 9:11 AM, Corinne Krych wrote: > Hello iOS folks > > I?ve started looking at sync part, I?ve created a separate repo [1]. For now, this lib is dependant on iOS-core. does is worth having it separate for folks that what to use core without sync? > > yes > > Same question applies for encrypted store. Right now encrypted store are part of iOS-core. do we want to separate it for people who want core without encrypted store ? > > I do like the idea of separation Just for that i?ve created https://issues.jboss.org/browse/AGIOS-160 > > what about people who all it all, encrypted store+sync, we?ll have to manage correctly transitive dependencies. > > could we bundle something like an 'AeroGear-All-You-Can-Eat-iOS' (similar like something you can do w/ the maven-shade-plugin?). Adding Andrea, perhaps he has an idea on that Yep i guess we could have an aerogear-ios repo which gather all you can eat Podspec aerogear-ios could be renamed aerogear-core-ios. Coiuld be revisited in 2.0+ Track in that JIRA https://issues.jboss.org/browse/AGIOS-161 > > > wdty? > > ++ > Corinne > [1] https://github.com/corinnekrych/aerogear-sync-ios > _______________________________________________ > 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 From corinnekrych at gmail.com Tue Feb 4 07:55:16 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Tue, 4 Feb 2014 13:55:16 +0100 Subject: [aerogear-dev] Mutable vs Immutable for AGMemoryStore and AGPropertyStore In-Reply-To: References: <2BC0CB71-5EAD-4AA6-9495-AD86CD122BD6@gmail.com> Message-ID: <4E2E9378-95F1-4CBE-88EC-545AFFF62D37@gmail.com> Hello all, Time to bring back the topic, on the immutability vs mutable issue for memory (an espicially plist) storage. read method should return an immutable object. Make it all immutable will help consistency. thoughts? ++ Corinne On 25 Nov 2013, at 23:41, Corinne Krych wrote: > I see actually 2 correlated problems in the described use case: > > 1. Immutability. [store readAll] return a mutable object I can then modify without using 'save' method. In Objective-C, mutability is a strong concept [1]. > But then immutability is not well supported in all languages... unmodifedCollection in Java not quite the same than immutable. > I see 2 options: > a) make slight API changes to cater both way like: > void save(T item) > could be replaced by > T save(T item) > b) change only iOS implementation and accept slight differences as each language idiomatic > 2. PList Storage dump the whole content of memory storage in one file whether you go for save one element or save all element. But if we have immutability then it wouldn't be such a problem. > > ++ > Corinne > [1]https://developer.apple.com/library/mac/documentation/general/conceptual/CocoaEncyclopedia/ObjectMutability/ObjectMutability.html > > > On 25 November 2013 22:17, Christos Vasilakis wrote: > This effect is most visible in the Memory storage implementations, since the mutable objects returned can be modified without the user asks for an explicitly 'save' operation. In the scenario described, regardless if you did save or not, a later 'read' operation on the store, would have returned a possible modified object (done outside the store periphery). > > Other store types (aka SQL) don't suffer from this, since all read operations request the last state from permanent store. > > It all comes to this: > a 'read' operation on a store _must_ guarantee to return the state of an object previously 'saved'. If the memory storage implementation fails on it, then 'read' should be fixed using each platform mutability semantics. If not mistaken, I believe this effect of mem storage is exhibited on our other platforms too. > > - > Christos > > > On Nov 25, 2013, at 3:24 PM, Corinne Krych wrote: > > > > Hello Guys, > > > > Using AGPropertyListStorage in Xmas app [1], I run into this interesting issue: > > > > In the app I retrieve a NSArray of NSMutableDictionary, I get a mutable copy of the NSArray and I save encrypted data in it > > I decrypt some of the data in memory BUT I actually don't want those to be saved decrypted into permanent storage. > > And then let's say I add some more data with encrypted value then I save this dato to my AGProperListStorage. Just this one. > > But surprise, if I look in my permenet storage, I see my newly data encrypted but the other data I ecrypted in memory were saved decrypted > > > > What happened? > > In one word: shallow mutable copy of NSArray. > > My mutable array still point to original MSMutableDictionary and when saving one data to permanent storage the all memory is dumped into plist resulting in decrypted value to be stored. > > > > How did I fixed it? > > Using deep mutable copy see in [2]. > > > > In AGMemoryStorage (and its inherited AGPropertyListStorage) we use NSMutableDictionary because you can save item (represented as Key/Value with NSMutableDictionary) without id, the store will take care of generating this id and assign it back into the item. > > > > Even the AGMemoryStorage which returns a NSArray of NSMutableDictionary is misleading because you can actually do > > NSArray myArray = [store reallAll] > > and then modify the contain of the memory storage without using save. > > > > That experience brings the topic whether it's a good pratice to use mutable object > > > > Options > > - option1: stick to immutable objects whithin the AGStore and let the save method return an immutable NSDictinary containing the item > > - option2: leave it as it is, responsability of user to do deep copy > > - others ? > > > > Personal Preference go for option1 which I found less confusing. > > > > ++ > > Corinne > > [1] https://github.com/corinnekrych/aerogear-ios-cookbook/blob/master/Xmas/Xmas.md > > [2] https://github.com/corinnekrych/aerogear-ios-cookbook/blob/master/Xmas/Xmas/Classes/Controller/AGGiftListCollectionViewController.m#L66 > > _______________________________________________ > > 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 > From matzew at apache.org Tue Feb 4 08:01:39 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 4 Feb 2014 14:01:39 +0100 Subject: [aerogear-dev] Mutable vs Immutable for AGMemoryStore and AGPropertyStore In-Reply-To: <4E2E9378-95F1-4CBE-88EC-545AFFF62D37@gmail.com> References: <2BC0CB71-5EAD-4AA6-9495-AD86CD122BD6@gmail.com> <4E2E9378-95F1-4CBE-88EC-545AFFF62D37@gmail.com> Message-ID: consistency FTW On Tue, Feb 4, 2014 at 1:55 PM, Corinne Krych wrote: > Hello all, > > Time to bring back the topic, on the immutability vs mutable issue for > memory (an espicially plist) storage. > read method should return an immutable object. Make it all immutable will > help consistency. > thoughts? > ++ > Corinne > > On 25 Nov 2013, at 23:41, Corinne Krych wrote: > > > I see actually 2 correlated problems in the described use case: > > > > 1. Immutability. [store readAll] return a mutable object I can then > modify without using 'save' method. In Objective-C, mutability is a strong > concept [1]. > > But then immutability is not well supported in all languages... > unmodifedCollection in Java not quite the same than immutable. > > I see 2 options: > > a) make slight API changes to cater both way like: > > void save(T item) > > could be replaced by > > T save(T item) > > b) change only iOS implementation and accept slight differences as each > language idiomatic > > 2. PList Storage dump the whole content of memory storage in one file > whether you go for save one element or save all element. But if we have > immutability then it wouldn't be such a problem. > > > > ++ > > Corinne > > [1] > https://developer.apple.com/library/mac/documentation/general/conceptual/CocoaEncyclopedia/ObjectMutability/ObjectMutability.html > > > > > > On 25 November 2013 22:17, Christos Vasilakis > wrote: > > This effect is most visible in the Memory storage implementations, since > the mutable objects returned can be modified without the user asks for an > explicitly 'save' operation. In the scenario described, regardless if you > did save or not, a later 'read' operation on the store, would have returned > a possible modified object (done outside the store periphery). > > > > Other store types (aka SQL) don't suffer from this, since all read > operations request the last state from permanent store. > > > > It all comes to this: > > a 'read' operation on a store _must_ guarantee to return the state of an > object previously 'saved'. If the memory storage implementation fails on > it, then 'read' should be fixed using each platform mutability semantics. > If not mistaken, I believe this effect of mem storage is exhibited on our > other platforms too. > > > > - > > Christos > > > > > On Nov 25, 2013, at 3:24 PM, Corinne Krych > wrote: > > > > > > Hello Guys, > > > > > > Using AGPropertyListStorage in Xmas app [1], I run into this > interesting issue: > > > > > > In the app I retrieve a NSArray of NSMutableDictionary, I get a > mutable copy of the NSArray and I save encrypted data in it > > > I decrypt some of the data in memory BUT I actually don't want those > to be saved decrypted into permanent storage. > > > And then let's say I add some more data with encrypted value then I > save this dato to my AGProperListStorage. Just this one. > > > But surprise, if I look in my permenet storage, I see my newly data > encrypted but the other data I ecrypted in memory were saved decrypted > > > > > > What happened? > > > In one word: shallow mutable copy of NSArray. > > > My mutable array still point to original MSMutableDictionary and when > saving one data to permanent storage the all memory is dumped into plist > resulting in decrypted value to be stored. > > > > > > How did I fixed it? > > > Using deep mutable copy see in [2]. > > > > > > In AGMemoryStorage (and its inherited AGPropertyListStorage) we use > NSMutableDictionary because you can save item (represented as Key/Value > with NSMutableDictionary) without id, the store will take care of > generating this id and assign it back into the item. > > > > > > Even the AGMemoryStorage which returns a NSArray of > NSMutableDictionary is misleading because you can actually do > > > NSArray myArray = [store reallAll] > > > and then modify the contain of the memory storage without using save. > > > > > > That experience brings the topic whether it's a good pratice to use > mutable object > > > > > > Options > > > - option1: stick to immutable objects whithin the AGStore and let the > save method return an immutable NSDictinary containing the item > > > - option2: leave it as it is, responsability of user to do deep copy > > > - others ? > > > > > > Personal Preference go for option1 which I found less confusing. > > > > > > ++ > > > Corinne > > > [1] > https://github.com/corinnekrych/aerogear-ios-cookbook/blob/master/Xmas/Xmas.md > > > [2] > https://github.com/corinnekrych/aerogear-ios-cookbook/blob/master/Xmas/Xmas/Classes/Controller/AGGiftListCollectionViewController.m#L66 > > > _______________________________________________ > > > 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 > > > > > _______________________________________________ > 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/20140204/df599e87/attachment-0001.html From corinnekrych at gmail.com Tue Feb 4 08:14:47 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Tue, 4 Feb 2014 14:14:47 +0100 Subject: [aerogear-dev] iOS weekly meeting In-Reply-To: References: <2B45D240-C2CA-4E20-825A-63579B79DBD5@gmail.com> Message-ID: <7DCE1D03-7502-4EE3-8175-80379155D08D@gmail.com> Due to Lazy bott, we?ll do the iOs meeting tomorrow same time. ++ Corinne On 04 Feb 2014, at 09:12, Corinne Krych wrote: > a question for our meeting, lots left items crypto related, i think. > On 04 Feb 2014, at 09:00, Matthias Wessendorf wrote: > >> When do we plan on releasing the 1.4 ? >> >> On Tuesday, February 4, 2014, Corinne Krych wrote: >> Hello folks >> >> As usually meeting will be at 2pm (CET time zone). >> Agenda could be found here: >> http://oksoclap.com/p/iOS-meeting-04-02-2014 >> >> Feel free to add items, meet you there. >> >> ++ >> Corinne >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> -- >> Sent from Gmail Mobile >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > From corinnekrych at gmail.com Tue Feb 4 08:33:13 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Tue, 4 Feb 2014 14:33:13 +0100 Subject: [aerogear-dev] Mutable vs Immutable for AGMemoryStore and AGPropertyStore In-Reply-To: References: <2BC0CB71-5EAD-4AA6-9495-AD86CD122BD6@gmail.com> Message-ID: Hello all, Time to bring back the topic, on the immutability vs mutable issue for memory (an especially plist) storage. read method should return an immutable object. Make it all immutable will help consistency. thoughts? ++ Corinne On 25 Nov 2013, at 23:41, Corinne Krych wrote: I see actually 2 correlated problems in the described use case: 1. Immutability. [store readAll] return a mutable object I can then modify without using 'save' method. In Objective-C, mutability is a strong concept [1]. But then immutability is not well supported in all languages... unmodifedCollection in Java not quite the same than immutable. I see 2 options: a) make slight API changes to cater both way like: void save(T item) could be replaced by T save(T item) b) change only iOS implementation and accept slight differences as each language idiomatic 2. PList Storage dump the whole content of memory storage in one file whether you go for save one element or save all element. But if we have immutability then it wouldn't be such a problem. ++ Corinne [1] https://developer.apple.com/library/mac/documentation/general/conceptual/CocoaEncyclopedia/ObjectMutability/ObjectMutability.html On 25 November 2013 22:17, Christos Vasilakis wrote: This effect is most visible in the Memory storage implementations, since the mutable objects returned can be modified without the user asks for an explicitly 'save' operation. In the scenario described, regardless if you did save or not, a later 'read' operation on the store, would have returned a possible modified object (done outside the store periphery). Other store types (aka SQL) don't suffer from this, since all read operations request the last state from permanent store. It all comes to this: a 'read' operation on a store _must_ guarantee to return the state of an object previously 'saved'. If the memory storage implementation fails on it, then 'read' should be fixed using each platform mutability semantics. If not mistaken, I believe this effect of mem storage is exhibited on our other platforms too. - Christos > On Nov 25, 2013, at 3:24 PM, Corinne Krych wrote: > > Hello Guys, > > Using AGPropertyListStorage in Xmas app [1], I run into this interesting issue: > > In the app I retrieve a NSArray of NSMutableDictionary, I get a mutable copy of the NSArray and I save encrypted data in it > I decrypt some of the data in memory BUT I actually don't want those to be saved decrypted into permanent storage. > And then let's say I add some more data with encrypted value then I save this dato to my AGProperListStorage. Just this one. > But surprise, if I look in my permenet storage, I see my newly data encrypted but the other data I ecrypted in memory were saved decrypted > > What happened? > In one word: shallow mutable copy of NSArray. > My mutable array still point to original MSMutableDictionary and when saving one data to permanent storage the all memory is dumped into plist resulting in decrypted value to be stored. > > How did I fixed it? > Using deep mutable copy see in [2]. > > In AGMemoryStorage (and its inherited AGPropertyListStorage) we use NSMutableDictionary because you can save item (represented as Key/Value with NSMutableDictionary) without id, the store will take care of generating this id and assign it back into the item. > > Even the AGMemoryStorage which returns a NSArray of NSMutableDictionary is misleading because you can actually do > NSArray myArray = [store reallAll] > and then modify the contain of the memory storage without using save. > > That experience brings the topic whether it's a good pratice to use mutable object > > Options > - option1: stick to immutable objects whithin the AGStore and let the save method return an immutable NSDictinary containing the item > - option2: leave it as it is, responsability of user to do deep copy > - others ? > > Personal Preference go for option1 which I found less confusing. > > ++ > Corinne > [1] https://github.com/corinnekrych/aerogear-ios-cookbook/blob/master/Xmas/Xmas.md > [2] https://github.com/corinnekrych/aerogear-ios-cookbook/blob/master/Xmas/Xmas/Classes/Controller/AGGiftListCollectionViewController.m#L66 > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140204/9b32575b/attachment.html From kpiwko at redhat.com Tue Feb 4 11:02:57 2014 From: kpiwko at redhat.com (Karel Piwko) Date: Tue, 4 Feb 2014 17:02:57 +0100 Subject: [aerogear-dev] [iOS] small libs In-Reply-To: References: Message-ID: <20140204170257.0c396f7b@kapy-ntb-x220> I believe that CocoaPods address this concern via subspecs - https://github.com/CocoaPods/CocoaPods/wiki/The-podspec-format http://guides.cocoapods.org/making/specs-and-specs-repo.html However, AIUI, this would require all Aerogear iOS related code to share one Git repository or at least have some git submodules setup. Submodule setup will be nasty for releasing new versions. PodSpec guide additionally says that spec should include all subspec by default, if user wants to be selective, he can do so by enumerating subspecs. http://guides.cocoapods.org/syntax/podspec.html#default_subspec My $0.02, Karel On Tue, 4 Feb 2014 09:11:27 +0100 Corinne Krych wrote: > Hello iOS folks > > I?ve started looking at sync part, I?ve created a separate repo [1]. For now, > this lib is dependant on iOS-core. does is worth having it separate for folks > that what to use core without sync? Same question applies for encrypted > store. Right no encrypted store are part of iOS-core. do we want to separate > it for people who want core without encrypted store ? what about people who > all it all, encrypted store+sync, we?ll have to manage correctly transitive > dependencies. wdty? > > ++ > Corinne > [1] https://github.com/corinnekrych/aerogear-sync-ios > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From supittma at redhat.com Tue Feb 4 11:42:25 2014 From: supittma at redhat.com (Summers Pittman) Date: Tue, 04 Feb 2014 11:42:25 -0500 Subject: [aerogear-dev] [sync] To pipe or not to pipe? In-Reply-To: References: Message-ID: <52F11871.1090808@redhat.com> On 02/04/2014 03:04 AM, Corinne Krych wrote: > Hello all, > > I started doing demo app Buddies and Hobbies [1] (same idea than luke?s one [2]). But instead of usin gcomplete separate chanel I wrapped Pipe within SyncPipe [3]. Questions: > 1. looking at Luke?s work I didn?t see the usage of pipe at all. > 2. do we want to reuse Pipe protocol/interface for sync Pipe or use a different one? > I rather use the pipe underneath as we don?t want to reimplement Paging, upload etc... > wdyt guys? I don't think extending Pipe is the best idea. However, I feel that any synchronizer should use pipes under the hood. Think composition over inheritance. Also overloading the read and save methods will get rather rough when we also have to check for conflicts and handle responses from the server. A SyncPipe could be the implementation the sync system works in iOS, but I don't think it should be part of the spec/protocol. > > With our actual server [4], we need adjust to serve REST endpoint. Ugly harcoded it (for now) to serve my purpose. > > ++ > Corinne > [1] https://github.com/corinnekrych/aerogear-ios-cookbook/tree/sync.demo.recipe/Hobbies > [2] https://github.com/lholmquist/ag-js-ds-poc > [3] https://github.com/corinnekrych/aerogear-sync-ios > [4] https://github.com/corinnekrych/aerogear-sync-server/blob/master/server/src/main/java/org/jboss/aerogear/sync/rest/RestChannelHandler.java#L49 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From lholmqui at redhat.com Tue Feb 4 11:44:39 2014 From: lholmqui at redhat.com (Luke Holmquist) Date: Tue, 4 Feb 2014 11:44:39 -0500 (EST) Subject: [aerogear-dev] [sync] To pipe or not to pipe? In-Reply-To: <52F11871.1090808@redhat.com> References: <52F11871.1090808@redhat.com> Message-ID: Sent from my iPhone > On Feb 4, 2014, at 11:42 AM, Summers Pittman wrote: > >> On 02/04/2014 03:04 AM, Corinne Krych wrote: >> Hello all, >> >> I started doing demo app Buddies and Hobbies [1] (same idea than luke?s one [2]). But instead of usin gcomplete separate chanel I wrapped Pipe within SyncPipe [3]. Questions: >> 1. looking at Luke?s work I didn?t see the usage of pipe at all. >> 2. do we want to reuse Pipe protocol/interface for sync Pipe or use a different one? >> I rather use the pipe underneath as we don?t want to reimplement Paging, upload etc... >> wdyt guys? > I don't think extending Pipe is the best idea. However, I feel that any > synchronizer should use pipes under the hood. > > Think composition over inheritance. Also overloading the read and save > methods will get rather rough when we also have to check for conflicts > and handle responses from the server. > > A SyncPipe could be the implementation the sync system works in iOS, but > I don't think it should be part of the spec/protocol. > +1 > >> >> With our actual server [4], we need adjust to serve REST endpoint. Ugly harcoded it (for now) to serve my purpose. >> >> ++ >> Corinne >> [1] https://github.com/corinnekrych/aerogear-ios-cookbook/tree/sync.demo.recipe/Hobbies >> [2] https://github.com/lholmquist/ag-js-ds-poc >> [3] https://github.com/corinnekrych/aerogear-sync-ios >> [4] https://github.com/corinnekrych/aerogear-sync-server/blob/master/server/src/main/java/org/jboss/aerogear/sync/rest/RestChannelHandler.java#L49 >> _______________________________________________ >> 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 From matzew at apache.org Tue Feb 4 11:52:09 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 4 Feb 2014 17:52:09 +0100 Subject: [aerogear-dev] [sync] To pipe or not to pipe? In-Reply-To: <52F11871.1090808@redhat.com> References: <52F11871.1090808@redhat.com> Message-ID: On Tue, Feb 4, 2014 at 5:42 PM, Summers Pittman wrote: > On 02/04/2014 03:04 AM, Corinne Krych wrote: > > Hello all, > > > > I started doing demo app Buddies and Hobbies [1] (same idea than luke's > one [2]). But instead of usin gcomplete separate chanel I wrapped Pipe > within SyncPipe [3]. Questions: > > 1. looking at Luke's work I didn't see the usage of pipe at all. > > 2. do we want to reuse Pipe protocol/interface for sync Pipe or use a > different one? > > I rather use the pipe underneath as we don't want to reimplement Paging, > upload etc... > > wdyt guys? > I don't think extending Pipe is the best idea. However, I feel that any > synchronizer should use pipes under the hood. > +1 > > Think composition over inheritance. Also overloading the read and save > methods will get rather rough when we also have to check for conflicts > and handle responses from the server. > +1 > > A SyncPipe could be the implementation the sync system works in iOS, not sure I get this > but > I don't think it should be part of the spec/protocol. > > > > > > With our actual server [4], we need adjust to serve REST endpoint. Ugly > harcoded it (for now) to serve my purpose. > > > > ++ > > Corinne > > [1] > https://github.com/corinnekrych/aerogear-ios-cookbook/tree/sync.demo.recipe/Hobbies > > [2] https://github.com/lholmquist/ag-js-ds-poc > > [3] https://github.com/corinnekrych/aerogear-sync-ios > > [4] > https://github.com/corinnekrych/aerogear-sync-server/blob/master/server/src/main/java/org/jboss/aerogear/sync/rest/RestChannelHandler.java#L49 > > _______________________________________________ > > 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/20140204/f001d0ec/attachment-0001.html From supittma at redhat.com Tue Feb 4 12:10:26 2014 From: supittma at redhat.com (Summers Pittman) Date: Tue, 04 Feb 2014 12:10:26 -0500 Subject: [aerogear-dev] [sync] To pipe or not to pipe? In-Reply-To: References: <52F11871.1090808@redhat.com> Message-ID: <52F11F02.3060007@redhat.com> On 02/04/2014 11:52 AM, Matthias Wessendorf wrote: > > > > On Tue, Feb 4, 2014 at 5:42 PM, Summers Pittman > wrote: > > On 02/04/2014 03:04 AM, Corinne Krych wrote: > > Hello all, > > > > I started doing demo app Buddies and Hobbies [1] (same idea than > luke's one [2]). But instead of usin gcomplete separate chanel I > wrapped Pipe within SyncPipe [3]. Questions: > > 1. looking at Luke's work I didn't see the usage of pipe at all. > > 2. do we want to reuse Pipe protocol/interface for sync Pipe or > use a different one? > > I rather use the pipe underneath as we don't want to reimplement > Paging, upload etc... > > wdyt guys? > I don't think extending Pipe is the best idea. However, I feel > that any > synchronizer should use pipes under the hood. > > > +1 > > > Think composition over inheritance. Also overloading the read and save > methods will get rather rough when we also have to check for conflicts > and handle responses from the server. > > > +1 > > > A SyncPipe could be the implementation the sync system works in iOS, > > > not sure I get this Sorry was a merge error on my part when I was writing the email. I meant that there isn't anything wrong with making a sync pipe for making implementing sync on iOS easier. I just don't think it should be part of the platform. > but > I don't think it should be part of the spec/protocol. > > > > > > With our actual server [4], we need adjust to serve REST > endpoint. Ugly harcoded it (for now) to serve my purpose. > > > > ++ > > Corinne > > [1] > https://github.com/corinnekrych/aerogear-ios-cookbook/tree/sync.demo.recipe/Hobbies > > [2] https://github.com/lholmquist/ag-js-ds-poc > > [3] https://github.com/corinnekrych/aerogear-sync-ios > > [4] > https://github.com/corinnekrych/aerogear-sync-server/blob/master/server/src/main/java/org/jboss/aerogear/sync/rest/RestChannelHandler.java#L49 > > _______________________________________________ > > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140204/8de020e4/attachment.html From kpiwko at redhat.com Tue Feb 4 12:13:39 2014 From: kpiwko at redhat.com (Karel Piwko) Date: Tue, 4 Feb 2014 18:13:39 +0100 Subject: [aerogear-dev] Aerogear UPS + Keycloak cartridge combined together POC Message-ID: <20140204181339.60267f2c@kapy-ntb-x220> Hey, I've combined Aerogear UPS and Keycloak cartridges together. You can check the results at: https://agpushkeycloak-mobileqa.rhcloud.com/ (admin/password) https://keycloak-mobileqa.rhcloud.com/ (admin/password) For keycloak, I have used original cart [1]: $ rhc app create -g small --no-git keycloak https://raw.github.com/stianst/openshift-keycloak-cartridge/master/metadata/manifest.yml For UPS, I have modified matzew's one stored in my repo [2] and modified UPS [3]: $ rhc app create -g small --no-git agpushkeycloak mysql-5.1 'http://cartreflect-claytondev.cloud.com/reflect?github=kpiwko/openshift-origin-cartridge-aerogear-push&commit=a45f93afaa275de082f9da749bce13fb33acdb75' There are some gotchas though: * keycloak.json - I'm not sure how this will be addressed by WF subsystem. We still need a way how to pass keycloak.json to UPS cartridge, which is AS7 and we can't ask user to modify standalone.xml anyway. However, we could make a hook on OpenShift - user will add keycloak.json to git repo and it will automagically put at right location. Could we have a hook in Keycloak to load keycloak.json from external location? Or should we rather do some war exploding magic? * AS7-3227 I worked this around by doing parameter injection for SecurityContext in UPS. Nasty. Can we make newer RESTEasy part of Keycloak package for AS7? Any better option? * Ember in UPS is firing AJAX request to REST Endpoints on the same domain. However, as it goes through Keycloak Auth Server, this is considered CORS request. I had to configure Web Origin for UPS application. This is confusing to me, Origin header should be transparent for Keycloak as I'm firing request to the same domain. Note this does not happen in Firefox, which identifies same domain and avoids Origin header. I need some insight here from more skilled people. * I wasn't able to keep http->https rewriting valve with Keycloak to avoid UPS usage via http protocol. I'll go deeper into that. * Changes to Web Origin in Keycloak admin UI are not reflected to already logged users. They need to log out first. * Missing logout button in UPS. Related to previous point. Let me know if you want me to convert some of these points to JIRAs in AGPUSH or KEYCLOAK projects. Also, let me please now if I should have configured something differently. Thanks, Karel [1] https://github.com/stianst/openshift-keycloak-cartridge [2] https://github.com/kpiwko/openshift-origin-cartridge-aerogear-push/tree/keycloak [3] https://github.com/kpiwko/aerogear-unifiedpush-server/tree/keycloak-openshift More detailed steps: 1/ Create Keycloak cart 2/ Add AeroGear-UnifiedPush realm with roles admin, user 3/ Add ag-push app with scopes admin, user, allow Web Origin for UPS cart location 4/ Get keycloak.json 5/ Enable CORS in keycloak.json, modify password 6/ Add keycloak.json to aerogear-unifiedpush-server/src/main/webapp/WEB-INF 7/ Package UPS via 'mvn clean package' 8/ Put war into openshift-origin-cartridge-aerogear-push/versions/0.9.0/standalone/deployments 9/ Push that online 10/ Create UPS cart using reflector cartridge (use commit sha1 if not using master), enable mysql-5.1 gear as well 11/ Create an user with roles admin/user in AeroGear-UnifiedPush realm 12/ Enjoy UPS secured by Keycloak. Have a big cup of coffee. From matzew at apache.org Tue Feb 4 12:14:35 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 4 Feb 2014 18:14:35 +0100 Subject: [aerogear-dev] [sync] To pipe or not to pipe? In-Reply-To: <52F11F02.3060007@redhat.com> References: <52F11871.1090808@redhat.com> <52F11F02.3060007@redhat.com> Message-ID: On Tue, Feb 4, 2014 at 6:10 PM, Summers Pittman wrote: > On 02/04/2014 11:52 AM, Matthias Wessendorf wrote: > > > > > On Tue, Feb 4, 2014 at 5:42 PM, Summers Pittman wrote: > >> On 02/04/2014 03:04 AM, Corinne Krych wrote: >> > Hello all, >> > >> > I started doing demo app Buddies and Hobbies [1] (same idea than luke's >> one [2]). But instead of usin gcomplete separate chanel I wrapped Pipe >> within SyncPipe [3]. Questions: >> > 1. looking at Luke's work I didn't see the usage of pipe at all. >> > 2. do we want to reuse Pipe protocol/interface for sync Pipe or use a >> different one? >> > I rather use the pipe underneath as we don't want to reimplement >> Paging, upload etc... >> > wdyt guys? >> I don't think extending Pipe is the best idea. However, I feel that any >> synchronizer should use pipes under the hood. >> > > +1 > >> >> Think composition over inheritance. Also overloading the read and save >> methods will get rather rough when we also have to check for conflicts >> and handle responses from the server. >> > > +1 > > >> >> A SyncPipe could be the implementation the sync system works in iOS, > > > not sure I get this > > Sorry was a merge error on my part when I was writing the email. > > I meant that there isn't anything wrong with making a sync pipe for making > implementing sync on iOS easier. I just don't think it should be part of > the platform. > Ah! ok :-) At least it sounds like a good idea to leverage the pipes internally, instead of making a AGSyncPipe > > > > >> but >> I don't think it should be part of the spec/protocol. >> >> >> > >> > With our actual server [4], we need adjust to serve REST endpoint. Ugly >> harcoded it (for now) to serve my purpose. >> > >> > ++ >> > Corinne >> > [1] >> https://github.com/corinnekrych/aerogear-ios-cookbook/tree/sync.demo.recipe/Hobbies >> > [2] https://github.com/lholmquist/ag-js-ds-poc >> > [3] https://github.com/corinnekrych/aerogear-sync-ios >> > [4] >> https://github.com/corinnekrych/aerogear-sync-server/blob/master/server/src/main/java/org/jboss/aerogear/sync/rest/RestChannelHandler.java#L49 >> > _______________________________________________ >> > 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 listaerogear-dev at lists.jboss.orghttps://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/20140204/319bca42/attachment-0001.html From matzew at apache.org Tue Feb 4 12:20:43 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 4 Feb 2014 18:20:43 +0100 Subject: [aerogear-dev] Aerogear UPS + Keycloak cartridge combined together POC In-Reply-To: <20140204181339.60267f2c@kapy-ntb-x220> References: <20140204181339.60267f2c@kapy-ntb-x220> Message-ID: On Tue, Feb 4, 2014 at 6:13 PM, Karel Piwko wrote: > Hey, > > I've combined Aerogear UPS and Keycloak cartridges together. You can check > the > results at: > > https://agpushkeycloak-mobileqa.rhcloud.com/ (admin/password) > https://keycloak-mobileqa.rhcloud.com/ (admin/password) > > I think it would be awesome if the keycloak bits would be included into the UPS bits, to have something OOTB, instead of pointing to a different server (CORS) > For keycloak, I have used original cart [1]: > > $ rhc app create -g small --no-git keycloak > > https://raw.github.com/stianst/openshift-keycloak-cartridge/master/metadata/manifest.yml > > For UPS, I have modified matzew's one stored in my repo [2] and modified > UPS > [3]: > > $ rhc app create -g small --no-git agpushkeycloak mysql-5.1 > ' > http://cartreflect-claytondev.cloud.com/reflect?github=kpiwko/openshift-origin-cartridge-aerogear-push&commit=a45f93afaa275de082f9da749bce13fb33acdb75 > ' > > There are some gotchas though: > > * keycloak.json - I'm not sure how this will be addressed by WF subsystem. the public-key needs to be, as far as I can see, included inside of the standalone.xml (keycloak subsystem section). Which is somewhat a similar issue; I think, if I get it right, that means as you plan to support more and more 'realms', you keep editing the standalone xml. > We > still need a way how to pass keycloak.json to UPS cartridge, which is AS7 > and we can't ask user to modify standalone.xml anyway. However, we could > make > a hook on OpenShift - user will add keycloak.json to git repo and it will > automagically put at right location. Could we have a hook in Keycloak to > load keycloak.json from external location? Or should we rather do some > war > exploding magic? > * AS7-3227 I worked this around by doing parameter injection for > SecurityContext in UPS. Nasty. Can we make newer RESTEasy part of > Keycloak > package for AS7? Any better option? > * Ember in UPS is firing AJAX request to REST Endpoints on the same domain. > However, as it goes through Keycloak Auth Server, this is considered CORS > request. I had to configure Web Origin for UPS application. This is > confusing to me, Origin header should be transparent for Keycloak as I'm > firing request to the same domain. Note this does not happen in Firefox, > which identifies same domain and avoids Origin header. I need some > insight > here from more skilled people. > hmmmmm .... sounds 'good' :-) > * I wasn't able to keep http->https rewriting valve with Keycloak to avoid > UPS > usage via http protocol. I'll go deeper into that. > https is enforced on our UPS cartridge > * Changes to Web Origin in Keycloak admin UI are not reflected to already > logged > users. They need to log out first. > * Missing logout button in UPS. Related to previous point. > > Let me know if you want me to convert some of these points to JIRAs in > AGPUSH > or KEYCLOAK projects. Also, let me please now if I should have configured > something differently. > > Thanks, > > Karel > > [1] https://github.com/stianst/openshift-keycloak-cartridge > [2] > > https://github.com/kpiwko/openshift-origin-cartridge-aerogear-push/tree/keycloak > [3] > > https://github.com/kpiwko/aerogear-unifiedpush-server/tree/keycloak-openshift > > More detailed steps: > > 1/ Create Keycloak cart > 2/ Add AeroGear-UnifiedPush realm with roles admin, user > 3/ Add ag-push app with scopes admin, user, allow Web Origin for UPS cart > location > 4/ Get keycloak.json > 5/ Enable CORS in keycloak.json, modify password > 6/ Add keycloak.json to aerogear-unifiedpush-server/src/main/webapp/WEB-INF > 7/ Package UPS via 'mvn clean package' > 8/ Put war into > > openshift-origin-cartridge-aerogear-push/versions/0.9.0/standalone/deployments > 9/ Push that online > 10/ Create UPS cart using reflector cartridge (use commit sha1 if not using > master), enable mysql-5.1 gear as well > 11/ Create an user with roles admin/user in AeroGear-UnifiedPush realm > 12/ Enjoy UPS secured by Keycloak. Have a big cup of coffee. > > > _______________________________________________ > 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/20140204/08ea50fa/attachment.html From matzew at apache.org Tue Feb 4 12:21:10 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 4 Feb 2014 18:21:10 +0100 Subject: [aerogear-dev] Aerogear UPS + Keycloak cartridge combined together POC In-Reply-To: References: <20140204181339.60267f2c@kapy-ntb-x220> Message-ID: oh, this was a cross-post :-) (adding keycloak) On Tue, Feb 4, 2014 at 6:20 PM, Matthias Wessendorf wrote: > > > > On Tue, Feb 4, 2014 at 6:13 PM, Karel Piwko wrote: > >> Hey, >> >> I've combined Aerogear UPS and Keycloak cartridges together. You can >> check the >> results at: >> >> https://agpushkeycloak-mobileqa.rhcloud.com/ (admin/password) >> https://keycloak-mobileqa.rhcloud.com/ (admin/password) >> >> > I think it would be awesome if the keycloak bits would be included into > the UPS bits, to have something OOTB, instead of pointing to a different > server (CORS) > > >> For keycloak, I have used original cart [1]: >> >> $ rhc app create -g small --no-git keycloak >> >> https://raw.github.com/stianst/openshift-keycloak-cartridge/master/metadata/manifest.yml >> >> For UPS, I have modified matzew's one stored in my repo [2] and modified >> UPS >> [3]: >> >> $ rhc app create -g small --no-git agpushkeycloak mysql-5.1 >> ' >> http://cartreflect-claytondev.cloud.com/reflect?github=kpiwko/openshift-origin-cartridge-aerogear-push&commit=a45f93afaa275de082f9da749bce13fb33acdb75 >> ' >> >> There are some gotchas though: >> >> * keycloak.json - I'm not sure how this will be addressed by WF subsystem. > > > the public-key needs to be, as far as I can see, included inside of the > standalone.xml (keycloak subsystem section). > Which is somewhat a similar issue; I think, if I get it right, that means > as you plan to support more and more 'realms', you keep editing the > standalone xml. > > >> We >> still need a way how to pass keycloak.json to UPS cartridge, which is >> AS7 >> and we can't ask user to modify standalone.xml anyway. However, we >> could make >> a hook on OpenShift - user will add keycloak.json to git repo and it >> will >> automagically put at right location. Could we have a hook in Keycloak to >> load keycloak.json from external location? Or should we rather do some >> war >> exploding magic? >> * AS7-3227 I worked this around by doing parameter injection for >> SecurityContext in UPS. Nasty. Can we make newer RESTEasy part of >> Keycloak >> package for AS7? Any better option? >> * Ember in UPS is firing AJAX request to REST Endpoints on the same >> domain. >> However, as it goes through Keycloak Auth Server, this is considered >> CORS >> request. I had to configure Web Origin for UPS application. This is >> confusing to me, Origin header should be transparent for Keycloak as I'm >> firing request to the same domain. Note this does not happen in Firefox, >> which identifies same domain and avoids Origin header. I need some >> insight >> here from more skilled people. >> > > hmmmmm .... sounds 'good' :-) > > >> * I wasn't able to keep http->https rewriting valve with Keycloak to >> avoid UPS >> usage via http protocol. I'll go deeper into that. >> > > https is enforced on our UPS cartridge > > >> * Changes to Web Origin in Keycloak admin UI are not reflected to already >> logged >> users. They need to log out first. >> * Missing logout button in UPS. Related to previous point. >> >> Let me know if you want me to convert some of these points to JIRAs in >> AGPUSH >> or KEYCLOAK projects. Also, let me please now if I should have configured >> something differently. >> >> Thanks, >> >> Karel >> >> [1] https://github.com/stianst/openshift-keycloak-cartridge >> [2] >> >> https://github.com/kpiwko/openshift-origin-cartridge-aerogear-push/tree/keycloak >> [3] >> >> https://github.com/kpiwko/aerogear-unifiedpush-server/tree/keycloak-openshift >> >> More detailed steps: >> >> 1/ Create Keycloak cart >> 2/ Add AeroGear-UnifiedPush realm with roles admin, user >> 3/ Add ag-push app with scopes admin, user, allow Web Origin for UPS cart >> location >> 4/ Get keycloak.json >> 5/ Enable CORS in keycloak.json, modify password >> 6/ Add keycloak.json to >> aerogear-unifiedpush-server/src/main/webapp/WEB-INF >> 7/ Package UPS via 'mvn clean package' >> 8/ Put war into >> >> openshift-origin-cartridge-aerogear-push/versions/0.9.0/standalone/deployments >> 9/ Push that online >> 10/ Create UPS cart using reflector cartridge (use commit sha1 if not >> using >> master), enable mysql-5.1 gear as well >> 11/ Create an user with roles admin/user in AeroGear-UnifiedPush realm >> 12/ Enjoy UPS secured by Keycloak. Have a big cup of coffee. >> >> >> _______________________________________________ >> 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 > -- 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/20140204/7ebc93e2/attachment.html From kpiwko at redhat.com Tue Feb 4 12:34:37 2014 From: kpiwko at redhat.com (Karel Piwko) Date: Tue, 4 Feb 2014 18:34:37 +0100 Subject: [aerogear-dev] Aerogear UPS + Keycloak cartridge combined together POC In-Reply-To: References: <20140204181339.60267f2c@kapy-ntb-x220> Message-ID: <20140204183437.0737d77f@kapy-ntb-x220> On Tue, 4 Feb 2014 18:21:10 +0100 Matthias Wessendorf wrote: > oh, this was a cross-post :-) (adding keycloak) > > > On Tue, Feb 4, 2014 at 6:20 PM, Matthias Wessendorf wrote: > > > > > > > > > On Tue, Feb 4, 2014 at 6:13 PM, Karel Piwko wrote: > > > >> Hey, > >> > >> I've combined Aerogear UPS and Keycloak cartridges together. You can > >> check the > >> results at: > >> > >> https://agpushkeycloak-mobileqa.rhcloud.com/ (admin/password) > >> https://keycloak-mobileqa.rhcloud.com/ (admin/password) > >> > >> > > I think it would be awesome if the keycloak bits would be included into > > the UPS bits, to have something OOTB, instead of pointing to a different > > server (CORS) I've added Keycloak AS7 modules to UPS cart but not admin console. I believe that Keycloak is SaaS, so usage with two different carts reflect reality better. Configuring Keycloak cart once and let all other carts use is seems the right way to me. > > > > > >> For keycloak, I have used original cart [1]: > >> > >> $ rhc app create -g small --no-git keycloak > >> > >> https://raw.github.com/stianst/openshift-keycloak-cartridge/master/metadata/manifest.yml > >> > >> For UPS, I have modified matzew's one stored in my repo [2] and modified > >> UPS > >> [3]: > >> > >> $ rhc app create -g small --no-git agpushkeycloak mysql-5.1 > >> ' > >> http://cartreflect-claytondev.cloud.com/reflect?github=kpiwko/openshift-origin-cartridge-aerogear-push&commit=a45f93afaa275de082f9da749bce13fb33acdb75 > >> ' > >> > >> There are some gotchas though: > >> > >> * keycloak.json - I'm not sure how this will be addressed by WF subsystem. > > > > > > the public-key needs to be, as far as I can see, included inside of the > > standalone.xml (keycloak subsystem section). > > Which is somewhat a similar issue; I think, if I get it right, that means > > as you plan to support more and more 'realms', you keep editing the > > standalone xml. That is great improvement w.r.t. current situation but does not handle OpenShift cart scenarios. > > > > > >> We > >> still need a way how to pass keycloak.json to UPS cartridge, which is > >> AS7 > >> and we can't ask user to modify standalone.xml anyway. However, we > >> could make > >> a hook on OpenShift - user will add keycloak.json to git repo and it > >> will > >> automagically put at right location. Could we have a hook in Keycloak to > >> load keycloak.json from external location? Or should we rather do some > >> war > >> exploding magic? > >> * AS7-3227 I worked this around by doing parameter injection for > >> SecurityContext in UPS. Nasty. Can we make newer RESTEasy part of > >> Keycloak > >> package for AS7? Any better option? > >> * Ember in UPS is firing AJAX request to REST Endpoints on the same > >> domain. > >> However, as it goes through Keycloak Auth Server, this is considered > >> CORS > >> request. I had to configure Web Origin for UPS application. This is > >> confusing to me, Origin header should be transparent for Keycloak as I'm > >> firing request to the same domain. Note this does not happen in Firefox, > >> which identifies same domain and avoids Origin header. I need some > >> insight > >> here from more skilled people. > >> > > > > hmmmmm .... sounds 'good' :-) :-) > > > > > >> * I wasn't able to keep http->https rewriting valve with Keycloak to > >> avoid UPS > >> usage via http protocol. I'll go deeper into that. > >> > > > > https is enforced on our UPS cartridge RI had to remove this enforcement. I'm just trying to put it back. > > > > > >> * Changes to Web Origin in Keycloak admin UI are not reflected to already > >> logged > >> users. They need to log out first. > >> * Missing logout button in UPS. Related to previous point. > >> > >> Let me know if you want me to convert some of these points to JIRAs in > >> AGPUSH > >> or KEYCLOAK projects. Also, let me please now if I should have configured > >> something differently. > >> > >> Thanks, > >> > >> Karel > >> > >> [1] https://github.com/stianst/openshift-keycloak-cartridge > >> [2] > >> > >> https://github.com/kpiwko/openshift-origin-cartridge-aerogear-push/tree/keycloak > >> [3] > >> > >> https://github.com/kpiwko/aerogear-unifiedpush-server/tree/keycloak-openshift > >> > >> More detailed steps: > >> > >> 1/ Create Keycloak cart > >> 2/ Add AeroGear-UnifiedPush realm with roles admin, user > >> 3/ Add ag-push app with scopes admin, user, allow Web Origin for UPS cart > >> location > >> 4/ Get keycloak.json > >> 5/ Enable CORS in keycloak.json, modify password > >> 6/ Add keycloak.json to > >> aerogear-unifiedpush-server/src/main/webapp/WEB-INF > >> 7/ Package UPS via 'mvn clean package' > >> 8/ Put war into > >> > >> openshift-origin-cartridge-aerogear-push/versions/0.9.0/standalone/deployments > >> 9/ Push that online > >> 10/ Create UPS cart using reflector cartridge (use commit sha1 if not > >> using > >> master), enable mysql-5.1 gear as well > >> 11/ Create an user with roles admin/user in AeroGear-UnifiedPush realm > >> 12/ Enjoy UPS secured by Keycloak. Have a big cup of coffee. > >> > >> > >> _______________________________________________ > >> 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 > > > > > From matzew at apache.org Tue Feb 4 12:38:03 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 4 Feb 2014 18:38:03 +0100 Subject: [aerogear-dev] [keycloak-dev] Aerogear UPS + Keycloak cartridge combined together POC In-Reply-To: <20140204183437.0737d77f@kapy-ntb-x220> References: <20140204181339.60267f2c@kapy-ntb-x220> <20140204183437.0737d77f@kapy-ntb-x220> Message-ID: On Tue, Feb 4, 2014 at 6:34 PM, Karel Piwko wrote: > On Tue, 4 Feb 2014 18:21:10 +0100 > Matthias Wessendorf wrote: > > > oh, this was a cross-post :-) (adding keycloak) > > > > > > On Tue, Feb 4, 2014 at 6:20 PM, Matthias Wessendorf >wrote: > > > > > > > > > > > > > > On Tue, Feb 4, 2014 at 6:13 PM, Karel Piwko wrote: > > > > > >> Hey, > > >> > > >> I've combined Aerogear UPS and Keycloak cartridges together. You can > > >> check the > > >> results at: > > >> > > >> https://agpushkeycloak-mobileqa.rhcloud.com/ (admin/password) > > >> https://keycloak-mobileqa.rhcloud.com/ (admin/password) > > >> > > >> > > > I think it would be awesome if the keycloak bits would be included into > > > the UPS bits, to have something OOTB, instead of pointing to a > different > > > server (CORS) > > I've added Keycloak AS7 modules to UPS cart but not admin console. I > believe > that Keycloak is SaaS, so usage with two different carts reflect reality > better. > Configuring Keycloak cart once and let all other carts use is seems the > right > way to me. > > there is IMO pros and cons in both ways > > > > > > > > >> For keycloak, I have used original cart [1]: > > >> > > >> $ rhc app create -g small --no-git keycloak > > >> > > >> > https://raw.github.com/stianst/openshift-keycloak-cartridge/master/metadata/manifest.yml > > >> > > >> For UPS, I have modified matzew's one stored in my repo [2] and > modified > > >> UPS > > >> [3]: > > >> > > >> $ rhc app create -g small --no-git agpushkeycloak mysql-5.1 > > >> ' > > >> > http://cartreflect-claytondev.cloud.com/reflect?github=kpiwko/openshift-origin-cartridge-aerogear-push&commit=a45f93afaa275de082f9da749bce13fb33acdb75 > > >> ' > > >> > > >> There are some gotchas though: > > >> > > >> * keycloak.json - I'm not sure how this will be addressed by WF > subsystem. > > > > > > > > > the public-key needs to be, as far as I can see, included inside of the > > > standalone.xml (keycloak subsystem section). > > > Which is somewhat a similar issue; I think, if I get it right, that > means > > > as you plan to support more and more 'realms', you keep editing the > > > standalone xml. > > That is great improvement w.r.t. current situation but does not handle > OpenShift > cart scenarios. > > > > > > > > > >> We > > >> still need a way how to pass keycloak.json to UPS cartridge, which > is > > >> AS7 > > >> and we can't ask user to modify standalone.xml anyway. However, we > > >> could make > > >> a hook on OpenShift - user will add keycloak.json to git repo and it > > >> will > > >> automagically put at right location. Could we have a hook in > Keycloak to > > >> load keycloak.json from external location? Or should we rather do > some > > >> war > > >> exploding magic? > > >> * AS7-3227 I worked this around by doing parameter injection for > > >> SecurityContext in UPS. Nasty. Can we make newer RESTEasy part of > > >> Keycloak > > >> package for AS7? Any better option? > > >> * Ember in UPS is firing AJAX request to REST Endpoints on the same > > >> domain. > > >> However, as it goes through Keycloak Auth Server, this is considered > > >> CORS > > >> request. I had to configure Web Origin for UPS application. This is > > >> confusing to me, Origin header should be transparent for Keycloak > as I'm > > >> firing request to the same domain. Note this does not happen in > Firefox, > > >> which identifies same domain and avoids Origin header. I need some > > >> insight > > >> here from more skilled people. > > >> > > > > > > hmmmmm .... sounds 'good' :-) > :-) > > > > > > > > >> * I wasn't able to keep http->https rewriting valve with Keycloak to > > >> avoid UPS > > >> usage via http protocol. I'll go deeper into that. > > >> > > > > > > https is enforced on our UPS cartridge > RI had to remove this enforcement. I'm just trying to put it back. > > > > > > > > >> * Changes to Web Origin in Keycloak admin UI are not reflected to > already > > >> logged > > >> users. They need to log out first. > > >> * Missing logout button in UPS. Related to previous point. > > >> > > >> Let me know if you want me to convert some of these points to JIRAs in > > >> AGPUSH > > >> or KEYCLOAK projects. Also, let me please now if I should have > configured > > >> something differently. > > >> > > >> Thanks, > > >> > > >> Karel > > >> > > >> [1] https://github.com/stianst/openshift-keycloak-cartridge > > >> [2] > > >> > > >> > https://github.com/kpiwko/openshift-origin-cartridge-aerogear-push/tree/keycloak > > >> [3] > > >> > > >> > https://github.com/kpiwko/aerogear-unifiedpush-server/tree/keycloak-openshift > > >> > > >> More detailed steps: > > >> > > >> 1/ Create Keycloak cart > > >> 2/ Add AeroGear-UnifiedPush realm with roles admin, user > > >> 3/ Add ag-push app with scopes admin, user, allow Web Origin for UPS > cart > > >> location > > >> 4/ Get keycloak.json > > >> 5/ Enable CORS in keycloak.json, modify password > > >> 6/ Add keycloak.json to > > >> aerogear-unifiedpush-server/src/main/webapp/WEB-INF > > >> 7/ Package UPS via 'mvn clean package' > > >> 8/ Put war into > > >> > > >> > openshift-origin-cartridge-aerogear-push/versions/0.9.0/standalone/deployments > > >> 9/ Push that online > > >> 10/ Create UPS cart using reflector cartridge (use commit sha1 if not > > >> using > > >> master), enable mysql-5.1 gear as well > > >> 11/ Create an user with roles admin/user in AeroGear-UnifiedPush realm > > >> 12/ Enjoy UPS secured by Keycloak. Have a big cup of coffee. > > >> > > >> > > >> _______________________________________________ > > >> 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 > > > > > > > > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-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/20140204/854fbd15/attachment.html From corinnekrych at gmail.com Tue Feb 4 14:23:10 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Tue, 4 Feb 2014 20:23:10 +0100 Subject: [aerogear-dev] [sync] To pipe or not to pipe? In-Reply-To: References: <52F11871.1090808@redhat.com> <52F11F02.3060007@redhat.com> Message-ID: Thanks guys! I've got my answers. I agree with you, I'll keep Pipe under the hood but I will define a new protocol as you said 'save' method has 3 callbacks: success, failure conflict using Pipe protocol feels awkward somehow. I'll update ios-sync repo with a new proposal and i'll share it with you shortly so we can discuss further. Once we agree on API we can define spec. ++ Corinne On 4 February 2014 18:14, Matthias Wessendorf wrote: > > > > On Tue, Feb 4, 2014 at 6:10 PM, Summers Pittman wrote: > >> On 02/04/2014 11:52 AM, Matthias Wessendorf wrote: >> >> >> >> >> On Tue, Feb 4, 2014 at 5:42 PM, Summers Pittman wrote: >> >>> On 02/04/2014 03:04 AM, Corinne Krych wrote: >>> > Hello all, >>> > >>> > I started doing demo app Buddies and Hobbies [1] (same idea than >>> luke's one [2]). But instead of usin gcomplete separate chanel I wrapped >>> Pipe within SyncPipe [3]. Questions: >>> > 1. looking at Luke's work I didn't see the usage of pipe at all. >>> > 2. do we want to reuse Pipe protocol/interface for sync Pipe or use a >>> different one? >>> > I rather use the pipe underneath as we don't want to reimplement >>> Paging, upload etc... >>> > wdyt guys? >>> I don't think extending Pipe is the best idea. However, I feel that any >>> synchronizer should use pipes under the hood. >>> >> >> +1 >> >>> >>> Think composition over inheritance. Also overloading the read and save >>> methods will get rather rough when we also have to check for conflicts >>> and handle responses from the server. >>> >> >> +1 >> >> >>> >>> A SyncPipe could be the implementation the sync system works in iOS, >> >> >> not sure I get this >> >> Sorry was a merge error on my part when I was writing the email. >> >> I meant that there isn't anything wrong with making a sync pipe for >> making implementing sync on iOS easier. I just don't think it should be >> part of the platform. >> > > Ah! ok :-) > > At least it sounds like a good idea to leverage the pipes internally, > instead of making a AGSyncPipe > > >> >> >> >> >>> but >>> I don't think it should be part of the spec/protocol. >>> >>> >>> > >>> > With our actual server [4], we need adjust to serve REST endpoint. >>> Ugly harcoded it (for now) to serve my purpose. >>> > >>> > ++ >>> > Corinne >>> > [1] >>> https://github.com/corinnekrych/aerogear-ios-cookbook/tree/sync.demo.recipe/Hobbies >>> > [2] https://github.com/lholmquist/ag-js-ds-poc >>> > [3] https://github.com/corinnekrych/aerogear-sync-ios >>> > [4] >>> https://github.com/corinnekrych/aerogear-sync-server/blob/master/server/src/main/java/org/jboss/aerogear/sync/rest/RestChannelHandler.java#L49 >>> > _______________________________________________ >>> > 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 listaerogear-dev at lists.jboss.orghttps://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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140204/730bd5ae/attachment-0001.html From corinnekrych at gmail.com Tue Feb 4 14:49:28 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Tue, 4 Feb 2014 20:49:28 +0100 Subject: [aerogear-dev] [iOS] small libs In-Reply-To: <20140204170257.0c396f7b@kapy-ntb-x220> References: <20140204170257.0c396f7b@kapy-ntb-x220> Message-ID: +1 Thanks for sharing. On 4 February 2014 17:02, Karel Piwko wrote: > I believe that CocoaPods address this concern via subspecs - > https://github.com/CocoaPods/CocoaPods/wiki/The-podspec-format > http://guides.cocoapods.org/making/specs-and-specs-repo.html > > However, AIUI, this would require all Aerogear iOS related code to share > one > Git repository or at least have some git submodules setup. Submodule setup > will > be nasty for releasing new versions. > > PodSpec guide additionally says that spec should include all subspec by > default, > if user wants to be selective, he can do so by enumerating subspecs. > > http://guides.cocoapods.org/syntax/podspec.html#default_subspec > > My $0.02, > > Karel > > On Tue, 4 Feb 2014 09:11:27 +0100 > Corinne Krych wrote: > > > Hello iOS folks > > > > I've started looking at sync part, I've created a separate repo [1]. For > now, > > this lib is dependant on iOS-core. does is worth having it separate for > folks > > that what to use core without sync? Same question applies for encrypted > > store. Right no encrypted store are part of iOS-core. do we want to > separate > > it for people who want core without encrypted store ? what about people > who > > all it all, encrypted store+sync, we'll have to manage correctly > transitive > > dependencies. wdty? > > > > ++ > > Corinne > > [1] https://github.com/corinnekrych/aerogear-sync-ios > > _______________________________________________ > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140204/995a30b3/attachment.html From lholmqui at redhat.com Tue Feb 4 15:25:30 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Tue, 4 Feb 2014 15:25:30 -0500 Subject: [aerogear-dev] SimplePush CLI In-Reply-To: References: <099DA0A2-DD97-4C8F-90B8-665F20F98B19@redhat.com> <52EFE5CE.40209@gmail.com> <52EFEB68.5010203@gmail.com> Message-ID: <42C979F5-1913-430D-9CD4-5348F8FAE65B@redhat.com> matzew inspired me to also do a node version, https://github.com/lholmquist/aerogear-simplepush-node-client/tree/cli On Feb 4, 2014, at 2:44 AM, Daniel Bevenius wrote: > Cool, will try it out later today! > > > > > On 3 February 2014 22:50, Matthias Wessendorf wrote: > Did a (temporary?) upload of the binary: > > https://github.com/matzew/simplepush-cli/raw/dist/bin/simple-push > > -M > > > On Mon, Feb 3, 2014 at 8:18 PM, JR Conlin wrote: > Ah, makes perfect sense. I'll go back to lurking. > > > On 2014/2/3 11:03 AM, Matthias Wessendorf wrote: >> Yep, works w/ UnifiedPush, and we use thst for testing as well >> >> >> However we need/have java libs fir sending, hence turning that into less verbose CLIs is just a few lines of code :-) >> >> On Monday, February 3, 2014, JR Conlin wrote: >> One other note: >> >> I don't know if this would work for UnifiedPush, but for testing remote REST calls, I tend to use curl >> >> http://curl.haxx.se/ >> >> It's available for nearly every platform known. >> >> It's pretty easy to use on the command line, so sending a PUT would be: >> >> curl -X PUT -d "version=123" http://push.services.mozilla.org/longStringOfCrap >> >> where -X specifies the method to use >> -d specifies the "data" to send in the request >> >> Curl is amazingly powerful once you dig into it and can save a lot of time. Just figured I should share the knowledge. >> >> On 2014/2/3 10:36 AM, Matthias Wessendorf wrote: >>> >>> >>> On Monday, February 3, 2014, Lucas Holmquist wrote: >>> looks pretty neat, >>> >>> i think we can also adapt the node.js versions to also be "installable" for CLI use, similar to how you can also use plugman/cordova cli's api and not just on the command line >>> >>> >>> I had brew in mind for this; will look into this later this week >>> >>> >>> On Feb 3, 2014, at 1:18 PM, Matthias Wessendorf wrote: >>> >>>> Hi, >>>> >>>> while thinking about potential refactorings, and moving some of the java 'sender' code into subprojects I played w/ the ideas of also offering CLI for: >>>> >>>> * SimplePush >>>> * UnifiedPush >>>> >>>> An early (hacky) version of a SimplePush CLI is located here: >>>> >>>> https://github.com/matzew/simplepush-cli >>>> >>>> The neat thing - I think - you can ignore the nasty version string, in that case the current timestamp is used. The CLI has been tested w/ our Quickstart on SimplePush ([1]) >>>> >>>> The actual code for the "SimplePushClient.java" file could be than also be reused inside of the UnifiedPush Server - my current code here is very much the code from the UnifiedPush Server (except here I am using OKHttp) >>>> >>>> thoughts? >>>> >>>> -Matthias >>>> >>>> [1] https://github.com/aerogear/aerogear-simplepush-quickstart >>>> >>>> >>>> -- >>>> 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 >>> >>> >>> >>> -- >>> Sent from Gmail Mobile >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> -- >> Sent from Gmail Mobile >> >> >> _______________________________________________ >> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140204/6873ba8a/attachment.html From scm.blanc at gmail.com Tue Feb 4 15:57:56 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Tue, 4 Feb 2014 21:57:56 +0100 Subject: [aerogear-dev] SimplePush CLI In-Reply-To: <42C979F5-1913-430D-9CD4-5348F8FAE65B@redhat.com> References: <099DA0A2-DD97-4C8F-90B8-665F20F98B19@redhat.com> <52EFE5CE.40209@gmail.com> <52EFEB68.5010203@gmail.com> <42C979F5-1913-430D-9CD4-5348F8FAE65B@redhat.com> Message-ID: awesome Luke ! On Tue, Feb 4, 2014 at 9:25 PM, Lucas Holmquist wrote: > matzew inspired me to also do a node version, > > https://github.com/lholmquist/aerogear-simplepush-node-client/tree/cli > > > On Feb 4, 2014, at 2:44 AM, Daniel Bevenius > wrote: > > Cool, will try it out later today! > > > > > On 3 February 2014 22:50, Matthias Wessendorf wrote: > >> Did a (temporary?) upload of the binary: >> >> https://github.com/matzew/simplepush-cli/raw/dist/bin/simple-push >> >> -M >> >> >> On Mon, Feb 3, 2014 at 8:18 PM, JR Conlin wrote: >> >>> Ah, makes perfect sense. I'll go back to lurking. >>> >>> >>> On 2014/2/3 11:03 AM, Matthias Wessendorf wrote: >>> >>> Yep, works w/ UnifiedPush, and we use thst for testing as well >>> >>> >>> However we need/have java libs fir sending, hence turning that into >>> less verbose CLIs is just a few lines of code :-) >>> >>> On Monday, February 3, 2014, JR Conlin wrote: >>> >>>> One other note: >>>> >>>> I don't know if this would work for UnifiedPush, but for testing remote >>>> REST calls, I tend to use curl >>>> >>>> http://curl.haxx.se/ >>>> >>>> It's available for nearly every platform known. >>>> >>>> It's pretty easy to use on the command line, so sending a PUT would be: >>>> >>>> curl -X PUT -d "version=123" >>>> http://push.services.mozilla.org/longStringOfCrap >>>> >>>> where -X specifies the method to use >>>> -d specifies the "data" to send in the request >>>> >>>> Curl is amazingly powerful once you dig into it and can save a lot of >>>> time. Just figured I should share the knowledge. >>>> >>>> On 2014/2/3 10:36 AM, Matthias Wessendorf wrote: >>>> >>>> >>>> >>>> On Monday, February 3, 2014, Lucas Holmquist >>>> wrote: >>>> >>>>> looks pretty neat, >>>>> >>>>> i think we can also adapt the node.js versions to also be >>>>> "installable" for CLI use, similar to how you can also use plugman/cordova >>>>> cli's api and not just on the command line >>>>> >>>> >>>> >>>> I had brew in mind for this; will look into this later this week >>>> >>>> >>>>> >>>>> On Feb 3, 2014, at 1:18 PM, Matthias Wessendorf >>>>> wrote: >>>>> >>>>> Hi, >>>>> >>>>> while thinking about potential refactorings, and moving some of the >>>>> java 'sender' code into subprojects I played w/ the ideas of also offering >>>>> CLI for: >>>>> >>>>> * SimplePush >>>>> * UnifiedPush >>>>> >>>>> An early (hacky) version of a SimplePush CLI is located here: >>>>> >>>>> https://github.com/matzew/simplepush-cli >>>>> >>>>> The neat thing - I think - you can ignore the nasty version string, >>>>> in that case the current timestamp is used. The CLI has been tested w/ our >>>>> Quickstart on SimplePush ([1]) >>>>> >>>>> The actual code for the "SimplePushClient.java" file could be than >>>>> also be reused inside of the UnifiedPush Server - my current code here is >>>>> very much the code from the UnifiedPush Server (except here I am using >>>>> OKHttp) >>>>> >>>>> thoughts? >>>>> >>>>> -Matthias >>>>> >>>>> [1] https://github.com/aerogear/aerogear-simplepush-quickstart >>>>> >>>>> >>>>> -- >>>>> 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 >>>>> >>>>> >>>>> >>>> >>>> -- >>>> Sent from Gmail Mobile >>>> >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing listaerogear-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>>> >>>> >>> >>> -- >>> Sent from Gmail Mobile >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing listaerogear-dev at lists.jboss.orghttps://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 > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140204/8b437985/attachment-0001.html From cvasilak at gmail.com Wed Feb 5 03:28:20 2014 From: cvasilak at gmail.com (Christos Vasilakis) Date: Wed, 5 Feb 2014 10:28:20 +0200 Subject: [aerogear-dev] [iOS] Apple requires iOS 7 for new apps/updates by Feb 1st In-Reply-To: References: <66BF1C73-3838-4CFD-936E-26FC5282E7E5@gmail.com> Message-ID: <041C11E2-C3CE-4BA6-B2A4-6DE13FE036E9@gmail.com> Hi, I have been thinking that as part of this change[1] of target the lib to iOS 7, in the process updating the internal AFNet lib to 2.0 series also which is optimised for iOS 7. Not sure if I can pause it till our next release or be included in 1.4? wdyth? - Christos [1] https://issues.jboss.org/browse/AGIOS-152 On Jan 16, 2014, at 12:57 PM, Matthias Wessendorf wrote: > > > > On Thu, Jan 16, 2014 at 9:21 AM, Christos Vasilakis wrote: > > On Jan 16, 2014, at 8:31 AM, Matthias Wessendorf wrote: > >> Hi, >> >> in December, while I was away, I missed an email from Apple Developer, telling that by Feb. 1st all app submissions to the store need to be 'optimized' for iOS 7. >> >> "Starting February 1, new apps and app updates submitted to the App Store must be built with the latest version of Xcode 5 and must be optimized for iOS 7. " >> >> >> That's an interesting statement; also for our iOS libraries... - So.... looks like we can simply remove the 'support' / linkage of older SDKs, and straight update to iOS 7... >> >> Thoughts ? > > IMHO it makes sense to move +1 > > What do you think of creating a JIRA for 'optimizing iOS libraries for iOS7" ? > After the 1.4.0 is released, we could do that task, release a 1.5.0 and move on with other items (e.g. like sync) > > > -Matthias > > > > > - > Christos > > >> -Matthias >> >> [1] https://developer.apple.com/news/ >> [2] http://techcrunch.com/2013/12/17/apple-requiring-all-app-submissions-to-be-optimized-for-ios-7-by-feb-1st/ >> >> -- >> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140205/2184ea92/attachment.html From corinnekrych at gmail.com Wed Feb 5 03:33:12 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Wed, 5 Feb 2014 09:33:12 +0100 Subject: [aerogear-dev] [iOS] Apple requires iOS 7 for new apps/updates by Feb 1st In-Reply-To: <041C11E2-C3CE-4BA6-B2A4-6DE13FE036E9@gmail.com> References: <66BF1C73-3838-4CFD-936E-26FC5282E7E5@gmail.com> <041C11E2-C3CE-4BA6-B2A4-6DE13FE036E9@gmail.com> Message-ID: Moving to 2.0 for AFNetworking is a great idea. it may quite an impact though. When are we planning 1.4? ++ Corinne On 05 Feb 2014, at 09:28, Christos Vasilakis wrote: > Hi, > > I have been thinking that as part of this change[1] of target the lib to iOS 7, in the process updating the internal AFNet lib to 2.0 series also which is optimised for iOS 7. Not sure if I can pause it till our next release or be included in 1.4? > > wdyth? > > - > Christos > > [1] https://issues.jboss.org/browse/AGIOS-152 > > On Jan 16, 2014, at 12:57 PM, Matthias Wessendorf wrote: > >> >> >> >> On Thu, Jan 16, 2014 at 9:21 AM, Christos Vasilakis wrote: >> >> On Jan 16, 2014, at 8:31 AM, Matthias Wessendorf wrote: >> >>> Hi, >>> >>> in December, while I was away, I missed an email from Apple Developer, telling that by Feb. 1st all app submissions to the store need to be 'optimized' for iOS 7. >>> >>> "Starting February 1, new apps and app updates submitted to the App Store must be built with the latest version of Xcode 5 and must be optimized for iOS 7. " >>> >>> >>> That's an interesting statement; also for our iOS libraries... - So.... looks like we can simply remove the 'support' / linkage of older SDKs, and straight update to iOS 7... >>> >>> Thoughts ? >> >> IMHO it makes sense to move +1 >> >> What do you think of creating a JIRA for 'optimizing iOS libraries for iOS7" ? >> After the 1.4.0 is released, we could do that task, release a 1.5.0 and move on with other items (e.g. like sync) >> >> >> -Matthias >> >> >> >> >> - >> Christos >> >> >>> -Matthias >>> >>> [1] https://developer.apple.com/news/ >>> [2] http://techcrunch.com/2013/12/17/apple-requiring-all-app-submissions-to-be-optimized-for-ios-7-by-feb-1st/ >>> >>> -- >>> 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 From matzew at apache.org Wed Feb 5 03:36:38 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 5 Feb 2014 09:36:38 +0100 Subject: [aerogear-dev] [iOS] Apple requires iOS 7 for new apps/updates by Feb 1st In-Reply-To: References: <66BF1C73-3838-4CFD-936E-26FC5282E7E5@gmail.com> <041C11E2-C3CE-4BA6-B2A4-6DE13FE036E9@gmail.com> Message-ID: On Wed, Feb 5, 2014 at 9:33 AM, Corinne Krych wrote: > Moving to 2.0 for AFNetworking is a great idea. > it may quite an impact though. > When are we planning 1.4? > I'd agree that moving to AFN2 should be done after 1.4. I think in an older meeting (or email thread), we already talked about getting 1.4 out, update to AFN2 (call it 1.5) and than continue w/ 'scheduled' work (e.g. sync) for 1.6 -M > ++ > Corinne > On 05 Feb 2014, at 09:28, Christos Vasilakis wrote: > > > Hi, > > > > I have been thinking that as part of this change[1] of target the lib to > iOS 7, in the process updating the internal AFNet lib to 2.0 series also > which is optimised for iOS 7. Not sure if I can pause it till our next > release or be included in 1.4? > > > > wdyth? > > > > - > > Christos > > > > [1] https://issues.jboss.org/browse/AGIOS-152 > > > > On Jan 16, 2014, at 12:57 PM, Matthias Wessendorf > wrote: > > > >> > >> > >> > >> On Thu, Jan 16, 2014 at 9:21 AM, Christos Vasilakis > wrote: > >> > >> On Jan 16, 2014, at 8:31 AM, Matthias Wessendorf > wrote: > >> > >>> Hi, > >>> > >>> in December, while I was away, I missed an email from Apple Developer, > telling that by Feb. 1st all app submissions to the store need to be > 'optimized' for iOS 7. > >>> > >>> "Starting February 1, new apps and app updates submitted to the App > Store must be built with the latest version of Xcode 5 and must be > optimized for iOS 7. " > >>> > >>> > >>> That's an interesting statement; also for our iOS libraries... - > So.... looks like we can simply remove the 'support' / linkage of older > SDKs, and straight update to iOS 7... > >>> > >>> Thoughts ? > >> > >> IMHO it makes sense to move +1 > >> > >> What do you think of creating a JIRA for 'optimizing iOS libraries for > iOS7" ? > >> After the 1.4.0 is released, we could do that task, release a 1.5.0 and > move on with other items (e.g. like sync) > >> > >> > >> -Matthias > >> > >> > >> > >> > >> - > >> Christos > >> > >> > >>> -Matthias > >>> > >>> [1] https://developer.apple.com/news/ > >>> [2] > http://techcrunch.com/2013/12/17/apple-requiring-all-app-submissions-to-be-optimized-for-ios-7-by-feb-1st/ > >>> > >>> -- > >>> 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 > > > _______________________________________________ > 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/20140205/3c2af287/attachment.html From corinnekrych at gmail.com Wed Feb 5 03:38:28 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Wed, 5 Feb 2014 09:38:28 +0100 Subject: [aerogear-dev] [iOS] Apple requires iOS 7 for new apps/updates by Feb 1st In-Reply-To: References: <66BF1C73-3838-4CFD-936E-26FC5282E7E5@gmail.com> <041C11E2-C3CE-4BA6-B2A4-6DE13FE036E9@gmail.com> Message-ID: On 05 Feb 2014, at 09:36, Matthias Wessendorf wrote: > > > > On Wed, Feb 5, 2014 at 9:33 AM, Corinne Krych wrote: > Moving to 2.0 for AFNetworking is a great idea. > it may quite an impact though. > When are we planning 1.4? > > I'd agree that moving to AFN2 should be done after 1.4. > I think in an older meeting (or email thread), we already talked about getting 1.4 out, update to AFN2 (call it 1.5) and than continue w/ 'scheduled' work (e.g. sync) for 1.6 > +1 That sounds like a good plan to me > > -M > > > ++ > Corinne > On 05 Feb 2014, at 09:28, Christos Vasilakis wrote: > > > Hi, > > > > I have been thinking that as part of this change[1] of target the lib to iOS 7, in the process updating the internal AFNet lib to 2.0 series also which is optimised for iOS 7. Not sure if I can pause it till our next release or be included in 1.4? > > > > wdyth? > > > > - > > Christos > > > > [1] https://issues.jboss.org/browse/AGIOS-152 > > > > On Jan 16, 2014, at 12:57 PM, Matthias Wessendorf wrote: > > > >> > >> > >> > >> On Thu, Jan 16, 2014 at 9:21 AM, Christos Vasilakis wrote: > >> > >> On Jan 16, 2014, at 8:31 AM, Matthias Wessendorf wrote: > >> > >>> Hi, > >>> > >>> in December, while I was away, I missed an email from Apple Developer, telling that by Feb. 1st all app submissions to the store need to be 'optimized' for iOS 7. > >>> > >>> "Starting February 1, new apps and app updates submitted to the App Store must be built with the latest version of Xcode 5 and must be optimized for iOS 7. " > >>> > >>> > >>> That's an interesting statement; also for our iOS libraries... - So.... looks like we can simply remove the 'support' / linkage of older SDKs, and straight update to iOS 7... > >>> > >>> Thoughts ? > >> > >> IMHO it makes sense to move +1 > >> > >> What do you think of creating a JIRA for 'optimizing iOS libraries for iOS7" ? > >> After the 1.4.0 is released, we could do that task, release a 1.5.0 and move on with other items (e.g. like sync) > >> > >> > >> -Matthias > >> > >> > >> > >> > >> - > >> Christos > >> > >> > >>> -Matthias > >>> > >>> [1] https://developer.apple.com/news/ > >>> [2] http://techcrunch.com/2013/12/17/apple-requiring-all-app-submissions-to-be-optimized-for-ios-7-by-feb-1st/ > >>> > >>> -- > >>> 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 > > > _______________________________________________ > 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 From corinnekrych at gmail.com Wed Feb 5 03:49:10 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Wed, 5 Feb 2014 09:49:10 +0100 Subject: [aerogear-dev] [sync] Diff libraries Message-ID: Hello Ladies and Gentlemen, I was looking for some diff/patch libraries to get differences between 2 objects (either json format of map/array format) ideally in iOS (withpodspec) or in C/C++. To plug into custom conflict management in you sync demo app. Like Luke did using jsondiffpatch in JS [1]. For comparing text there is google-diff-match-patch [2] lib that is implemented in several langagues and format (including iOS). But i couldn?t find a jsondiff liek lib for iOS? I?m asking my favourite oracle (i.e.: the mailing list), see if i get more lucky. ++ Corinne [1] https://github.com/benjamine/JsonDiffPatch [2] https://github.com/JanX2/google-diff-match-patch From cvasilak at gmail.com Wed Feb 5 03:53:35 2014 From: cvasilak at gmail.com (Christos Vasilakis) Date: Wed, 5 Feb 2014 10:53:35 +0200 Subject: [aerogear-dev] [iOS] Apple requires iOS 7 for new apps/updates by Feb 1st In-Reply-To: References: <66BF1C73-3838-4CFD-936E-26FC5282E7E5@gmail.com> <041C11E2-C3CE-4BA6-B2A4-6DE13FE036E9@gmail.com> Message-ID: <7828166D-B8BC-4685-BC1D-4BBDC2001CC1@gmail.com> On Feb 5, 2014, at 10:36 AM, Matthias Wessendorf wrote: > > > > On Wed, Feb 5, 2014 at 9:33 AM, Corinne Krych wrote: > Moving to 2.0 for AFNetworking is a great idea. > it may quite an impact though. > When are we planning 1.4? > > I'd agree that moving to AFN2 should be done after 1.4. > I think in an older meeting (or email thread), we already talked about getting 1.4 out, update to AFN2 (call it 1.5) and than continue w/ 'scheduled' work (e.g. sync) for 1.6 > +1 ok great thanx guys! - Christos > > -M > > > ++ > Corinne > On 05 Feb 2014, at 09:28, Christos Vasilakis wrote: > > > Hi, > > > > I have been thinking that as part of this change[1] of target the lib to iOS 7, in the process updating the internal AFNet lib to 2.0 series also which is optimised for iOS 7. Not sure if I can pause it till our next release or be included in 1.4? > > > > wdyth? > > > > - > > Christos > > > > [1] https://issues.jboss.org/browse/AGIOS-152 > > > > On Jan 16, 2014, at 12:57 PM, Matthias Wessendorf wrote: > > > >> > >> > >> > >> On Thu, Jan 16, 2014 at 9:21 AM, Christos Vasilakis wrote: > >> > >> On Jan 16, 2014, at 8:31 AM, Matthias Wessendorf wrote: > >> > >>> Hi, > >>> > >>> in December, while I was away, I missed an email from Apple Developer, telling that by Feb. 1st all app submissions to the store need to be 'optimized' for iOS 7. > >>> > >>> "Starting February 1, new apps and app updates submitted to the App Store must be built with the latest version of Xcode 5 and must be optimized for iOS 7. " > >>> > >>> > >>> That's an interesting statement; also for our iOS libraries... - So.... looks like we can simply remove the 'support' / linkage of older SDKs, and straight update to iOS 7... > >>> > >>> Thoughts ? > >> > >> IMHO it makes sense to move +1 > >> > >> What do you think of creating a JIRA for 'optimizing iOS libraries for iOS7" ? > >> After the 1.4.0 is released, we could do that task, release a 1.5.0 and move on with other items (e.g. like sync) > >> > >> > >> -Matthias > >> > >> > >> > >> > >> - > >> Christos > >> > >> > >>> -Matthias > >>> > >>> [1] https://developer.apple.com/news/ > >>> [2] http://techcrunch.com/2013/12/17/apple-requiring-all-app-submissions-to-be-optimized-for-ios-7-by-feb-1st/ > >>> > >>> -- > >>> 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 > > > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140205/bc4988b8/attachment.html From kpiwko at redhat.com Wed Feb 5 04:32:18 2014 From: kpiwko at redhat.com (Karel Piwko) Date: Wed, 5 Feb 2014 10:32:18 +0100 Subject: [aerogear-dev] SimplePush CLI In-Reply-To: References: Message-ID: <20140205103218.40efeb64@kapy-ntb-x220> Pure awesomeness. Airlift + real executable plugin FTW. Unfortunately, it does not work on Windows. So Node.js FTW? ;-) On Mon, 3 Feb 2014 19:18:09 +0100 Matthias Wessendorf wrote: > Hi, > > while thinking about potential refactorings, and moving some of the java > 'sender' code into subprojects I played w/ the ideas of also offering CLI > for: > > * SimplePush > * UnifiedPush > > An early (hacky) version of a SimplePush CLI is located here: > > https://github.com/matzew/simplepush-cli > > The neat thing - I think - you can ignore the nasty version string, in that > case the current timestamp is used. The CLI has been tested w/ our > Quickstart on SimplePush ([1]) > > The actual code for the "SimplePushClient.java" file could be than also be > reused inside of the UnifiedPush Server - my current code here is very much > the code from the UnifiedPush Server (except here I am using OKHttp) > > thoughts? > > -Matthias > > [1] https://github.com/aerogear/aerogear-simplepush-quickstart > > From aemmanou at redhat.com Wed Feb 5 04:46:12 2014 From: aemmanou at redhat.com (Apostolos Emmanouilidis) Date: Wed, 05 Feb 2014 10:46:12 +0100 Subject: [aerogear-dev] Aerogear UPS + Keycloak cartridge combined together POC In-Reply-To: <20140204181339.60267f2c@kapy-ntb-x220> References: <20140204181339.60267f2c@kapy-ntb-x220> Message-ID: <1391593572.2541.12.camel@dhcp129-205.brq.redhat.com> This case appears because Chrome and Safari are sending the Origin header on same origin PUT, DELETE & POST requests. On the other side, Firefox does not send the Origin header on same origin requests. As the Keycloak team explained to me, in most JS/HTML apps you'd add origin part of the base url as web origin in the application's settings through the Keycloak administration console. However, this does not apply to non-js based app and that's why the base url is not automatically considered as web origin. Request Method:POST Request Headersview source Accept:application/json, text/javascript, */*; q=0.01 Accept-Encoding:gzip,deflate,sdch Accept-Language:en-US,en;q=0.8,el;q=0.6 Connection:keep-alive Content-Length:15 Content-Type:application/json Cookie:JSESSIONID=Tw9NmJjHUlRO6JnimwyzS1w3.undefined Host:agpushkeycloak-mobileqa.rhcloud.com Origin:http://agpushkeycloak-mobileqa.rhcloud.com Referer:http://agpushkeycloak-mobileqa.rhcloud.com/ User-Agent:Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36 X-Requested-With:XMLHttpRequest On Tue, 2014-02-04 at 18:13 +0100, Karel Piwko wrote: > * Ember in UPS is firing AJAX request to REST Endpoints on the same domain. > However, as it goes through Keycloak Auth Server, this is considered CORS > request. I had to configure Web Origin for UPS application. This is > confusing to me, Origin header should be transparent for Keycloak as I'm > firing request to the same domain. Note this does not happen in Firefox, > which identifies same domain and avoids Origin header. I need some insight > here from more skilled people. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140205/3d6a3595/attachment.html From matzew at apache.org Wed Feb 5 04:47:40 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 5 Feb 2014 10:47:40 +0100 Subject: [aerogear-dev] SimplePush CLI In-Reply-To: <20140205103218.40efeb64@kapy-ntb-x220> References: <20140205103218.40efeb64@kapy-ntb-x220> Message-ID: On Wed, Feb 5, 2014 at 10:32 AM, Karel Piwko wrote: > Pure awesomeness. Airlift + real executable plugin FTW. exactly :) > Unfortunately, it does > not work on Windows. So Node.js FTW? ;-) > what do I know ? Not using windows, nor using node :-) > > On Mon, 3 Feb 2014 19:18:09 +0100 > Matthias Wessendorf wrote: > > > Hi, > > > > while thinking about potential refactorings, and moving some of the java > > 'sender' code into subprojects I played w/ the ideas of also offering CLI > > for: > > > > * SimplePush > > * UnifiedPush > > > > An early (hacky) version of a SimplePush CLI is located here: > > > > https://github.com/matzew/simplepush-cli > > > > The neat thing - I think - you can ignore the nasty version string, in > that > > case the current timestamp is used. The CLI has been tested w/ our > > Quickstart on SimplePush ([1]) > > > > The actual code for the "SimplePushClient.java" file could be than also > be > > reused inside of the UnifiedPush Server - my current code here is very > much > > the code from the UnifiedPush Server (except here I am using OKHttp) > > > > thoughts? > > > > -Matthias > > > > [1] https://github.com/aerogear/aerogear-simplepush-quickstart > > > > > > _______________________________________________ > 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/20140205/b675d684/attachment-0001.html From cvasilak at gmail.com Wed Feb 5 05:23:49 2014 From: cvasilak at gmail.com (Christos Vasilakis) Date: Wed, 5 Feb 2014 12:23:49 +0200 Subject: [aerogear-dev] [sync] Diff libraries In-Reply-To: References: Message-ID: Hi Corinne, i did came across the following diff-match lib[1] might be interested to digg more, as I have seen they all derive from google-diff [1] https://github.com/inquisitiveSoft/DiffMatchPatch-ObjC [+podspec] On Wed, Feb 5, 2014 at 10:49 AM, Corinne Krych wrote: > Hello Ladies and Gentlemen, > > I was looking for some diff/patch libraries to get differences between 2 > objects (either json format of map/array format) ideally in iOS > (withpodspec) or in C/C++. To plug into custom conflict management in you > sync demo app. Like Luke did using jsondiffpatch in JS [1]. > > For comparing text there is google-diff-match-patch [2] lib that is > implemented in several langagues and format (including iOS). > > But i couldn't find a jsondiff liek lib for iOS... I'm asking my favourite > oracle (i.e.: the mailing list), see if i get more lucky. > > ++ > Corinne > [1] https://github.com/benjamine/JsonDiffPatch > [2] https://github.com/JanX2/google-diff-match-patch > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140205/043a261d/attachment.html From matzew at apache.org Wed Feb 5 06:20:20 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 5 Feb 2014 12:20:20 +0100 Subject: [aerogear-dev] Question around encryption for iOS push certificate passphrase Message-ID: Hello, I started to take a quick look at [1], for a better encryption of the passphrase for all the iOS variants (stored as plaintext ATM). For that I started looking at our neat Pbkdf2 class, from AeroGear-Crypto. The idea is to store both: the encrypted password + the salt in the database, instead of the plaintext version of the password/passphrase. Something like here: https://github.com/matzew/psswd-salting/blob/master/src/test/java/net/wessendorf/salt/LittleTest.java#L35-L43 This works fine on things like logins: https://github.com/matzew/psswd-salting/blob/master/src/test/java/net/wessendorf/salt/LittleTest.java#L46-L54 However, I am afraid it does not work for the iOS passphrase, required to connect to Apple - looks like the library we use requires it in plain text... (due to Apple? Not sure...) https://github.com/notnoop/java-apns/blob/master/src/main/java/com/notnoop/apns/ApnsServiceBuilder.java#L159 BTW. here is the relevant usage inside of our UnifiedPush Server: https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/server/src/main/java/org/jboss/aerogear/unifiedpush/message/sender/APNsPushNotificationSender.java#L146 I am now wondering if there is something we can do for [1], in the long run, not now? I see the 'java-apns API' supports passing in a java.security.Keystore, but unfortunately I am not sure if there is an impl. of that which is able to deal w/ encrypted passwords or if something like that might even work at all :-/ Greetings, Matthias [1] https://issues.jboss.org/browse/AGPUSH-358 -- 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/20140205/f97ae407/attachment.html From kpiwko at redhat.com Wed Feb 5 08:35:04 2014 From: kpiwko at redhat.com (Karel Piwko) Date: Wed, 5 Feb 2014 14:35:04 +0100 Subject: [aerogear-dev] [keycloak-dev] Aerogear UPS + Keycloak cartridge combined together POC In-Reply-To: <52F136B9.3090906@redhat.com> References: <20140204181339.60267f2c@kapy-ntb-x220> <52F136B9.3090906@redhat.com> Message-ID: <20140205143504.563c6771@kapy-ntb-x220> On Tue, 04 Feb 2014 13:51:37 -0500 Bill Burke wrote: > > > On 2/4/2014 12:13 PM, Karel Piwko wrote: > > Hey, > > > > I've combined Aerogear UPS and Keycloak cartridges together. You can check > > the results at: > > > > https://agpushkeycloak-mobileqa.rhcloud.com/ (admin/password) > > https://keycloak-mobileqa.rhcloud.com/ (admin/password) > > > > For keycloak, I have used original cart [1]: > > > > $ rhc app create -g small --no-git keycloak > > https://raw.github.com/stianst/openshift-keycloak-cartridge/master/metadata/manifest.yml > > > > For UPS, I have modified matzew's one stored in my repo [2] and modified UPS > > [3]: Given your comments, I'll modify setup to have (primarily) single cart option. Should I keep two carts setup? It at least seems as a good QE test case ;-) Note, I will either have to wait for WF8 Final (due to Hibernate bug in CR1) or base cart on AS7. > > > > $ rhc app create -g small --no-git agpushkeycloak mysql-5.1 > > 'http://cartreflect-claytondev.cloud.com/reflect?github=kpiwko/openshift-origin-cartridge-aerogear-push&commit=a45f93afaa275de082f9da749bce13fb33acdb75' > > > > There are some gotchas though: > > > > * keycloak.json - I'm not sure how this will be addressed by WF subsystem. > > We still need a way how to pass keycloak.json to UPS cartridge, which is AS7 > > and we can't ask user to modify standalone.xml anyway. However, we could > > make a hook on OpenShift - user will add keycloak.json to git repo and it > > will automagically put at right location. Could we have a hook in Keycloak > > to load keycloak.json from external location? Or should we rather do some > > war exploding magic? > > I need to go through Stan's work. I want to be able to configure the > subsystem from the keycloak admin console without having to create a > keycloak.json file. I just don't know yet if the subsystem will work on > AS7. This will work for app and Keycloak being deployed on a single server. It does not solve SaaS scenario - keycloak admin console can configure subsystem of current WF(AS) only. Keycloak would need to manage subsystem of a remote WF - I doubt this would ever be possible with AS7 on OpenShift and I think security concerns of such setup are not even allowing this on WF8. > > > > * AS7-3227 I worked this around by doing parameter injection for > > SecurityContext in UPS. Nasty. Can we make newer RESTEasy part of > > Keycloak package for AS7? Any better option? > > This is an UPS issue right? Keycloak WAR bundles is own Resteasy and > excludes built in one. Well, it is either keycloak packaging issue or documentation issue (or problem here in Brno in between chair and keyboard). I've added keycloak-as7-adapter-dist to AS7. Keycloak WAR was added to different cartridge. So, AS7 (UPS) is still using old RESTEasy 2.x. This will be fixed if newer RESTEasy is packaged inside of keycloak-as7-adapter-dist instead of Keycloak WAR. IIRC this was setup pre alpha-1. > > > * Ember in UPS is firing AJAX request to REST Endpoints on the same domain. > > However, as it goes through Keycloak Auth Server, this is considered CORS > > request. I had to configure Web Origin for UPS application. This is > > confusing to me, Origin header should be transparent for Keycloak as I'm > > firing request to the same domain. Note this does not happen in Firefox, > > which identifies same domain and avoids Origin header. I need some > > insight here from more skilled people. > > JIRA for this one. I've only tested/experimented with CORS on Firefox. https://issues.jboss.org/browse/KEYCLOAK-281 > > > * I wasn't able to keep http->https rewriting valve with Keycloak to avoid > > UPS usage via http protocol. I'll go deeper into that. > > * Changes to Web Origin in Keycloak admin UI are not reflected to already > > logged users. They need to log out first. > > We can't fix this. But it will be mitigated when we add refresh tokens. > We'll have a short token lifespan that needs to be refreshed. The > refresh will pick up the changes. > Sounds good. > > More detailed steps: > > > > 1/ Create Keycloak cart > > 2/ Add AeroGear-UnifiedPush realm with roles admin, user > > 3/ Add ag-push app with scopes admin, user, allow Web Origin for UPS cart > > location > > > Couldn't the cartridge come with a pre-configured keycloak database? We > also have a realm import option, but we haven't documented the json > format yet. Also there's the admin REST interface you could use to > create the realm/application/roles etc. If I'm able to get public key via admin REST interface, it should be possible to preconfigure that. Setup will be complicated but possible with Keycloak subsystem. Having realm import json format documentation will definitely help here. > > > > 4/ Get keycloak.json > > 5/ Enable CORS in keycloak.json, modify password > > 6/ Add keycloak.json to aerogear-unifiedpush-server/src/main/webapp/WEB-INF > > 7/ Package UPS via 'mvn clean package' > > 8/ Put war into > > openshift-origin-cartridge-aerogear-push/versions/0.9.0/standalone/deployments > > This may be able to be done from the keycloak console. Right, but not in SaaS scenario, only if app and Keycloak run on same instance. > > > 9/ Push that online > > 10/ Create UPS cart using reflector cartridge (use commit sha1 if not using > > master), enable mysql-5.1 gear as well > > 11/ Create an user with roles admin/user in AeroGear-UnifiedPush realm > > 12/ Enjoy UPS secured by Keycloak. Have a big cup of coffee. > > > > :) > From cvasilak at gmail.com Wed Feb 5 08:35:10 2014 From: cvasilak at gmail.com (Christos Vasilakis) Date: Wed, 5 Feb 2014 15:35:10 +0200 Subject: [aerogear-dev] iOS weekly meeting In-Reply-To: <2B45D240-C2CA-4E20-825A-63579B79DBD5@gmail.com> References: <2B45D240-C2CA-4E20-825A-63579B79DBD5@gmail.com> Message-ID: <53289614-8661-4E78-995F-84A1BE5E4846@gmail.com> fyi, meeting notes: jbott:Meeting ended Wed Feb 5 13:22:36 2014 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) [3:33pm]jbott:Minutes: http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-02-05-12.49.html [3:33pm]jbott:Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-02-05-12.49.txt [3:33pm]jbott:Log: http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-02-05-12.49.log.html On Feb 4, 2014, at 9:50 AM, Corinne Krych wrote: > Hello folks > > As usually meeting will be at 2pm (CET time zone). > Agenda could be found here: > http://oksoclap.com/p/iOS-meeting-04-02-2014 > > Feel free to add items, meet you there. > > ++ > Corinne > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From kpiwko at redhat.com Wed Feb 5 08:17:22 2014 From: kpiwko at redhat.com (Karel Piwko) Date: Wed, 5 Feb 2014 14:17:22 +0100 Subject: [aerogear-dev] [keycloak-dev] Aerogear UPS + Keycloak cartridge combined together POC In-Reply-To: <52F136B9.3090906@redhat.com> References: <20140204181339.60267f2c@kapy-ntb-x220> <52F136B9.3090906@redhat.com> Message-ID: <20140205141722.0e810a3c@kapy-ntb-x220> On Tue, 04 Feb 2014 13:51:37 -0500 Bill Burke wrote: > > > On 2/4/2014 12:13 PM, Karel Piwko wrote: > > Hey, > > > > I've combined Aerogear UPS and Keycloak cartridges together. You can check > > the results at: > > > > https://agpushkeycloak-mobileqa.rhcloud.com/ (admin/password) > > https://keycloak-mobileqa.rhcloud.com/ (admin/password) > > > > For keycloak, I have used original cart [1]: > > > > $ rhc app create -g small --no-git keycloak > > https://raw.github.com/stianst/openshift-keycloak-cartridge/master/metadata/manifest.yml > > > > For UPS, I have modified matzew's one stored in my repo [2] and modified UPS > > [3]: Given your comments, I'll modify setup to have (primarily) single cart option. Should I keep two carts setup? It at least seems as a good QE test case ;-) Note, I will either have to wait for WF8 Final (due to Hibernate bug in CR1) or base it on AS7. > > > > $ rhc app create -g small --no-git agpushkeycloak mysql-5.1 > > 'http://cartreflect-claytondev.cloud.com/reflect?github=kpiwko/openshift-origin-cartridge-aerogear-push&commit=a45f93afaa275de082f9da749bce13fb33acdb75' > > > > There are some gotchas though: > > > > * keycloak.json - I'm not sure how this will be addressed by WF subsystem. > > We still need a way how to pass keycloak.json to UPS cartridge, which is AS7 > > and we can't ask user to modify standalone.xml anyway. However, we could > > make a hook on OpenShift - user will add keycloak.json to git repo and it > > will automagically put at right location. Could we have a hook in Keycloak > > to load keycloak.json from external location? Or should we rather do some > > war exploding magic? > > I need to go through Stan's work. I want to be able to configure the > subsystem from the keycloak admin console without having to create a > keycloak.json file. I just don't know yet if the subsystem will work on > AS7. This will work for app and Keycloak being deployed on a single server. It does not solve SaaS scenario - keycloak admin console can configure subsystem of current AS/WF only. Keycloak would need to manage subsystem of remote WF - I doubt this would ever be possible with AS7 on OpenShift and I think security concerns of such setup are not > > > > * AS7-3227 I worked this around by doing parameter injection for > > SecurityContext in UPS. Nasty. Can we make newer RESTEasy part of > > Keycloak package for AS7? Any better option? > > This is an UPS issue right? Keycloak WAR bundles is own Resteasy and > excludes built in one. Well, it is either keycloak packaging issue or documentation issue (or problem here in Brno in between chair and keyboard). I've added keycloak-as7-adapter-dist to AS7. Keycloak WAR was added to different cartridge. So, AS7 (UPS) is still using old RESTEasy 2.x. This will be fixed if newer RESTEasy is packaged inside of keycloak-as7-adapter-dist instead of Keycloak WAR. IIRC this was setup pre alpha-1. > > > * Ember in UPS is firing AJAX request to REST Endpoints on the same domain. > > However, as it goes through Keycloak Auth Server, this is considered CORS > > request. I had to configure Web Origin for UPS application. This is > > confusing to me, Origin header should be transparent for Keycloak as I'm > > firing request to the same domain. Note this does not happen in Firefox, > > which identifies same domain and avoids Origin header. I need some > > insight here from more skilled people. > > JIRA for this one. I've only tested/experimented with CORS on Firefox. https://issues.jboss.org/browse/KEYCLOAK-233 > > > * I wasn't able to keep http->https rewriting valve with Keycloak to avoid > > UPS usage via http protocol. I'll go deeper into that. > > * Changes to Web Origin in Keycloak admin UI are not reflected to already > > logged users. They need to log out first. > > We can't fix this. But it will be mitigated when we add refresh tokens. > We'll have a short token lifespan that needs to be refreshed. The > refresh will pick up the changes. > Sounds good. > > More detailed steps: > > > > 1/ Create Keycloak cart > > 2/ Add AeroGear-UnifiedPush realm with roles admin, user > > 3/ Add ag-push app with scopes admin, user, allow Web Origin for UPS cart > > location > > > Couldn't the cartridge come with a pre-configured keycloak database? We > also have a realm import option, but we haven't documented the json > format yet. Also there's the admin REST interface you could use to > create the realm/application/roles etc. If I'm able to get public key via admin REST interface, it should be possible to preconfigure that. Setup will be complicated but possible with Keycloak subsystem. Having realm import json format documentation will definitely help here. > > > > 4/ Get keycloak.json > > 5/ Enable CORS in keycloak.json, modify password > > 6/ Add keycloak.json to aerogear-unifiedpush-server/src/main/webapp/WEB-INF > > 7/ Package UPS via 'mvn clean package' > > 8/ Put war into > > openshift-origin-cartridge-aerogear-push/versions/0.9.0/standalone/deployments > > This may be able to be done from the keycloak console. Right, but not in SaaS scenario, only if app and Keycloak run on same instance. > > > 9/ Push that online > > 10/ Create UPS cart using reflector cartridge (use commit sha1 if not using > > master), enable mysql-5.1 gear as well > > 11/ Create an user with roles admin/user in AeroGear-UnifiedPush realm > > 12/ Enjoy UPS secured by Keycloak. Have a big cup of coffee. > > > > :) > From corinnekrych at gmail.com Wed Feb 5 09:41:05 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Wed, 5 Feb 2014 15:41:05 +0100 Subject: [aerogear-dev] [sync] Diff libraries In-Reply-To: References: Message-ID: <463B8AA0-68AB-4C37-8401-EA35D6E6528E@gmail.com> Rather than a text diff i?d like something that compares data structure (JSON like) diff. I can use google diff by serialiazing to string but it?s a plain text diff rather than object diff. Guess you can patch the stringyfied object an then convert it back to json structure but less elegant and flexible than jsondiffpatch on object. ++ Corinne On 05 Feb 2014, at 11:23, Christos Vasilakis wrote: > Hi Corinne, > > i did came across the following diff-match lib[1] might be interested to digg more, as I have seen they all derive from google-diff > > [1] https://github.com/inquisitiveSoft/DiffMatchPatch-ObjC [+podspec] > > > > On Wed, Feb 5, 2014 at 10:49 AM, Corinne Krych wrote: > Hello Ladies and Gentlemen, > > I was looking for some diff/patch libraries to get differences between 2 objects (either json format of map/array format) ideally in iOS (withpodspec) or in C/C++. To plug into custom conflict management in you sync demo app. Like Luke did using jsondiffpatch in JS [1]. > > For comparing text there is google-diff-match-patch [2] lib that is implemented in several langagues and format (including iOS). > > But i couldn?t find a jsondiff liek lib for iOS? I?m asking my favourite oracle (i.e.: the mailing list), see if i get more lucky. > > ++ > Corinne > [1] https://github.com/benjamine/JsonDiffPatch > [2] https://github.com/JanX2/google-diff-match-patch > _______________________________________________ > 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 From bruno at abstractj.org Wed Feb 5 09:52:49 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Wed, 5 Feb 2014 12:52:49 -0200 Subject: [aerogear-dev] Question around encryption for iOS push certificate passphrase In-Reply-To: References: Message-ID: You don?t need a key pair, so I can?t see any good reason to use the KeyStore. If Apple graciously requires the passphrase in plain text we need to do something about it. PBKDF2 is not only a function to store passwords, but is also possible to generate secret keys. So into your scenarios the solution is: ? ? ? ? Pbkdf2 pbkdf2 = AeroGearCrypto.pbkdf2(); ? ? ? ? byte[] salt = new Random().randomBytes(); ? ? ? ? int iterations = 100000; ? ? ? ? SecretKey secretKey = pbkdf2.generateSecretKey(PASSWORD, salt, iterations); ? ? ? ? CryptoBox cryptoBox = new CryptoBox(secretKey.getEncoded()); ? ? ? ? String passphrase = "My bonnie lies over the ocean"; ? ? ? ? byte[] ciphertext = cryptoBox.encrypt(CRYPTOBOX_IV, passphrase, RAW); Salt, IV and the number of iterations must be stored in some place, or you can just stick with the default number of iterations. But you still need to store salt and IV. -- abstractj On February 5, 2014 at 9:20:37 AM, Matthias Wessendorf (matzew at apache.org) wrote: > > However, I am afraid it does not work for the iOS passphrase, > required to connect to Apple - looks like the library we use requires > it in plain text... (due to Apple? Not sure...) From supittma at redhat.com Wed Feb 5 10:04:33 2014 From: supittma at redhat.com (Summers Pittman) Date: Wed, 05 Feb 2014 10:04:33 -0500 Subject: [aerogear-dev] [sync] Diff libraries In-Reply-To: <463B8AA0-68AB-4C37-8401-EA35D6E6528E@gmail.com> References: <463B8AA0-68AB-4C37-8401-EA35D6E6528E@gmail.com> Message-ID: <52F25301.6060904@redhat.com> On Wed 05 Feb 2014 09:41:05 AM EST, Corinne Krych wrote: > Rather than a text diff i?d like something that compares data structure (JSON like) diff. > I can use google diff by serialiazing to string but it?s a plain text diff rather than object diff. Guess you can patch the stringyfied object an then convert it back to json structure but less elegant and flexible than jsondiffpatch on object. If you go this route you need to make sure that things like order of variables, order of items in an array/collection, etc always come out the same way. Also you need to make sure your stringified / merged JSON is still valid JSON. You may be off using hashing of your objects and doing set comparisons. Unfortunately I do not know of a library which makes that "free". I used that on the DevNexus demo. > > ++ > Corinne > On 05 Feb 2014, at 11:23, Christos Vasilakis wrote: > >> Hi Corinne, >> >> i did came across the following diff-match lib[1] might be interested to digg more, as I have seen they all derive from google-diff >> >> [1] https://github.com/inquisitiveSoft/DiffMatchPatch-ObjC [+podspec] >> >> >> >> On Wed, Feb 5, 2014 at 10:49 AM, Corinne Krych wrote: >> Hello Ladies and Gentlemen, >> >> I was looking for some diff/patch libraries to get differences between 2 objects (either json format of map/array format) ideally in iOS (withpodspec) or in C/C++. To plug into custom conflict management in you sync demo app. Like Luke did using jsondiffpatch in JS [1]. >> >> For comparing text there is google-diff-match-patch [2] lib that is implemented in several langagues and format (including iOS). >> >> But i couldn?t find a jsondiff liek lib for iOS? I?m asking my favourite oracle (i.e.: the mailing list), see if i get more lucky. >> >> ++ >> Corinne >> [1] https://github.com/benjamine/JsonDiffPatch >> [2] https://github.com/JanX2/google-diff-match-patch >> _______________________________________________ >> 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 > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From corinnekrych at gmail.com Wed Feb 5 10:37:29 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Wed, 5 Feb 2014 16:37:29 +0100 Subject: [aerogear-dev] [sync] Diff libraries In-Reply-To: <52F25301.6060904@redhat.com> References: <463B8AA0-68AB-4C37-8401-EA35D6E6528E@gmail.com> <52F25301.6060904@redhat.com> Message-ID: <4C4D87F8-F786-40E3-A3D3-ACA2FFB812B7@gmail.com> On 05 Feb 2014, at 16:04, Summers Pittman wrote: > > > On Wed 05 Feb 2014 09:41:05 AM EST, Corinne Krych wrote: >> Rather than a text diff i?d like something that compares data structure (JSON like) diff. >> I can use google diff by serialiazing to string but it?s a plain text diff rather than object diff. Guess you can patch the stringyfied object an then convert it back to json structure but less elegant and flexible than jsondiffpatch on object. > > If you go this route you need to make sure that things like order of variables, order of items in an array/collection, etc always come out the same way. > > Also you need to make sure your stringified / merged JSON is still valid JSON. > Exactly. I dont feel that?s the right route > You may be off using hashing of your objects and doing set comparisons. Unfortunately I do not know of a library which makes that "free". I used that on the DevNexus demo. Jsondiffpatch js does handle it nicely. Might be some similar libs in Java? > >> >> ++ >> Corinne >> On 05 Feb 2014, at 11:23, Christos Vasilakis wrote: >> >>> Hi Corinne, >>> >>> i did came across the following diff-match lib[1] might be interested to digg more, as I have seen they all derive from google-diff >>> >>> [1] https://github.com/inquisitiveSoft/DiffMatchPatch-ObjC [+podspec] >>> >>> >>> >>> On Wed, Feb 5, 2014 at 10:49 AM, Corinne Krych wrote: >>> Hello Ladies and Gentlemen, >>> >>> I was looking for some diff/patch libraries to get differences between 2 objects (either json format of map/array format) ideally in iOS (withpodspec) or in C/C++. To plug into custom conflict management in you sync demo app. Like Luke did using jsondiffpatch in JS [1]. >>> >>> For comparing text there is google-diff-match-patch [2] lib that is implemented in several langagues and format (including iOS). >>> >>> But i couldn?t find a jsondiff liek lib for iOS? I?m asking my favourite oracle (i.e.: the mailing list), see if i get more lucky. >>> >>> ++ >>> Corinne >>> [1] https://github.com/benjamine/JsonDiffPatch >>> [2] https://github.com/JanX2/google-diff-match-patch >>> _______________________________________________ >>> 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 >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev From matzew at apache.org Wed Feb 5 11:00:44 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 5 Feb 2014 17:00:44 +0100 Subject: [aerogear-dev] Question around encryption for iOS push certificate passphrase In-Reply-To: References: Message-ID: Hello Bruno! On Wed, Feb 5, 2014 at 3:52 PM, Bruno Oliveira wrote: > You don't need a key pair, so I can't see any good reason to use the > KeyStore. If Apple graciously requires the passphrase in plain text we need > to do something about it. > > PBKDF2 is not only a function to store passwords, but is also possible to > generate secret keys. So into your scenarios the solution is: > > Pbkdf2 pbkdf2 = AeroGearCrypto.pbkdf2(); > byte[] salt = new Random().randomBytes(); > int iterations = 100000; > SecretKey secretKey = pbkdf2.generateSecretKey(PASSWORD, salt, > iterations); > > CryptoBox cryptoBox = new CryptoBox(secretKey.getEncoded()); > String passphrase = "My bonnie lies over the ocean"; > byte[] ciphertext = cryptoBox.encrypt(CRYPTOBOX_IV, passphrase, > RAW); > > > Salt, IV and the number of iterations must be stored in some place, or you > can just stick with the default number of iterations. But you still need to > store salt and IV. > Ah, thanks for the hints. I have a little isolated test case. In there I (potentially) store the privateKey, the IV and the ciphertext in the database. This basically simulates the case when the "new iOS variant" form has been submitted - so instead of the plain passphrase for the cert, I store the three guys (privateKey, IV, ciphertext): https://github.com/matzew/psswd-salting/blob/master/src/test/java/net/wessendorf/salt/SecretKeyTest.java#L43-L62 Later on, I use the pandora :) to decrypt, by leveraging the stored information in the database (privateKey, IV, ciphertext): https://github.com/matzew/psswd-salting/blob/master/src/test/java/net/wessendorf/salt/SecretKeyTest.java#L67-L71 Than I get back the 'plaintext' version of the certificate's passphrase, e.g. as byte[] or String: https://github.com/matzew/psswd-salting/blob/master/src/test/java/net/wessendorf/salt/SecretKeyTest.java#L74-L78 Greetings, Matthias > > -- > abstractj > > On February 5, 2014 at 9:20:37 AM, Matthias Wessendorf (matzew at apache.org) > wrote: > > > However, I am afraid it does not work for the iOS passphrase, > > required to connect to Apple - looks like the library we use requires > > it in plain text... (due to Apple? Not sure...) > > -- 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/20140205/4c506ab2/attachment.html From bruno at abstractj.org Wed Feb 5 11:05:39 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Wed, 5 Feb 2014 14:05:39 -0200 Subject: [aerogear-dev] Question around encryption for iOS push certificate passphrase In-Reply-To: References: Message-ID: You shouldn?t store your private key, please make use of the suggested code and let me know. -- abstractj On February 5, 2014 at 2:00:45 PM, Matthias Wessendorf (matzew at apache.org) wrote: > > Ah, thanks for the hints. I have a little isolated test case. > In there I (potentially) store the privateKey, the IV and the > ciphertext in the database. From matzew at apache.org Wed Feb 5 11:49:57 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 5 Feb 2014 17:49:57 +0100 Subject: [aerogear-dev] Question around encryption for iOS push certificate passphrase In-Reply-To: References: Message-ID: Hello Bruno, On Wed, Feb 5, 2014 at 5:05 PM, Bruno Oliveira wrote: > You shouldn't store your private key, please make use of the suggested > code and let me know. > OK, not storing the 'private key', but instead I am only storing the IV, salt and ciphertext, right ? The following code is basically the (relevant) code behind the web-form when someone creates the logical construct of an iOS variant: https://github.com/matzew/psswd-salting/blob/master/src/test/java/net/wessendorf/salt/SecretKeyTest.java#L44-L62 In real I get all the information for the variant (e.g. its name, its description, its certificate file and the passphrase for the certificate), but the above has been limited to the passphrase, as everything else is not so important here :-) So after that I have basically the following pieces in the database: * IV * salt * ciphertex instead of the plaintext passphrase for the iOS certs. But, now, somewhere later in in the program, I need to do the decryption to get the actual passphrase for the stored Apple-certificate. However, I don't see how to create the CryptoBox here, as I should not stash the private/secret key, nor do I have access to the previous CryptoBox object https://github.com/matzew/psswd-salting/blob/master/src/test/java/net/wessendorf/salt/SecretKeyTest.java#L64-L85 Looks like I am missing something here -Matthias > > -- > abstractj > > On February 5, 2014 at 2:00:45 PM, Matthias Wessendorf (matzew at apache.org) > wrote: > > > Ah, thanks for the hints. I have a little isolated test case. > > In there I (potentially) store the privateKey, the IV and the > > ciphertext in the database. > > -- 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/20140205/b930093f/attachment-0001.html From daniel at passos.me Wed Feb 5 12:53:48 2014 From: daniel at passos.me (Daniel Passos) Date: Wed, 5 Feb 2014 15:53:48 -0200 Subject: [aerogear-dev] Question around encryption for iOS push certificate passphrase In-Reply-To: References: Message-ID: On Wed, Feb 5, 2014 at 2:49 PM, Matthias Wessendorf wrote: > Hello Bruno, > > > On Wed, Feb 5, 2014 at 5:05 PM, Bruno Oliveira wrote: > >> You shouldn't store your private key, please make use of the suggested >> code and let me know. >> > > > OK, not storing the 'private key', but instead I am only storing the IV, > salt and ciphertext, right ? > Right. In this case you don't need store Private Key > The following code is basically the (relevant) code behind the web-form > when someone creates the logical construct of an iOS variant: > > > https://github.com/matzew/psswd-salting/blob/master/src/test/java/net/wessendorf/salt/SecretKeyTest.java#L44-L62 > > In real I get all the information for the variant (e.g. its name, its > description, its certificate file and the passphrase for the certificate), > but the above has been limited to the passphrase, as everything else is not > so important here :-) > > So after that I have basically the following pieces in the database: > * IV > * salt > * ciphertex > > instead of the plaintext passphrase for the iOS certs. > *NEVER* store password/passphrase > But, now, somewhere later in in the program, I need to do the decryption > to get the actual passphrase for the stored Apple-certificate. > However, I don't see how to create the CryptoBox here, as I should not > stash the private/secret key, nor do I have access to the previous > CryptoBox object > > > https://github.com/matzew/psswd-salting/blob/master/src/test/java/net/wessendorf/salt/SecretKeyTest.java#L64-L85 > > > Looks like I am missing something here > If you have Salt and password you can create a PrivateKey "on the fly" Pbkdf2 pbkdf2 = AeroGearCrypto.pbkdf2(); byte[] rawPassword = pbkdf2.encrypt(passphrase, salt); PrivateKey privateKey = new PrivateKey(rawPassword); And for create CriptoBox you only need a PrivateKey CryptoBox cryptoBox = new CryptoBox(privateKey); Now you a able to decrypt using stored IV :) byte[] decryptedData = cryptoBox.decrypt(IV, data); That was exactly what we did in Ecrypted Store https://github.com/danielpassos/aerogear-android/blob/master/src/org/jboss/aerogear/android/impl/datamanager/EncryptedSQLStore.java#L115-L150 -Matthias > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140205/6d99234e/attachment.html From matzew at apache.org Wed Feb 5 12:58:57 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 5 Feb 2014 18:58:57 +0100 Subject: [aerogear-dev] Question around encryption for iOS push certificate passphrase In-Reply-To: References: Message-ID: On Wed, Feb 5, 2014 at 6:53 PM, Daniel Passos wrote: > On Wed, Feb 5, 2014 at 2:49 PM, Matthias Wessendorf wrote: > >> Hello Bruno, >> >> >> On Wed, Feb 5, 2014 at 5:05 PM, Bruno Oliveira wrote: >> >>> You shouldn't store your private key, please make use of the suggested >>> code and let me know. >>> >> >> >> OK, not storing the 'private key', but instead I am only storing the IV, >> salt and ciphertext, right ? >> > > Right. In this case you don't need store Private Key > > >> The following code is basically the (relevant) code behind the web-form >> when someone creates the logical construct of an iOS variant: >> >> >> https://github.com/matzew/psswd-salting/blob/master/src/test/java/net/wessendorf/salt/SecretKeyTest.java#L44-L62 >> >> In real I get all the information for the variant (e.g. its name, its >> description, its certificate file and the passphrase for the certificate), >> but the above has been limited to the passphrase, as everything else is not >> so important here :-) >> >> So after that I have basically the following pieces in the database: >> * IV >> * salt >> * ciphertex >> >> instead of the plaintext passphrase for the iOS certs. >> > > *NEVER* store password/passphrase > yep, that's why I am thinking about: https://issues.jboss.org/browse/AGPUSH-358 > > >> But, now, somewhere later in in the program, I need to do the >> decryption to get the actual passphrase for the stored Apple-certificate. >> However, I don't see how to create the CryptoBox here, as I should not >> stash the private/secret key, nor do I have access to the previous >> CryptoBox object >> >> >> https://github.com/matzew/psswd-salting/blob/master/src/test/java/net/wessendorf/salt/SecretKeyTest.java#L64-L85 >> >> >> Looks like I am missing something here >> > > If you have Salt and password you can create a PrivateKey "on the fly" > As said in the comments of I don't have access to the password/passphrase: https://github.com/matzew/psswd-salting/blob/master/src/test/java/net/wessendorf/salt/SecretKeyTest.java#L67 > > > Pbkdf2 pbkdf2 = AeroGearCrypto.pbkdf2(); > > byte[] rawPassword = pbkdf2.encrypt(passphrase, salt); > > PrivateKey privateKey = new PrivateKey(rawPassword); > > > And for create CriptoBox you only need a PrivateKey > > CryptoBox cryptoBox = new CryptoBox(privateKey); > > Now you a able to decrypt using stored IV :) > > byte[] decryptedData = cryptoBox.decrypt(IV, data); > > That was exactly what we did in Ecrypted Store > > > https://github.com/danielpassos/aerogear-android/blob/master/src/org/jboss/aerogear/android/impl/datamanager/EncryptedSQLStore.java#L115-L150 > > > -Matthias >> > > _______________________________________________ > 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/20140205/8d34c714/attachment-0001.html From bruno at abstractj.org Wed Feb 5 13:41:44 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Wed, 5 Feb 2014 16:41:44 -0200 Subject: [aerogear-dev] Question around encryption for iOS push certificate passphrase In-Reply-To: References: Message-ID: You need tho reconstruct that key again with the pieces from your database, so your code would look like: @Test ? ? public void testPasswordValidationWithRandomSaltProvided() throws Exception { ? ? ? ? Pbkdf2 pbkdf2 = AeroGearCrypto.pbkdf2(); ? ? ? ? byte[] salt = new Random().randomBytes(); ? ? ? ? byte[] IV = new Random().randomBytes(); ? ? ? ? int iterations = 100000; ? ? ? ? //Encrypt step ? ? ? ? SecretKey secretKey = pbkdf2.generateSecretKey(PASSWORD, salt, iterations); ? ? ? ? CryptoBox box1 = new CryptoBox(secretKey.getEncoded()); ? ? ? ? String passphrase = "My bonnie lies over the ocean"; ? ? ? ? byte[] ciphertext = box1.encrypt(IV, passphrase.getBytes()); ? ? ? ? //Decrypt step ? ? ? ? SecretKey recoveredKey = pbkdf2.generateSecretKey(PASSWORD, salt, iterations); ? ? ? ? CryptoBox box2 = new CryptoBox(recoveredKey.getEncoded()); ? ? ? ? byte[] plaintext = box2.decrypt(IV, ciphertext); ? ? ? ? System.out.println(RAW.encode(plaintext)); ? ? } -- abstractj On February 5, 2014 at 3:59:06 PM, Matthias Wessendorf (matzew at apache.org) wrote: > > But, now, somewhere later in in the program, I need to do the decryption > to get the actual passphrase for the stored Apple-certificate. > However, I don't see how to create the CryptoBox here, as I should > not stash the private/secret key, nor do I have access to the previous > CryptoBox object > > https://github.com/matzew/psswd-salting/blob/master/src/test/java/net/wessendorf/salt/SecretKeyTest.java#L64-L85 > > > Looks like I am missing something here From matzew at apache.org Wed Feb 5 13:47:03 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 5 Feb 2014 19:47:03 +0100 Subject: [aerogear-dev] Question around encryption for iOS push certificate passphrase In-Reply-To: References: Message-ID: On Wed, Feb 5, 2014 at 7:41 PM, Bruno Oliveira wrote: > You need tho reconstruct that key again with the pieces from your > database, so your code would look like: > > @Test > public void testPasswordValidationWithRandomSaltProvided() throws > Exception { > Pbkdf2 pbkdf2 = AeroGearCrypto.pbkdf2(); > byte[] salt = new Random().randomBytes(); > byte[] IV = new Random().randomBytes(); > int iterations = 100000; > > //Encrypt step > SecretKey secretKey = pbkdf2.generateSecretKey(PASSWORD, salt, > iterations); > CryptoBox box1 = new CryptoBox(secretKey.getEncoded()); > String passphrase = "My bonnie lies over the ocean"; > byte[] ciphertext = box1.encrypt(IV, passphrase.getBytes()); > > //Decrypt step > SecretKey recoveredKey = pbkdf2.generateSecretKey(PASSWORD, salt, > iterations); > as said in the comments, I don't have that PASSWORD here That is only submitted when the user creates a new iOS variant, it's never entered when the server tries to connect to the APNs > CryptoBox box2 = new CryptoBox(recoveredKey.getEncoded()); > byte[] plaintext = box2.decrypt(IV, ciphertext); > System.out.println(RAW.encode(plaintext)); > > } > > -- > abstractj > > On February 5, 2014 at 3:59:06 PM, Matthias Wessendorf (matzew at apache.org) > wrote: > > > But, now, somewhere later in in the program, I need to do the > decryption > > to get the actual passphrase for the stored Apple-certificate. > > However, I don't see how to create the CryptoBox here, as I should > > not stash the private/secret key, nor do I have access to the previous > > CryptoBox object > > > > > https://github.com/matzew/psswd-salting/blob/master/src/test/java/net/wessendorf/salt/SecretKeyTest.java#L64-L85 > > > > > > Looks like I am missing something here > > -- 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/20140205/c90db087/attachment.html From bruno at abstractj.org Wed Feb 5 14:00:43 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Wed, 5 Feb 2014 17:00:43 -0200 Subject: [aerogear-dev] Question around encryption for iOS push certificate passphrase In-Reply-To: References: Message-ID: There is no magic, the password must exist in some place. If not possible require the password, is possible to follow the same approach provided for password reset functionality. If you want to stick to the KeyStore, you still need to provide the password in some place, but that?s more suitable when you have a key exchange or something like this. So if you patiently read my the code proposed, you will realize that is possible to achieve it via property file, database or whatever: @Test ? ? public void testPasswordValidationWithRandomSaltProvided() throws Exception { ? ? ? ? Pbkdf2 pbkdf2 = AeroGearCrypto.pbkdf2(); ? ? ? ? byte[] salt = new Random().randomBytes(); ? ? ? ? byte[] IV = new Random().randomBytes(); ? ? ? ? int iterations = 100000; read.secretFile(?secret.properties?); String PASSWORD = read.load(?password_to_my_superpassphrase?); ? ? ? ? //Encrypt step ? ? ? ? SecretKey secretKey = pbkdf2.generateSecretKey(PASSWORD, salt, iterations); ? ? ? ? CryptoBox box1 = new CryptoBox(secretKey.getEncoded()); ? ? ? ? String passphrase = "My bonnie lies over the ocean"; ? ? ? ? byte[] ciphertext = box1.encrypt(IV, passphrase.getBytes()); ? ? ? ? //Decrypt step ? ? ? ? SecretKey recoveredKey = pbkdf2.generateSecretKey(PASSWORD, salt, iterations); } If it?s not clear, let me know where should I introduce this functionality rather than a pet project and I can do that. -- abstractj On February 5, 2014 at 4:47:04 PM, Matthias Wessendorf (matzew at apache.org) wrote: > > as said in the comments, I don't have that PASSWORD here > > > That is only submitted when the user creates a new iOS variant, > it's never entered when the server tries to connect to the APNs From matzew at apache.org Wed Feb 5 14:47:23 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 5 Feb 2014 20:47:23 +0100 Subject: [aerogear-dev] Question around encryption for iOS push certificate passphrase In-Reply-To: References: Message-ID: On Wed, Feb 5, 2014 at 8:00 PM, Bruno Oliveira wrote: > There is no magic, the password must exist in some place. If not possible > require the password, is possible to follow the same approach provided for > password reset functionality. > > If you want to stick to the KeyStore, you still need to provide the > password in some place, but that's more suitable when you have a key > exchange or something like this. > > So if you patiently read my the code proposed, you will realize that is > possible to achieve it via property file, database or whatever: > > @Test > public void testPasswordValidationWithRandomSaltProvided() throws > Exception { > Pbkdf2 pbkdf2 = AeroGearCrypto.pbkdf2(); > byte[] salt = new Random().randomBytes(); > byte[] IV = new Random().randomBytes(); > int iterations = 100000; > > read.secretFile("secret.properties"); > String PASSWORD = read.load("password_to_my_superpassphrase"); > yeah, but that is really per variant, not global. So we would need a lot of these secret file :-) So, the passphrase is upload to the server (for all iOS variants), w/ this HTTP request: http://aerogear.org/docs/specs/aerogear-push-rest/Variants/iOS/ Somewhen later a totally different system submits a HTTP request to trigger the PUSH message delivery: http://aerogear.org/docs/specs/aerogear-push-rest/Sender/ And internally, only for iOS variant, all it needs is the certificate (from the apple developer portal) + its passphrase Perhaps I am wrong, but I feel that if (for iOS variants) we start to require "password_to_my_superpassphrase" on the request for creating the logical construct of the variant, and use the same for the Sender, we would have that magical password, but I fear that this opens a new can of worms. > > //Encrypt step > SecretKey secretKey = pbkdf2.generateSecretKey(PASSWORD, salt, > iterations); > CryptoBox box1 = new CryptoBox(secretKey.getEncoded()); > String passphrase = "My bonnie lies over the ocean"; > byte[] ciphertext = box1.encrypt(IV, passphrase.getBytes()); > > //Decrypt step > SecretKey recoveredKey = pbkdf2.generateSecretKey(PASSWORD, salt, > iterations); > } > > If it's not clear, let me know where should I introduce this functionality > rather than a pet project and I can do that. > The AGPUSH-358 ticket is still yours :-) I just felt looking at it, while reading up on our crypto bits. > > -- > abstractj > > On February 5, 2014 at 4:47:04 PM, Matthias Wessendorf (matzew at apache.org) > wrote: > > > as said in the comments, I don't have that PASSWORD here > > > > > > That is only submitted when the user creates a new iOS variant, > > it's never entered when the server tries to connect to the APNs > > -- 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/20140205/cce32c16/attachment.html From bruno at abstractj.org Wed Feb 5 15:02:20 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Wed, 5 Feb 2014 18:02:20 -0200 Subject: [aerogear-dev] Question around encryption for iOS push certificate passphrase In-Reply-To: References: Message-ID: On February 5, 2014 at 5:47:24 PM, Matthias Wessendorf (matzew at apache.org) wrote: > > yeah, but that is really per variant, not global. So we would > need a lot of these secret file :-) You?ve probably misunderstood what I said, but that would be silly and impractical, I didn?t say that, right? If you don?t want to require an input every time, make use of SINGLE key to encrypt the passphrases that?s what was suggested. > > > > Perhaps I am wrong, but I feel that if (for iOS variants) we start > to require "password_to_my_superpassphrase" on the request > for creating the logical construct of the variant, > and use the same for the Sender, we would have that magical password,? That?s what I?ve already mentioned, the password MUST be provided. And there are a gazillion of solutions to the same problem outside there. > but I fear that this opens a new can of worms. Why? > > > The AGPUSH-358 ticket is still yours :-) I just felt looking at > it, while reading up on our crypto bits. I don?t bother whoever will solve this ticket. If you want to jump in, feel free to reassign to you, if don?t I can look at this on the next week. From matzew at apache.org Wed Feb 5 15:06:04 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 5 Feb 2014 21:06:04 +0100 Subject: [aerogear-dev] Question around encryption for iOS push certificate passphrase In-Reply-To: References: Message-ID: On Wed, Feb 5, 2014 at 9:02 PM, Bruno Oliveira wrote: > On February 5, 2014 at 5:47:24 PM, Matthias Wessendorf (matzew at apache.org) > wrote: > > > yeah, but that is really per variant, not global. So we would > > need a lot of these secret file :-) > > You've probably misunderstood what I said, but that would be silly and > impractical, I didn't say that, right? If you don't want to require an > input every time, make use of SINGLE key to encrypt the passphrases that's > what was suggested. > > > > > > > > > Perhaps I am wrong, but I feel that if (for iOS variants) we start > > to require "password_to_my_superpassphrase" on the request > > for creating the logical construct of the variant, > > and use the same for the Sender, we would have that magical password, > > That's what I've already mentioned, the password MUST be provided. And > there are a gazillion of solutions to the same problem outside there. > > > but I fear that this opens a new can of worms. > > Why? > isn't is a problem if some backend app has to store this password as well? In order to have their batch system (or what ever) being able to trigger push message delivery ? > > > > > > > The AGPUSH-358 ticket is still yours :-) I just felt looking at > > it, while reading up on our crypto bits. > > I don't bother whoever will solve this ticket. If you want to jump in, > feel free to reassign to you, if don't I can look at this on the next week. > -- 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/20140205/d2896850/attachment.html From qmx at qmx.me Wed Feb 5 15:13:14 2014 From: qmx at qmx.me (Douglas Campos) Date: Wed, 5 Feb 2014 18:13:14 -0200 Subject: [aerogear-dev] Question around encryption for iOS push certificate passphrase In-Reply-To: References: Message-ID: <20140205201314.GR75920@rohan.local> On Wed, Feb 05, 2014 at 09:06:04PM +0100, Matthias Wessendorf wrote: > isn't is a problem if some backend app has to store this password as well? > In order to have their batch system (or what ever) being able to trigger > push message delivery ? Well, there's no free lunch, you've got to store this somewhere - or shoot for oauth dance between apps + HSMs + loads of money -- qmx From bruno at abstractj.org Wed Feb 5 15:17:52 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Wed, 5 Feb 2014 18:17:52 -0200 Subject: [aerogear-dev] Question around encryption for iOS push certificate passphrase In-Reply-To: <20140205201314.GR75920@rohan.local> References: <20140205201314.GR75920@rohan.local> Message-ID: +1 -- abstractj On February 5, 2014 at 6:13:31 PM, Douglas Campos (qmx at qmx.me) wrote: > > Well, there's no free lunch, you've got to store this somewhere > - or > shoot for oauth dance between apps + HSMs + loads of money From scm.blanc at gmail.com Wed Feb 5 17:22:35 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Wed, 5 Feb 2014 23:22:35 +0100 Subject: [aerogear-dev] Differences between Firefox OS "native" Push lib and AeroGear's Push adapter Message-ID: Hi, While playing today with my Firefox Device and its native Simple Push support I noticed some differences between our implementation and the native Push regarding the success callback after a register : //Native FFOS Push broadcastRequest = navigator.push.register(); broadcastRequest.onsuccess = function (event) { broadcastEndpoint = broadcastRequest.result; // only contains the pushURL } //Aerogear Push Adapter broadcastRequest = navigator.push.register(); broadcastRequest.onsuccess = function (event) { broadcastEndpoint = broadcastRequest.result.pushEndpoint; channelID = broadcastRequest.result.channelID; version = broadcastRequest.result.version; status = broadcastRequest.result.status } So, the AeroGear Push exposes much more in the callback that it should suppose to do : just exposing the pushEndpoint. The reason we do that I suppose, but Luke or Kris could confirm that, is that we thought respecting the SPS protocol, which indeed returns a whole object containing all the info. It is just that the Native Push Client API filter that out in the callback response. After discussing that on the #push channel with the Mozilla people they confirmed me that we should only expoe the pushEndpoint. If we keep it as is, this can be problematic when we want to use the same code both for native and with the adapter when, for instance, registering to the UPS : broadcastRequest = navigator.push.register(); broadcastRequest.onsuccess = function (event) { broadcastEndpoint = event.target.result; var broadCastSettings = { metadata: { deviceToken: broadcastEndpoint.channelID, simplePushEndpoint: broadcastEndpoint.pushEndpoint } } UPClient.registerWithPushServer(broadCastSettings); } This won't work with the native push since "broadcastEndpoint.channelID" will be undefined. So I propose that we change the behaviour, to return only the pushEndpoint in the callback, even if that means a bit of String manipulation when we want to perform the registration to the UPS : var broadCastSettings = { metadata: { deviceToken: broadcastEndpoint.substr(broadcastEndpoint.lastIndexOf('/') + 1), simplePushEndpoint: broadcastEndpoint } } wdyt ? Seb ps : our SPS Server implementation stays correct and returns what should be returned, it's really just the client part and how we expose the result -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140205/f3900964/attachment.html From matzew at apache.org Wed Feb 5 17:52:31 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 5 Feb 2014 23:52:31 +0100 Subject: [aerogear-dev] Differences between Firefox OS "native" Push lib and AeroGear's Push adapter In-Reply-To: References: Message-ID: On Wed, Feb 5, 2014 at 11:22 PM, Sebastien Blanc wrote: > Hi, > While playing today with my Firefox Device and its native Simple Push > support I noticed some differences between our implementation and the > native Push regarding the success callback after a register : > > > > > //Native FFOS Push > broadcastRequest = navigator.push.register(); > broadcastRequest.onsuccess = function (event) { > broadcastEndpoint = broadcastRequest.result; // only contains the pushURL > } > > > //Aerogear Push Adapter > broadcastRequest = navigator.push.register(); > broadcastRequest.onsuccess = function (event) { > broadcastEndpoint = broadcastRequest.result.pushEndpoint; > channelID = broadcastRequest.result.channelID; > version = broadcastRequest.result.version; > status = broadcastRequest.result.status > } > > So, the AeroGear Push exposes much more in the callback that it should > suppose to do : just exposing the pushEndpoint. > > The reason we do that I suppose, but Luke or Kris could confirm that, is > that we thought respecting the SPS protocol, which indeed returns a whole > object containing all the info. It is just that the Native Push Client API > filter that out in the callback response. > Did they change that recently? Or was theirs always like it is now ? > After discussing that on the #push channel with the Mozilla people they > confirmed me that we should only expoe the pushEndpoint. > yep, I agree on changing our JS polyfil > > If we keep it as is, this can be problematic when we want to use the same > code both for native and with the adapter when, for instance, registering > to the UPS : > > broadcastRequest = navigator.push.register(); > broadcastRequest.onsuccess = function (event) { > broadcastEndpoint = event.target.result; > var broadCastSettings = { > metadata: { > deviceToken: broadcastEndpoint.channelID, > simplePushEndpoint: broadcastEndpoint.pushEndpoint > } > } > UPClient.registerWithPushServer(broadCastSettings); > } > > > > This won't work with the native push since "broadcastEndpoint.channelID" > will be undefined. > sweet :-) > > So I propose that we change the behaviour, to return only the pushEndpoint > in the callback, even if that means a bit of String manipulation when we > want to perform the registration to the UPS : > > var broadCastSettings = { > metadata: { > deviceToken: broadcastEndpoint.substr(broadcastEndpoint.lastIndexOf('/') + 1), > simplePushEndpoint: broadcastEndpoint > } > } > > > well, that's not really good for security reasons, since their looooong 'substring' was done for that. Also that's just redundant. The I guess, the deviceToken (channelID registration) might be a bit bogus, for SimplePush. Let me think about it.... That said, we still have no clue how to proper clean-up 'out dated' channels, since the SimplePush Server/Protocol is silent on that (unlike APNs / GCM). but that's really a different thread (yep, we have a future JIRA for that) -M > wdyt ? > > Seb > > > ps : our SPS Server implementation stays correct and returns what should > be returned, it's really just the client part and how we expose the result > > > _______________________________________________ > 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/20140205/7b99f170/attachment-0001.html From scm.blanc at gmail.com Thu Feb 6 02:54:15 2014 From: scm.blanc at gmail.com (=?utf-8?Q?S=C3=A9bastien_Blanc?=) Date: Thu, 6 Feb 2014 08:54:15 +0100 Subject: [aerogear-dev] Differences between Firefox OS "native" Push lib and AeroGear's Push adapter In-Reply-To: References: Message-ID: <58891AD3-0741-4CB7-99F1-00547F0B2B57@gmail.com> Envoy? de mon iPhone Le Feb 5, 2014 ? 23:52, Matthias Wessendorf a ?crit : > > > > On Wed, Feb 5, 2014 at 11:22 PM, Sebastien Blanc wrote: > Hi, > While playing today with my Firefox Device and its native Simple Push support I noticed some differences between our implementation and the native Push regarding the success callback after a register : > > > > > > //Native FFOS Push > broadcastRequest = navigator.push.register(); > broadcastRequest.onsuccess = function (event) { > broadcastEndpoint = broadcastRequest.result; // only contains the pushURL > } > > > //Aerogear Push Adapter > broadcastRequest = navigator.push.register(); > broadcastRequest.onsuccess = function (event) { > broadcastEndpoint = broadcastRequest.result.pushEndpoint; > channelID = broadcastRequest.result.channelID; > version = broadcastRequest.result.version; > status = broadcastRequest.result.status > } > So, the AeroGear Push exposes much more in the callback that it should suppose to do : just exposing the pushEndpoint. > > The reason we do that I suppose, but Luke or Kris could confirm that, is that we thought respecting the SPS protocol, which indeed returns a whole object containing all the info. It is just that the Native Push Client API filter that out in the callback response. > > > Did they change that recently? Or was theirs always like it is now ? Hard to check the history but I think it has always been like that. > > > After discussing that on the #push channel with the Mozilla people they confirmed me that we should only expoe the pushEndpoint. > > > yep, I agree on changing our JS polyfil > > > > If we keep it as is, this can be problematic when we want to use the same code both for native and with the adapter when, for instance, registering to the UPS : > > broadcastRequest = navigator.push.register(); > broadcastRequest.onsuccess = function (event) { > broadcastEndpoint = event.target.result; > var broadCastSettings = { > metadata: { > deviceToken: broadcastEndpoint.channelID, > simplePushEndpoint: broadcastEndpoint.pushEndpoint > } > } > UPClient.registerWithPushServer(broadCastSettings); > } > > > This won't work with the native push since "broadcastEndpoint.channelID" will be undefined. > > sweet :-) > > > So I propose that we change the behaviour, to return only the pushEndpoint in the callback, even if that means a bit of String manipulation when we want to perform the registration to the UPS : > > var broadCastSettings = { > metadata: { > deviceToken: broadcastEndpoint.substr(broadcastEndpoint.lastIndexOf('/') + 1), > simplePushEndpoint: broadcastEndpoint > } > } > > > well, that's not really good for security reasons, since their looooong 'substring' was done for that. Also that's just redundant. > > The I guess, the deviceToken (channelID registration) might be a bit bogus, for SimplePush. Let me think about it.... > > That said, we still have no clue how to proper clean-up 'out dated' channels, since the SimplePush Server/Protocol is silent on that (unlike APNs / GCM). but that's really a different thread (yep, we have a future JIRA for that) > > > -M > > > wdyt ? > > Seb > > > ps : our SPS Server implementation stays correct and returns what should be returned, it's really just the client part and how we expose the result > > > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140206/4c23e74a/attachment.html From scm.blanc at gmail.com Thu Feb 6 03:42:26 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Thu, 6 Feb 2014 09:42:26 +0100 Subject: [aerogear-dev] [SPS-JS] navigator.setMessageHandler Vs navigator.mozSetMessageHandler Message-ID: Hi, Mozilla specifies[1] a function called "mozSetMessageHandler" while we named this function "setMessageHandler" in our polyfill [2] . This is the handler for incoming push notifications. I'm not really a big fan of specific prefixes but again if we want to be really polyfill here, we should align. wdyt ? Seb [1] https://developer.mozilla.org/en-US/docs/Web/API/Navigator.mozSetMessageHandler [2] https://github.com/aerogear/aerogear-js/blob/master/src/simplepush/aerogear.simplepush.js#L152 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140206/0bc9c800/attachment.html From matzew at apache.org Thu Feb 6 03:45:57 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 6 Feb 2014 09:45:57 +0100 Subject: [aerogear-dev] [SPS-JS] navigator.setMessageHandler Vs navigator.mozSetMessageHandler In-Reply-To: References: Message-ID: On Thu, Feb 6, 2014 at 9:42 AM, Sebastien Blanc wrote: > Hi, > Mozilla specifies[1] a function called "mozSetMessageHandler" while we > named this function "setMessageHandler" in our polyfill [2] . This is the > handler for incoming push notifications. > > I'm not really a big fan of specific prefixes but again if we want to be > really polyfill here, we should align. > hrm, not sure - I think, eventually theirs will be ``setMessageHandler`` as well; Why not just setting a reference from ``mozSetMessageHandler `` to ``setMessageHandler`` ? That way both would work, right ? > wdyt ? > > Seb > > > > [1] > https://developer.mozilla.org/en-US/docs/Web/API/Navigator.mozSetMessageHandler > [2] > https://github.com/aerogear/aerogear-js/blob/master/src/simplepush/aerogear.simplepush.js#L152 > > _______________________________________________ > 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/20140206/9142af90/attachment-0001.html From scm.blanc at gmail.com Thu Feb 6 03:52:09 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Thu, 6 Feb 2014 09:52:09 +0100 Subject: [aerogear-dev] [SPS-JS] navigator.setMessageHandler Vs navigator.mozSetMessageHandler In-Reply-To: References: Message-ID: On Thu, Feb 6, 2014 at 9:45 AM, Matthias Wessendorf wrote: > > > > On Thu, Feb 6, 2014 at 9:42 AM, Sebastien Blanc wrote: > >> Hi, >> Mozilla specifies[1] a function called "mozSetMessageHandler" while we >> named this function "setMessageHandler" in our polyfill [2] . This is the >> handler for incoming push notifications. >> >> I'm not really a big fan of specific prefixes but again if we want to be >> really polyfill here, we should align. >> > > hrm, not sure - I think, eventually theirs will be ``setMessageHandler`` > as well; > Yes, I should ping them on their list to have more details. > > Why not just setting a reference from ``mozSetMessageHandler `` to > ``setMessageHandler`` ? That way both would work, right ? > You mean defining both functions and calling setMessageHandler from mozSetMessageHandler ? > > >> wdyt ? >> >> Seb >> >> >> >> [1] >> https://developer.mozilla.org/en-US/docs/Web/API/Navigator.mozSetMessageHandler >> [2] >> https://github.com/aerogear/aerogear-js/blob/master/src/simplepush/aerogear.simplepush.js#L152 >> >> _______________________________________________ >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140206/a3e02793/attachment.html From matzew at apache.org Thu Feb 6 03:57:21 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 6 Feb 2014 09:57:21 +0100 Subject: [aerogear-dev] [SPS-JS] navigator.setMessageHandler Vs navigator.mozSetMessageHandler In-Reply-To: References: Message-ID: On Thu, Feb 6, 2014 at 9:52 AM, Sebastien Blanc wrote: > > > > On Thu, Feb 6, 2014 at 9:45 AM, Matthias Wessendorf wrote: > >> >> >> >> On Thu, Feb 6, 2014 at 9:42 AM, Sebastien Blanc wrote: >> >>> Hi, >>> Mozilla specifies[1] a function called "mozSetMessageHandler" while we >>> named this function "setMessageHandler" in our polyfill [2] . This is the >>> handler for incoming push notifications. >>> >>> I'm not really a big fan of specific prefixes but again if we want to be >>> really polyfill here, we should align. >>> >> >> hrm, not sure - I think, eventually theirs will be ``setMessageHandler`` >> as well; >> > > Yes, I should ping them on their list to have more details. > >> >> Why not just setting a reference from ``mozSetMessageHandler `` to >> ``setMessageHandler`` ? That way both would work, right ? >> > You mean defining both functions and calling setMessageHandler from > mozSetMessageHandler ? > No, just like: navigator.setMessageHandler = function(..) {........}; /// what we have ATM navigator.mozSetMessageHandler = navigator.setMessageHandler; // a reference >> >>> wdyt ? >>> >>> Seb >>> >>> >>> >>> [1] >>> https://developer.mozilla.org/en-US/docs/Web/API/Navigator.mozSetMessageHandler >>> [2] >>> https://github.com/aerogear/aerogear-js/blob/master/src/simplepush/aerogear.simplepush.js#L152 >>> >>> _______________________________________________ >>> 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/20140206/4b68f0ff/attachment.html From scm.blanc at gmail.com Thu Feb 6 04:07:16 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Thu, 6 Feb 2014 10:07:16 +0100 Subject: [aerogear-dev] [SPS-JS] navigator.setMessageHandler Vs navigator.mozSetMessageHandler In-Reply-To: References: Message-ID: On Thu, Feb 6, 2014 at 9:57 AM, Matthias Wessendorf wrote: > > > > On Thu, Feb 6, 2014 at 9:52 AM, Sebastien Blanc wrote: > >> >> >> >> On Thu, Feb 6, 2014 at 9:45 AM, Matthias Wessendorf wrote: >> >>> >>> >>> >>> On Thu, Feb 6, 2014 at 9:42 AM, Sebastien Blanc wrote: >>> >>>> Hi, >>>> Mozilla specifies[1] a function called "mozSetMessageHandler" while we >>>> named this function "setMessageHandler" in our polyfill [2] . This is the >>>> handler for incoming push notifications. >>>> >>>> I'm not really a big fan of specific prefixes but again if we want to >>>> be really polyfill here, we should align. >>>> >>> >>> hrm, not sure - I think, eventually theirs will be ``setMessageHandler`` >>> as well; >>> >> >> Yes, I should ping them on their list to have more details. >> >>> >>> Why not just setting a reference from ``mozSetMessageHandler `` to >>> ``setMessageHandler`` ? That way both would work, right ? >>> >> You mean defining both functions and calling setMessageHandler from >> mozSetMessageHandler ? >> > > > No, just like: > > navigator.setMessageHandler = function(..) {........}; /// what we have ATM > navigator.mozSetMessageHandler = navigator.setMessageHandler; // a > reference > Ok right , got it :) That makes me think that we should have a page on our site describing these kinds of things when develloping for ffos. > > > > >>> >>>> wdyt ? >>>> >>>> Seb >>>> >>>> >>>> >>>> [1] >>>> https://developer.mozilla.org/en-US/docs/Web/API/Navigator.mozSetMessageHandler >>>> [2] >>>> https://github.com/aerogear/aerogear-js/blob/master/src/simplepush/aerogear.simplepush.js#L152 >>>> >>>> _______________________________________________ >>>> 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 > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140206/632ea8e5/attachment-0001.html From matzew at apache.org Thu Feb 6 04:11:56 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 6 Feb 2014 10:11:56 +0100 Subject: [aerogear-dev] [SPS-JS] navigator.setMessageHandler Vs navigator.mozSetMessageHandler In-Reply-To: References: Message-ID: On Thu, Feb 6, 2014 at 10:07 AM, Sebastien Blanc wrote: > > > > On Thu, Feb 6, 2014 at 9:57 AM, Matthias Wessendorf wrote: > >> >> >> >> On Thu, Feb 6, 2014 at 9:52 AM, Sebastien Blanc wrote: >> >>> >>> >>> >>> On Thu, Feb 6, 2014 at 9:45 AM, Matthias Wessendorf wrote: >>> >>>> >>>> >>>> >>>> On Thu, Feb 6, 2014 at 9:42 AM, Sebastien Blanc wrote: >>>> >>>>> Hi, >>>>> Mozilla specifies[1] a function called "mozSetMessageHandler" while we >>>>> named this function "setMessageHandler" in our polyfill [2] . This is the >>>>> handler for incoming push notifications. >>>>> >>>>> I'm not really a big fan of specific prefixes but again if we want to >>>>> be really polyfill here, we should align. >>>>> >>>> >>>> hrm, not sure - I think, eventually theirs will be >>>> ``setMessageHandler`` as well; >>>> >>> >>> Yes, I should ping them on their list to have more details. >>> >>>> >>>> Why not just setting a reference from ``mozSetMessageHandler `` to >>>> ``setMessageHandler`` ? That way both would work, right ? >>>> >>> You mean defining both functions and calling setMessageHandler from >>> mozSetMessageHandler ? >>> >> >> >> No, just like: >> >> navigator.setMessageHandler = function(..) {........}; /// what we have >> ATM >> navigator.mozSetMessageHandler = navigator.setMessageHandler; // a >> reference >> > > Ok right , got it :) > That makes me think that we should have a page on our site describing > these kinds of things when develloping for ffos. > "these kind of things" ? > > >> >> >> >> >>>> >>>>> wdyt ? >>>>> >>>>> Seb >>>>> >>>>> >>>>> >>>>> [1] >>>>> https://developer.mozilla.org/en-US/docs/Web/API/Navigator.mozSetMessageHandler >>>>> [2] >>>>> https://github.com/aerogear/aerogear-js/blob/master/src/simplepush/aerogear.simplepush.js#L152 >>>>> >>>>> _______________________________________________ >>>>> 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 >> >> _______________________________________________ >> 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/20140206/fe3b6f17/attachment.html From scm.blanc at gmail.com Thu Feb 6 04:21:27 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Thu, 6 Feb 2014 10:21:27 +0100 Subject: [aerogear-dev] [SPS-JS] navigator.setMessageHandler Vs navigator.mozSetMessageHandler In-Reply-To: References: Message-ID: On Thu, Feb 6, 2014 at 10:11 AM, Matthias Wessendorf wrote: > > > > On Thu, Feb 6, 2014 at 10:07 AM, Sebastien Blanc wrote: > >> >> >> >> On Thu, Feb 6, 2014 at 9:57 AM, Matthias Wessendorf wrote: >> >>> >>> >>> >>> On Thu, Feb 6, 2014 at 9:52 AM, Sebastien Blanc wrote: >>> >>>> >>>> >>>> >>>> On Thu, Feb 6, 2014 at 9:45 AM, Matthias Wessendorf wrote: >>>> >>>>> >>>>> >>>>> >>>>> On Thu, Feb 6, 2014 at 9:42 AM, Sebastien Blanc wrote: >>>>> >>>>>> Hi, >>>>>> Mozilla specifies[1] a function called "mozSetMessageHandler" while >>>>>> we named this function "setMessageHandler" in our polyfill [2] . This is >>>>>> the handler for incoming push notifications. >>>>>> >>>>>> I'm not really a big fan of specific prefixes but again if we want to >>>>>> be really polyfill here, we should align. >>>>>> >>>>> >>>>> hrm, not sure - I think, eventually theirs will be >>>>> ``setMessageHandler`` as well; >>>>> >>>> >>>> Yes, I should ping them on their list to have more details. >>>> >>>>> >>>>> Why not just setting a reference from ``mozSetMessageHandler `` to >>>>> ``setMessageHandler`` ? That way both would work, right ? >>>>> >>>> You mean defining both functions and calling setMessageHandler from >>>> mozSetMessageHandler ? >>>> >>> >>> >>> No, just like: >>> >>> navigator.setMessageHandler = function(..) {........}; /// what we have >>> ATM >>> navigator.mozSetMessageHandler = navigator.setMessageHandler; // a >>> reference >>> >> >> Ok right , got it :) >> That makes me think that we should have a page on our site describing >> these kinds of things when develloping for ffos. >> > > "these kind of things" ? > Things to take care of when implementing simple push in your app and want to make sure it works on ffo, like adding permissions to the manifest, the ref to mozSetMessageHandler , etc ... Just a simple guide. > > >> >> >>> >>> >>> >>> >>>>> >>>>>> wdyt ? >>>>>> >>>>>> Seb >>>>>> >>>>>> >>>>>> >>>>>> [1] >>>>>> https://developer.mozilla.org/en-US/docs/Web/API/Navigator.mozSetMessageHandler >>>>>> [2] >>>>>> https://github.com/aerogear/aerogear-js/blob/master/src/simplepush/aerogear.simplepush.js#L152 >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>> >>> _______________________________________________ >>> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140206/4dc8100b/attachment-0001.html From matzew at apache.org Thu Feb 6 04:24:45 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 6 Feb 2014 10:24:45 +0100 Subject: [aerogear-dev] [SPS-JS] navigator.setMessageHandler Vs navigator.mozSetMessageHandler In-Reply-To: References: Message-ID: On Thu, Feb 6, 2014 at 10:21 AM, Sebastien Blanc wrote: > > > > On Thu, Feb 6, 2014 at 10:11 AM, Matthias Wessendorf wrote: > >> >> >> >> On Thu, Feb 6, 2014 at 10:07 AM, Sebastien Blanc wrote: >> >>> >>> >>> >>> On Thu, Feb 6, 2014 at 9:57 AM, Matthias Wessendorf wrote: >>> >>>> >>>> >>>> >>>> On Thu, Feb 6, 2014 at 9:52 AM, Sebastien Blanc wrote: >>>> >>>>> >>>>> >>>>> >>>>> On Thu, Feb 6, 2014 at 9:45 AM, Matthias Wessendorf >>>> > wrote: >>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Thu, Feb 6, 2014 at 9:42 AM, Sebastien Blanc wrote: >>>>>> >>>>>>> Hi, >>>>>>> Mozilla specifies[1] a function called "mozSetMessageHandler" while >>>>>>> we named this function "setMessageHandler" in our polyfill [2] . This is >>>>>>> the handler for incoming push notifications. >>>>>>> >>>>>>> I'm not really a big fan of specific prefixes but again if we want >>>>>>> to be really polyfill here, we should align. >>>>>>> >>>>>> >>>>>> hrm, not sure - I think, eventually theirs will be >>>>>> ``setMessageHandler`` as well; >>>>>> >>>>> >>>>> Yes, I should ping them on their list to have more details. >>>>> >>>>>> >>>>>> Why not just setting a reference from ``mozSetMessageHandler `` to >>>>>> ``setMessageHandler`` ? That way both would work, right ? >>>>>> >>>>> You mean defining both functions and calling setMessageHandler from >>>>> mozSetMessageHandler ? >>>>> >>>> >>>> >>>> No, just like: >>>> >>>> navigator.setMessageHandler = function(..) {........}; /// what we have >>>> ATM >>>> navigator.mozSetMessageHandler = navigator.setMessageHandler; // a >>>> reference >>>> >>> >>> Ok right , got it :) >>> That makes me think that we should have a page on our site describing >>> these kinds of things when develloping for ffos. >>> >> >> "these kind of things" ? >> > Things to take care of when implementing simple push in your app and want > to make sure it works on ffo, like adding permissions to the manifest, > yep, I agree > the ref to mozSetMessageHandler , etc ... > well, IMO that should be done in our software, for em > Just a simple guide. > Do we have a JIRA for a FFOS guide already ? > >> >>> >>> >>>> >>>> >>>> >>>> >>>>>> >>>>>>> wdyt ? >>>>>>> >>>>>>> Seb >>>>>>> >>>>>>> >>>>>>> >>>>>>> [1] >>>>>>> https://developer.mozilla.org/en-US/docs/Web/API/Navigator.mozSetMessageHandler >>>>>>> [2] >>>>>>> https://github.com/aerogear/aerogear-js/blob/master/src/simplepush/aerogear.simplepush.js#L152 >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>> >>>> _______________________________________________ >>>> 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/20140206/8c690f15/attachment.html From scm.blanc at gmail.com Thu Feb 6 04:31:51 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Thu, 6 Feb 2014 10:31:51 +0100 Subject: [aerogear-dev] [SPS-JS] navigator.setMessageHandler Vs navigator.mozSetMessageHandler In-Reply-To: References: Message-ID: On Thu, Feb 6, 2014 at 10:24 AM, Matthias Wessendorf wrote: > > > > On Thu, Feb 6, 2014 at 10:21 AM, Sebastien Blanc wrote: > >> >> >> >> On Thu, Feb 6, 2014 at 10:11 AM, Matthias Wessendorf wrote: >> >>> >>> >>> >>> On Thu, Feb 6, 2014 at 10:07 AM, Sebastien Blanc wrote: >>> >>>> >>>> >>>> >>>> On Thu, Feb 6, 2014 at 9:57 AM, Matthias Wessendorf wrote: >>>> >>>>> >>>>> >>>>> >>>>> On Thu, Feb 6, 2014 at 9:52 AM, Sebastien Blanc wrote: >>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Thu, Feb 6, 2014 at 9:45 AM, Matthias Wessendorf < >>>>>> matzew at apache.org> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, Feb 6, 2014 at 9:42 AM, Sebastien Blanc >>>>>> > wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> Mozilla specifies[1] a function called "mozSetMessageHandler" while >>>>>>>> we named this function "setMessageHandler" in our polyfill [2] . This is >>>>>>>> the handler for incoming push notifications. >>>>>>>> >>>>>>>> I'm not really a big fan of specific prefixes but again if we want >>>>>>>> to be really polyfill here, we should align. >>>>>>>> >>>>>>> >>>>>>> hrm, not sure - I think, eventually theirs will be >>>>>>> ``setMessageHandler`` as well; >>>>>>> >>>>>> >>>>>> Yes, I should ping them on their list to have more details. >>>>>> >>>>>>> >>>>>>> Why not just setting a reference from ``mozSetMessageHandler `` to >>>>>>> ``setMessageHandler`` ? That way both would work, right ? >>>>>>> >>>>>> You mean defining both functions and calling setMessageHandler from >>>>>> mozSetMessageHandler ? >>>>>> >>>>> >>>>> >>>>> No, just like: >>>>> >>>>> navigator.setMessageHandler = function(..) {........}; /// what we >>>>> have ATM >>>>> navigator.mozSetMessageHandler = navigator.setMessageHandler; // a >>>>> reference >>>>> >>>> >>>> Ok right , got it :) >>>> That makes me think that we should have a page on our site describing >>>> these kinds of things when develloping for ffos. >>>> >>> >>> "these kind of things" ? >>> >> Things to take care of when implementing simple push in your app and want >> to make sure it works on ffo, like adding permissions to the manifest, >> > > yep, I agree > > >> the ref to mozSetMessageHandler , etc ... >> > > well, IMO that should be done in our software, for em > Ah ok, directly in our lib, yeah of course that makes even more sense :) Let's see what Luke think about this. > > > >> Just a simple guide. >> > > Do we have a JIRA for a FFOS guide already ? > We have now ;) https://issues.jboss.org/browse/AEROGEAR-1429 > > > >> >>> >>>> >>>> >>>>> >>>>> >>>>> >>>>> >>>>>>> >>>>>>>> wdyt ? >>>>>>>> >>>>>>>> Seb >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> [1] >>>>>>>> https://developer.mozilla.org/en-US/docs/Web/API/Navigator.mozSetMessageHandler >>>>>>>> [2] >>>>>>>> https://github.com/aerogear/aerogear-js/blob/master/src/simplepush/aerogear.simplepush.js#L152 >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>> >>>>> _______________________________________________ >>>>> 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 > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140206/a2762288/attachment-0001.html From matzew at apache.org Thu Feb 6 06:28:39 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 6 Feb 2014 12:28:39 +0100 Subject: [aerogear-dev] Differences between Firefox OS "native" Push lib and AeroGear's Push adapter In-Reply-To: References: Message-ID: On Wed, Feb 5, 2014 at 11:52 PM, Matthias Wessendorf wrote: > > > > On Wed, Feb 5, 2014 at 11:22 PM, Sebastien Blanc wrote: > >> Hi, >> While playing today with my Firefox Device and its native Simple Push >> support I noticed some differences between our implementation and the >> native Push regarding the success callback after a register : >> >> >> >> >> >> //Native FFOS Push >> broadcastRequest = navigator.push.register(); >> broadcastRequest.onsuccess = function (event) { >> broadcastEndpoint = broadcastRequest.result; // only contains the pushURL >> } >> >> >> //Aerogear Push Adapter >> broadcastRequest = navigator.push.register(); >> broadcastRequest.onsuccess = function (event) { >> broadcastEndpoint = broadcastRequest.result.pushEndpoint; >> channelID = broadcastRequest.result.channelID; >> version = broadcastRequest.result.version; >> status = broadcastRequest.result.status >> } >> >> So, the AeroGear Push exposes much more in the callback that it should >> suppose to do : just exposing the pushEndpoint. >> >> The reason we do that I suppose, but Luke or Kris could confirm that, is >> that we thought respecting the SPS protocol, which indeed returns a whole >> object containing all the info. It is just that the Native Push Client API >> filter that out in the callback response. >> > > > Did they change that recently? Or was theirs always like it is now ? > > > >> After discussing that on the #push channel with the Mozilla people they >> confirmed me that we should only expoe the pushEndpoint. >> > > > yep, I agree on changing our JS polyfil > > > >> >> If we keep it as is, this can be problematic when we want to use the same >> code both for native and with the adapter when, for instance, registering >> to the UPS : >> >> broadcastRequest = navigator.push.register(); >> broadcastRequest.onsuccess = function (event) { >> broadcastEndpoint = event.target.result; >> var broadCastSettings = { >> metadata: { >> deviceToken: broadcastEndpoint.channelID, >> simplePushEndpoint: broadcastEndpoint.pushEndpoint >> } >> } >> UPClient.registerWithPushServer(broadCastSettings); >> } >> >> >> >> This won't work with the native push since "broadcastEndpoint.channelID" >> will be undefined. >> > > sweet :-) > > >> >> So I propose that we change the behaviour, to return only the >> pushEndpoint in the callback, even if that means a bit of String >> manipulation when we want to perform the registration to the UPS : >> >> var broadCastSettings = { >> metadata: { >> deviceToken: broadcastEndpoint.substr(broadcastEndpoint.lastIndexOf('/') + 1), >> simplePushEndpoint: broadcastEndpoint >> } >> } >> >> >> > well, that's not really good for security reasons, since their looooong > 'substring' was done for that. Also that's just redundant. > > The I guess, the deviceToken (channelID registration) might be a bit > bogus, for SimplePush. Let me think about it.... > Right now we use the channelID as the deviceToken, but we should not really 'leak' the channelID (see [1]), so I guess the here proposed change makes sense. Don't recall exactly why we did it in the past, but yeah - let's change it. Thinking about the consequence: I think we should use store the value of the returned 'pushEndpoint' string as our device-token. At the end the device-token is really the thing that identifies a device w/in the target network. Apple/Google uses a unique string, and if Mozilla uses a URL, that's totally fine. Reading the protocol definitions (see [1]) for the 'endpoint' I think it is fair to use that (unique) URL string as the device-token; And we could use this token value as well for the unregister calls, instead of the channelIDs. Any thoughts ? -Matthias [1] https://wiki.mozilla.org/WebAPI/SimplePush/Protocol#Definitions > > That said, we still have no clue how to proper clean-up 'out dated' > channels, since the SimplePush Server/Protocol is silent on that (unlike > APNs / GCM). but that's really a different thread (yep, we have a future > JIRA for that) > > > -M > > > >> wdyt ? >> >> Seb >> >> >> ps : our SPS Server implementation stays correct and returns what should >> be returned, it's really just the client part and how we expose the result >> >> >> _______________________________________________ >> 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 > -- 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/20140206/86cd5a5c/attachment.html From daniel.bevenius at gmail.com Thu Feb 6 06:51:06 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Thu, 6 Feb 2014 12:51:06 +0100 Subject: [aerogear-dev] Differences between Firefox OS "native" Push lib and AeroGear's Push adapter In-Reply-To: References: Message-ID: +1 Sounds reasonable I think. On 6 February 2014 12:28, Matthias Wessendorf wrote: > > > > On Wed, Feb 5, 2014 at 11:52 PM, Matthias Wessendorf wrote: > >> >> >> >> On Wed, Feb 5, 2014 at 11:22 PM, Sebastien Blanc wrote: >> >>> Hi, >>> While playing today with my Firefox Device and its native Simple Push >>> support I noticed some differences between our implementation and the >>> native Push regarding the success callback after a register : >>> >>> >>> >>> >>> >>> >>> //Native FFOS Push >>> broadcastRequest = navigator.push.register(); >>> broadcastRequest.onsuccess = function (event) { >>> broadcastEndpoint = broadcastRequest.result; // only contains the pushURL >>> } >>> >>> >>> //Aerogear Push Adapter >>> broadcastRequest = navigator.push.register(); >>> broadcastRequest.onsuccess = function (event) { >>> broadcastEndpoint = broadcastRequest.result.pushEndpoint; >>> channelID = broadcastRequest.result.channelID; >>> version = broadcastRequest.result.version; >>> status = broadcastRequest.result.status >>> } >>> >>> So, the AeroGear Push exposes much more in the callback that it should >>> suppose to do : just exposing the pushEndpoint. >>> >>> The reason we do that I suppose, but Luke or Kris could confirm that, is >>> that we thought respecting the SPS protocol, which indeed returns a whole >>> object containing all the info. It is just that the Native Push Client API >>> filter that out in the callback response. >>> >> >> >> Did they change that recently? Or was theirs always like it is now ? >> >> >> >>> After discussing that on the #push channel with the Mozilla people >>> they confirmed me that we should only expoe the pushEndpoint. >>> >> >> >> yep, I agree on changing our JS polyfil >> >> >> >>> >>> If we keep it as is, this can be problematic when we want to use the >>> same code both for native and with the adapter when, for instance, >>> registering to the UPS : >>> >>> broadcastRequest = navigator.push.register(); >>> broadcastRequest.onsuccess = function (event) { >>> broadcastEndpoint = event.target.result; >>> var broadCastSettings = { >>> metadata: { >>> deviceToken: broadcastEndpoint.channelID, >>> simplePushEndpoint: broadcastEndpoint.pushEndpoint >>> } >>> } >>> UPClient.registerWithPushServer(broadCastSettings); >>> } >>> >>> >>> >>> This won't work with the native push since "broadcastEndpoint.channelID" >>> will be undefined. >>> >> >> sweet :-) >> >> >>> >>> So I propose that we change the behaviour, to return only the >>> pushEndpoint in the callback, even if that means a bit of String >>> manipulation when we want to perform the registration to the UPS : >>> >>> var broadCastSettings = { >>> metadata: { >>> deviceToken: broadcastEndpoint.substr(broadcastEndpoint.lastIndexOf('/') + 1), >>> simplePushEndpoint: broadcastEndpoint >>> } >>> } >>> >>> >>> >> well, that's not really good for security reasons, since their looooong >> 'substring' was done for that. Also that's just redundant. >> >> The I guess, the deviceToken (channelID registration) might be a bit >> bogus, for SimplePush. Let me think about it.... >> > > > Right now we use the channelID as the deviceToken, but we should not > really 'leak' the channelID (see [1]), so I guess the here proposed change > makes sense. Don't recall exactly why we did it in the past, but yeah - > let's change it. > > > Thinking about the consequence: I think we should use store the value of > the returned 'pushEndpoint' string as our device-token. At the end the > device-token is really the thing that identifies a device w/in the target > network. Apple/Google uses a unique string, and if Mozilla uses a URL, > that's totally fine. > > Reading the protocol definitions (see [1]) for the 'endpoint' I think it > is fair to use that (unique) URL string as the device-token; And we could > use this token value as well for the unregister calls, instead of the > channelIDs. > > > Any thoughts ? > > > -Matthias > > [1] https://wiki.mozilla.org/WebAPI/SimplePush/Protocol#Definitions > > > > >> >> That said, we still have no clue how to proper clean-up 'out dated' >> channels, since the SimplePush Server/Protocol is silent on that (unlike >> APNs / GCM). but that's really a different thread (yep, we have a future >> JIRA for that) >> >> >> -M >> >> >> >>> wdyt ? >>> >>> Seb >>> >>> >>> ps : our SPS Server implementation stays correct and returns what should >>> be returned, it's really just the client part and how we expose the result >>> >>> >>> _______________________________________________ >>> 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 >> > > > > -- > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140206/6c86e742/attachment-0001.html From corinnekrych at gmail.com Thu Feb 6 08:32:21 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Thu, 6 Feb 2014 14:32:21 +0100 Subject: [aerogear-dev] [sync] Diff libraries In-Reply-To: <4C4D87F8-F786-40E3-A3D3-ACA2FFB812B7@gmail.com> References: <463B8AA0-68AB-4C37-8401-EA35D6E6528E@gmail.com> <52F25301.6060904@redhat.com> <4C4D87F8-F786-40E3-A3D3-ACA2FFB812B7@gmail.com> Message-ID: <47F5816F-F3C3-4068-9181-7D0EE7D1CFDC@gmail.com> Hello Guys, So in despair of finding an iOS version of a ?diff-patch? library for object comparison, I?ve started implementing one [1]. It is pretty much inspired by jsonndiffpatch JS lib and use the same delta legend [2]. I haven?t finished it yet, it is missing LCS implementation[3] (the most complex part tbh) and it will need several iterations for completion. I will use it in our sync-demo app [4] replacing the actual use of google-diff-patch-merge [5] as like summers stated it, comparison of stringified objects is not sufficient. The idea is to stay pluggable in the way we handle conflict. If the app is a chat or text document we?ll use [5] with text differences. ++ Corinne [1] https://github.com/corinnekrych/aerogear-diff-patch-ios [2] https://github.com/benjamine/JsonDiffPatch#delta-legend [3] http://en.wikipedia.org/wiki/Longest_common_subsequence_problem [4] https://github.com/corinnekrych/aerogear-ios-cookbook/blob/sync.demo.recipe/Hobbies/Hobbies/AGBuddiesViewController.m#L157 [5] https://github.com/JanX2/google-diff-match-patch-Objective-C (cool stuff i?m part of contributors! ;) there is no simple pleasure. On 05 Feb 2014, at 16:37, Corinne Krych wrote: > > On 05 Feb 2014, at 16:04, Summers Pittman wrote: > >> >> >> On Wed 05 Feb 2014 09:41:05 AM EST, Corinne Krych wrote: >>> Rather than a text diff i?d like something that compares data structure (JSON like) diff. >>> I can use google diff by serialiazing to string but it?s a plain text diff rather than object diff. Guess you can patch the stringyfied object an then convert it back to json structure but less elegant and flexible than jsondiffpatch on object. >> >> If you go this route you need to make sure that things like order of variables, order of items in an array/collection, etc always come out the same way. >> >> Also you need to make sure your stringified / merged JSON is still valid JSON. >> > > Exactly. I dont feel that?s the right route > > >> You may be off using hashing of your objects and doing set comparisons. Unfortunately I do not know of a library which makes that "free". I used that on the DevNexus demo. > > Jsondiffpatch js does handle it nicely. > Might be some similar libs in Java? > >> >>> >>> ++ >>> Corinne >>> On 05 Feb 2014, at 11:23, Christos Vasilakis wrote: >>> >>>> Hi Corinne, >>>> >>>> i did came across the following diff-match lib[1] might be interested to digg more, as I have seen they all derive from google-diff >>>> >>>> [1] https://github.com/inquisitiveSoft/DiffMatchPatch-ObjC [+podspec] >>>> >>>> >>>> >>>> On Wed, Feb 5, 2014 at 10:49 AM, Corinne Krych wrote: >>>> Hello Ladies and Gentlemen, >>>> >>>> I was looking for some diff/patch libraries to get differences between 2 objects (either json format of map/array format) ideally in iOS (withpodspec) or in C/C++. To plug into custom conflict management in you sync demo app. Like Luke did using jsondiffpatch in JS [1]. >>>> >>>> For comparing text there is google-diff-match-patch [2] lib that is implemented in several langagues and format (including iOS). >>>> >>>> But i couldn?t find a jsondiff liek lib for iOS? I?m asking my favourite oracle (i.e.: the mailing list), see if i get more lucky. >>>> >>>> ++ >>>> Corinne >>>> [1] https://github.com/benjamine/JsonDiffPatch >>>> [2] https://github.com/JanX2/google-diff-match-patch >>>> _______________________________________________ >>>> 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 >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > From scm.blanc at gmail.com Thu Feb 6 09:11:08 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Thu, 6 Feb 2014 15:11:08 +0100 Subject: [aerogear-dev] Differences between Firefox OS "native" Push lib and AeroGear's Push adapter In-Reply-To: References: Message-ID: On Thu, Feb 6, 2014 at 12:28 PM, Matthias Wessendorf wrote: > > > > On Wed, Feb 5, 2014 at 11:52 PM, Matthias Wessendorf wrote: > >> >> >> >> On Wed, Feb 5, 2014 at 11:22 PM, Sebastien Blanc wrote: >> >>> Hi, >>> While playing today with my Firefox Device and its native Simple Push >>> support I noticed some differences between our implementation and the >>> native Push regarding the success callback after a register : >>> >>> >>> >>> >>> >>> >>> //Native FFOS Push >>> broadcastRequest = navigator.push.register(); >>> broadcastRequest.onsuccess = function (event) { >>> broadcastEndpoint = broadcastRequest.result; // only contains the pushURL >>> } >>> >>> >>> //Aerogear Push Adapter >>> broadcastRequest = navigator.push.register(); >>> broadcastRequest.onsuccess = function (event) { >>> broadcastEndpoint = broadcastRequest.result.pushEndpoint; >>> channelID = broadcastRequest.result.channelID; >>> version = broadcastRequest.result.version; >>> status = broadcastRequest.result.status >>> } >>> >>> So, the AeroGear Push exposes much more in the callback that it should >>> suppose to do : just exposing the pushEndpoint. >>> >>> The reason we do that I suppose, but Luke or Kris could confirm that, is >>> that we thought respecting the SPS protocol, which indeed returns a whole >>> object containing all the info. It is just that the Native Push Client API >>> filter that out in the callback response. >>> >> >> >> Did they change that recently? Or was theirs always like it is now ? >> >> >> >>> After discussing that on the #push channel with the Mozilla people >>> they confirmed me that we should only expoe the pushEndpoint. >>> >> >> >> yep, I agree on changing our JS polyfil >> >> >> >>> >>> If we keep it as is, this can be problematic when we want to use the >>> same code both for native and with the adapter when, for instance, >>> registering to the UPS : >>> >>> broadcastRequest = navigator.push.register(); >>> broadcastRequest.onsuccess = function (event) { >>> broadcastEndpoint = event.target.result; >>> var broadCastSettings = { >>> metadata: { >>> deviceToken: broadcastEndpoint.channelID, >>> simplePushEndpoint: broadcastEndpoint.pushEndpoint >>> } >>> } >>> UPClient.registerWithPushServer(broadCastSettings); >>> } >>> >>> >>> >>> This won't work with the native push since "broadcastEndpoint.channelID" >>> will be undefined. >>> >> >> sweet :-) >> >> >>> >>> So I propose that we change the behaviour, to return only the >>> pushEndpoint in the callback, even if that means a bit of String >>> manipulation when we want to perform the registration to the UPS : >>> >>> var broadCastSettings = { >>> metadata: { >>> deviceToken: broadcastEndpoint.substr(broadcastEndpoint.lastIndexOf('/') + 1), >>> simplePushEndpoint: broadcastEndpoint >>> } >>> } >>> >>> >>> >> well, that's not really good for security reasons, since their looooong >> 'substring' was done for that. Also that's just redundant. >> >> The I guess, the deviceToken (channelID registration) might be a bit >> bogus, for SimplePush. Let me think about it.... >> > > > Right now we use the channelID as the deviceToken, but we should not > really 'leak' the channelID (see [1]), so I guess the here proposed change > makes sense. Don't recall exactly why we did it in the past, but yeah - > let's change it. > > > Thinking about the consequence: I think we should use store the value of > the returned 'pushEndpoint' string as our device-token. At the end the > device-token is really the thing that identifies a device w/in the target > network. Apple/Google uses a unique string, and if Mozilla uses a URL, > that's totally fine. > > Reading the protocol definitions (see [1]) for the 'endpoint' I think it > is fair to use that (unique) URL string as the device-token; And we could > use this token value as well for the unregister calls, instead of the > channelIDs. > After reading your comment on the PR https://github.com/aerogear/aerogear-js/pull/105#issuecomment-34324732 I understand that you just want to use the deviceToken and not pass the simplePushEndpoint to UPS anymore, is that right ? > > > Any thoughts ? > > > -Matthias > > [1] https://wiki.mozilla.org/WebAPI/SimplePush/Protocol#Definitions > > > > >> >> That said, we still have no clue how to proper clean-up 'out dated' >> channels, since the SimplePush Server/Protocol is silent on that (unlike >> APNs / GCM). but that's really a different thread (yep, we have a future >> JIRA for that) >> >> >> -M >> >> >> >>> wdyt ? >>> >>> Seb >>> >>> >>> ps : our SPS Server implementation stays correct and returns what should >>> be returned, it's really just the client part and how we expose the result >>> >>> >>> _______________________________________________ >>> 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 >> > > > > -- > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140206/b22c4dd1/attachment-0001.html From matzew at apache.org Thu Feb 6 09:27:29 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 6 Feb 2014 15:27:29 +0100 Subject: [aerogear-dev] Differences between Firefox OS "native" Push lib and AeroGear's Push adapter In-Reply-To: References: Message-ID: On Thu, Feb 6, 2014 at 3:11 PM, Sebastien Blanc wrote: > > > > On Thu, Feb 6, 2014 at 12:28 PM, Matthias Wessendorf wrote: > >> >> >> >> On Wed, Feb 5, 2014 at 11:52 PM, Matthias Wessendorf wrote: >> >>> >>> >>> >>> On Wed, Feb 5, 2014 at 11:22 PM, Sebastien Blanc wrote: >>> >>>> Hi, >>>> While playing today with my Firefox Device and its native Simple Push >>>> support I noticed some differences between our implementation and the >>>> native Push regarding the success callback after a register : >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> //Native FFOS Push >>>> broadcastRequest = navigator.push.register(); >>>> broadcastRequest.onsuccess = function (event) { >>>> broadcastEndpoint = broadcastRequest.result; // only contains the pushURL >>>> } >>>> >>>> >>>> //Aerogear Push Adapter >>>> broadcastRequest = navigator.push.register(); >>>> broadcastRequest.onsuccess = function (event) { >>>> broadcastEndpoint = broadcastRequest.result.pushEndpoint; >>>> channelID = broadcastRequest.result.channelID; >>>> version = broadcastRequest.result.version; >>>> status = broadcastRequest.result.status >>>> } >>>> >>>> So, the AeroGear Push exposes much more in the callback that it should >>>> suppose to do : just exposing the pushEndpoint. >>>> >>>> The reason we do that I suppose, but Luke or Kris could confirm that, >>>> is that we thought respecting the SPS protocol, which indeed returns a >>>> whole object containing all the info. It is just that the Native Push >>>> Client API filter that out in the callback response. >>>> >>> >>> >>> Did they change that recently? Or was theirs always like it is now ? >>> >>> >>> >>>> After discussing that on the #push channel with the Mozilla people >>>> they confirmed me that we should only expoe the pushEndpoint. >>>> >>> >>> >>> yep, I agree on changing our JS polyfil >>> >>> >>> >>>> >>>> If we keep it as is, this can be problematic when we want to use the >>>> same code both for native and with the adapter when, for instance, >>>> registering to the UPS : >>>> >>>> broadcastRequest = navigator.push.register(); >>>> broadcastRequest.onsuccess = function (event) { >>>> broadcastEndpoint = event.target.result; >>>> var broadCastSettings = { >>>> metadata: { >>>> deviceToken: broadcastEndpoint.channelID, >>>> simplePushEndpoint: broadcastEndpoint.pushEndpoint >>>> } >>>> } >>>> UPClient.registerWithPushServer(broadCastSettings); >>>> } >>>> >>>> >>>> >>>> This won't work with the native push since "broadcastEndpoint.channelID" >>>> will be undefined. >>>> >>> >>> sweet :-) >>> >>> >>>> >>>> So I propose that we change the behaviour, to return only the >>>> pushEndpoint in the callback, even if that means a bit of String >>>> manipulation when we want to perform the registration to the UPS : >>>> >>>> var broadCastSettings = { >>>> metadata: { >>>> deviceToken: broadcastEndpoint.substr(broadcastEndpoint.lastIndexOf('/') + 1), >>>> simplePushEndpoint: broadcastEndpoint >>>> } >>>> } >>>> >>>> >>>> >>> well, that's not really good for security reasons, since their looooong >>> 'substring' was done for that. Also that's just redundant. >>> >>> The I guess, the deviceToken (channelID registration) might be a bit >>> bogus, for SimplePush. Let me think about it.... >>> >> >> >> Right now we use the channelID as the deviceToken, but we should not >> really 'leak' the channelID (see [1]), so I guess the here proposed change >> makes sense. Don't recall exactly why we did it in the past, but yeah - >> let's change it. >> >> >> Thinking about the consequence: I think we should use store the value of >> the returned 'pushEndpoint' string as our device-token. At the end the >> device-token is really the thing that identifies a device w/in the target >> network. Apple/Google uses a unique string, and if Mozilla uses a URL, >> that's totally fine. >> >> Reading the protocol definitions (see [1]) for the 'endpoint' I think it >> is fair to use that (unique) URL string as the device-token; And we could >> use this token value as well for the unregister calls, instead of the >> channelIDs. >> > > After reading your comment on the PR > https://github.com/aerogear/aerogear-js/pull/105#issuecomment-34324732 I > understand that you just want to use the deviceToken and not pass the > simplePushEndpoint to UPS anymore, is that right ? > yep > >> >> Any thoughts ? >> >> >> -Matthias >> >> [1] https://wiki.mozilla.org/WebAPI/SimplePush/Protocol#Definitions >> >> >> >> >>> >>> That said, we still have no clue how to proper clean-up 'out dated' >>> channels, since the SimplePush Server/Protocol is silent on that (unlike >>> APNs / GCM). but that's really a different thread (yep, we have a future >>> JIRA for that) >>> >>> >>> -M >>> >>> >>> >>>> wdyt ? >>>> >>>> Seb >>>> >>>> >>>> ps : our SPS Server implementation stays correct and returns what >>>> should be returned, it's really just the client part and how we expose the >>>> result >>>> >>>> >>>> _______________________________________________ >>>> 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 >>> >> >> >> >> -- >> 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/20140206/53339b6b/attachment.html From matzew at apache.org Thu Feb 6 09:54:08 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 6 Feb 2014 15:54:08 +0100 Subject: [aerogear-dev] [sync] Diff libraries In-Reply-To: <47F5816F-F3C3-4068-9181-7D0EE7D1CFDC@gmail.com> References: <463B8AA0-68AB-4C37-8401-EA35D6E6528E@gmail.com> <52F25301.6060904@redhat.com> <4C4D87F8-F786-40E3-A3D3-ACA2FFB812B7@gmail.com> <47F5816F-F3C3-4068-9181-7D0EE7D1CFDC@gmail.com> Message-ID: On Thu, Feb 6, 2014 at 2:32 PM, Corinne Krych wrote: > Hello Guys, > > So in despair of finding an iOS version of a 'diff-patch' library for > object comparison, I've started implementing one [1]. It is pretty much > inspired by jsonndiffpatch JS lib and use the same delta legend [2]. I > haven't finished it yet, it is missing LCS implementation[3] (the most > complex part tbh) and it will need several iterations for completion. > > I will use it in our sync-demo app [4] replacing the actual use of > google-diff-patch-merge [5] as like summers stated it, comparison of > stringified objects is not sufficient. > > The idea is to stay pluggable in the way we handle conflict. If the app is > a chat or text document we'll use [5] with text differences. > > awesome! > ++ > Corinne > [1] https://github.com/corinnekrych/aerogear-diff-patch-ios > [2] https://github.com/benjamine/JsonDiffPatch#delta-legend > [3] http://en.wikipedia.org/wiki/Longest_common_subsequence_problem > [4] > https://github.com/corinnekrych/aerogear-ios-cookbook/blob/sync.demo.recipe/Hobbies/Hobbies/AGBuddiesViewController.m#L157 > [5] https://github.com/JanX2/google-diff-match-patch-Objective-C (cool > stuff i'm part of contributors! ;) there is no simple pleasure. > > On 05 Feb 2014, at 16:37, Corinne Krych wrote: > > > > > On 05 Feb 2014, at 16:04, Summers Pittman wrote: > > > >> > >> > >> On Wed 05 Feb 2014 09:41:05 AM EST, Corinne Krych wrote: > >>> Rather than a text diff i'd like something that compares data > structure (JSON like) diff. > >>> I can use google diff by serialiazing to string but it's a plain text > diff rather than object diff. Guess you can patch the stringyfied object an > then convert it back to json structure but less elegant and flexible than > jsondiffpatch on object. > >> > >> If you go this route you need to make sure that things like order of > variables, order of items in an array/collection, etc always come out the > same way. > >> > >> Also you need to make sure your stringified / merged JSON is still > valid JSON. > >> > > > > Exactly. I dont feel that's the right route > > > > > >> You may be off using hashing of your objects and doing set comparisons. > Unfortunately I do not know of a library which makes that "free". I used > that on the DevNexus demo. > > > > Jsondiffpatch js does handle it nicely. > > Might be some similar libs in Java? > > > >> > >>> > >>> ++ > >>> Corinne > >>> On 05 Feb 2014, at 11:23, Christos Vasilakis > wrote: > >>> > >>>> Hi Corinne, > >>>> > >>>> i did came across the following diff-match lib[1] might be interested > to digg more, as I have seen they all derive from google-diff > >>>> > >>>> [1] https://github.com/inquisitiveSoft/DiffMatchPatch-ObjC > [+podspec] > >>>> > >>>> > >>>> > >>>> On Wed, Feb 5, 2014 at 10:49 AM, Corinne Krych < > corinnekrych at gmail.com> wrote: > >>>> Hello Ladies and Gentlemen, > >>>> > >>>> I was looking for some diff/patch libraries to get differences > between 2 objects (either json format of map/array format) ideally in iOS > (withpodspec) or in C/C++. To plug into custom conflict management in you > sync demo app. Like Luke did using jsondiffpatch in JS [1]. > >>>> > >>>> For comparing text there is google-diff-match-patch [2] lib that is > implemented in several langagues and format (including iOS). > >>>> > >>>> But i couldn't find a jsondiff liek lib for iOS... I'm asking my > favourite oracle (i.e.: the mailing list), see if i get more lucky. > >>>> > >>>> ++ > >>>> Corinne > >>>> [1] https://github.com/benjamine/JsonDiffPatch > >>>> [2] https://github.com/JanX2/google-diff-match-patch > >>>> _______________________________________________ > >>>> 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 > >>> > >>> > >>> _______________________________________________ > >>> 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/20140206/61483e9a/attachment-0001.html From cvasilak at gmail.com Thu Feb 6 09:58:59 2014 From: cvasilak at gmail.com (Christos Vasilakis) Date: Thu, 6 Feb 2014 16:58:59 +0200 Subject: [aerogear-dev] [sync] Diff libraries In-Reply-To: <47F5816F-F3C3-4068-9181-7D0EE7D1CFDC@gmail.com> References: <463B8AA0-68AB-4C37-8401-EA35D6E6528E@gmail.com> <52F25301.6060904@redhat.com> <4C4D87F8-F786-40E3-A3D3-ACA2FFB812B7@gmail.com> <47F5816F-F3C3-4068-9181-7D0EE7D1CFDC@gmail.com> Message-ID: On Feb 6, 2014, at 3:32 PM, Corinne Krych wrote: > Hello Guys, > > So in despair of finding an iOS version of a ?diff-patch? library for object comparison, I?ve started implementing one [1]. It is pretty which reminds me "Necessity is the mother of invention? :) nice work Corinne! > much inspired by jsonndiffpatch JS lib and use the same delta legend [2]. I haven?t finished it yet, it is missing LCS implementation[3] (the most complex part tbh) and it will need several iterations for completion. > > I will use it in our sync-demo app [4] replacing the actual use of google-diff-patch-merge [5] as like summers stated it, comparison of stringified objects is not sufficient. > > The idea is to stay pluggable in the way we handle conflict. If the app is a chat or text document we?ll use [5] with text differences. > > ++ > Corinne > [1] https://github.com/corinnekrych/aerogear-diff-patch-ios > [2] https://github.com/benjamine/JsonDiffPatch#delta-legend > [3] http://en.wikipedia.org/wiki/Longest_common_subsequence_problem > [4] https://github.com/corinnekrych/aerogear-ios-cookbook/blob/sync.demo.recipe/Hobbies/Hobbies/AGBuddiesViewController.m#L157 > [5] https://github.com/JanX2/google-diff-match-patch-Objective-C (cool stuff i?m part of contributors! ;) there is no simple pleasure. > > On 05 Feb 2014, at 16:37, Corinne Krych wrote: > >> >> On 05 Feb 2014, at 16:04, Summers Pittman wrote: >> >>> >>> >>> On Wed 05 Feb 2014 09:41:05 AM EST, Corinne Krych wrote: >>>> Rather than a text diff i?d like something that compares data structure (JSON like) diff. >>>> I can use google diff by serialiazing to string but it?s a plain text diff rather than object diff. Guess you can patch the stringyfied object an then convert it back to json structure but less elegant and flexible than jsondiffpatch on object. >>> >>> If you go this route you need to make sure that things like order of variables, order of items in an array/collection, etc always come out the same way. >>> >>> Also you need to make sure your stringified / merged JSON is still valid JSON. >>> >> >> Exactly. I dont feel that?s the right route >> >> >>> You may be off using hashing of your objects and doing set comparisons. Unfortunately I do not know of a library which makes that "free". I used that on the DevNexus demo. >> >> Jsondiffpatch js does handle it nicely. >> Might be some similar libs in Java? >> >>> >>>> >>>> ++ >>>> Corinne >>>> On 05 Feb 2014, at 11:23, Christos Vasilakis wrote: >>>> >>>>> Hi Corinne, >>>>> >>>>> i did came across the following diff-match lib[1] might be interested to digg more, as I have seen they all derive from google-diff >>>>> >>>>> [1] https://github.com/inquisitiveSoft/DiffMatchPatch-ObjC [+podspec] >>>>> >>>>> >>>>> >>>>> On Wed, Feb 5, 2014 at 10:49 AM, Corinne Krych wrote: >>>>> Hello Ladies and Gentlemen, >>>>> >>>>> I was looking for some diff/patch libraries to get differences between 2 objects (either json format of map/array format) ideally in iOS (withpodspec) or in C/C++. To plug into custom conflict management in you sync demo app. Like Luke did using jsondiffpatch in JS [1]. >>>>> >>>>> For comparing text there is google-diff-match-patch [2] lib that is implemented in several langagues and format (including iOS). >>>>> >>>>> But i couldn?t find a jsondiff liek lib for iOS? I?m asking my favourite oracle (i.e.: the mailing list), see if i get more lucky. >>>>> >>>>> ++ >>>>> Corinne >>>>> [1] https://github.com/benjamine/JsonDiffPatch >>>>> [2] https://github.com/JanX2/google-diff-match-patch >>>>> _______________________________________________ >>>>> 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 >>>> >>>> >>>> _______________________________________________ >>>> 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 From avibelli at redhat.com Fri Feb 7 02:30:00 2014 From: avibelli at redhat.com (Andrea Vibelli) Date: Fri, 7 Feb 2014 02:30:00 -0500 (EST) Subject: [aerogear-dev] [iOS] small libs In-Reply-To: <3E247C9A-880A-4411-9D68-264565C78FE0@gmail.com> References: <3E247C9A-880A-4411-9D68-264565C78FE0@gmail.com> Message-ID: <298667626.9314101.1391758200810.JavaMail.root@redhat.com> Hi, I do agree with the separation of the libraries, so that a user can use only the libraries that he needs. It's a cleaner approach and eventually would keep also the size of the imported libraries at the minimum, saving some space is always a good option when going on mobile even if nowadays the space is not a concern anymore :-) I would personally avoid having one single repo with all the code that builds a library with different 'granularity' (so an all-library-repository that has the option of building a subset of its packages), I would have one dedicated repository for each library that have to be built. For what I have seen, the approach that I would like most is the same that is being adopted by the EAP in the Maven world (https://github.com/jboss-developer/jboss-eap-boms): the definition of a bom with a set of submodules that specify all the different combinations of libraries to be built, each library having its own definition and repository. I don't know if a similar approach could be achievable with CocoaPods. I will try to investigate further. Andrea ----- Messaggio originale ----- > Da: "Corinne Krych" > A: "AeroGear Developer Mailing List" > Cc: avibelli at redhat.com > Inviato: Marted?, 4 febbraio 2014 13:39:29 > Oggetto: Re: [aerogear-dev] [iOS] small libs > > > On 04 Feb 2014, at 09:15, Matthias Wessendorf wrote: > > > > > > > > > On Tue, Feb 4, 2014 at 9:11 AM, Corinne Krych > > wrote: > > Hello iOS folks > > > > I?ve started looking at sync part, I?ve created a separate repo [1]. For > > now, this lib is dependant on iOS-core. does is worth having it separate > > for folks that what to use core without sync? > > > > yes > > > > Same question applies for encrypted store. Right now encrypted store are > > part of iOS-core. do we want to separate it for people who want core > > without encrypted store ? > > > > I do like the idea of separation > > Just for that i?ve created > https://issues.jboss.org/browse/AGIOS-160 > > > > > what about people who all it all, encrypted store+sync, we?ll have to > > manage correctly transitive dependencies. > > > > could we bundle something like an 'AeroGear-All-You-Can-Eat-iOS' (similar > > like something you can do w/ the maven-shade-plugin?). Adding Andrea, > > perhaps he has an idea on that > > Yep i guess we could have an aerogear-ios repo which gather all you can eat > Podspec > aerogear-ios could be renamed aerogear-core-ios. Coiuld be revisited in 2.0+ > Track in that JIRA > https://issues.jboss.org/browse/AGIOS-161 > > > > > > > wdty? > > > > ++ > > Corinne > > [1] https://github.com/corinnekrych/aerogear-sync-ios > > _______________________________________________ > > 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 > > From corinnekrych at gmail.com Fri Feb 7 02:36:36 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Fri, 7 Feb 2014 08:36:36 +0100 Subject: [aerogear-dev] [iOS] small libs In-Reply-To: <298667626.9314101.1391758200810.JavaMail.root@redhat.com> References: <3E247C9A-880A-4411-9D68-264565C78FE0@gmail.com> <298667626.9314101.1391758200810.JavaMail.root@redhat.com> Message-ID: <44CC11A0-5340-4B3F-9FC4-FE294F2BB576@gmail.com> On 07 Feb 2014, at 08:30, Andrea Vibelli wrote: > Hi, I do agree with the separation of the libraries, so that a user can use only the libraries that he needs. It's a cleaner approach and eventually would keep also the size of the imported libraries at the minimum, saving some space is always a good option when going on mobile even if nowadays the space is not a concern anymore :-) > > I would personally avoid having one single repo with all the code that builds a library with different 'granularity' (so an all-library-repository that has the option of building a subset of its packages), I would have one dedicated repository for each library that have to be built. +1 That?s what we?re doing right now on ios libs. > For what I have seen, the approach that I would like most is the same that is being adopted by the EAP in the Maven world (https://github.com/jboss-developer/jboss-eap-boms): the definition of a bom with a set of submodules that specify all the different combinations of libraries to be built, each library having its own definition and repository. I don't know if a similar approach could be achievable with CocoaPods. I don?t htink CocoaPods provides ?boms? like approach to build. Definitively something to explore and maybe propose to cocoapod community. > > I will try to investigate further. Keep in touch. Let us know your finding. > > Andrea > > > ----- Messaggio originale ----- >> Da: "Corinne Krych" >> A: "AeroGear Developer Mailing List" >> Cc: avibelli at redhat.com >> Inviato: Marted?, 4 febbraio 2014 13:39:29 >> Oggetto: Re: [aerogear-dev] [iOS] small libs >> >> >> On 04 Feb 2014, at 09:15, Matthias Wessendorf wrote: >> >>> >>> >>> >>> On Tue, Feb 4, 2014 at 9:11 AM, Corinne Krych >>> wrote: >>> Hello iOS folks >>> >>> I?ve started looking at sync part, I?ve created a separate repo [1]. For >>> now, this lib is dependant on iOS-core. does is worth having it separate >>> for folks that what to use core without sync? >>> >>> yes >>> >>> Same question applies for encrypted store. Right now encrypted store are >>> part of iOS-core. do we want to separate it for people who want core >>> without encrypted store ? >>> >>> I do like the idea of separation >> >> Just for that i?ve created >> https://issues.jboss.org/browse/AGIOS-160 >> >>> >>> what about people who all it all, encrypted store+sync, we?ll have to >>> manage correctly transitive dependencies. >>> >>> could we bundle something like an 'AeroGear-All-You-Can-Eat-iOS' (similar >>> like something you can do w/ the maven-shade-plugin?). Adding Andrea, >>> perhaps he has an idea on that >> >> Yep i guess we could have an aerogear-ios repo which gather all you can eat >> Podspec >> aerogear-ios could be renamed aerogear-core-ios. Coiuld be revisited in 2.0+ >> Track in that JIRA >> https://issues.jboss.org/browse/AGIOS-161 >> >>> >>> >>> wdty? >>> >>> ++ >>> Corinne >>> [1] https://github.com/corinnekrych/aerogear-sync-ios >>> _______________________________________________ >>> 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 >> >> From scm.blanc at gmail.com Sun Feb 9 06:06:39 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Sun, 9 Feb 2014 12:06:39 +0100 Subject: [aerogear-dev] [UPS] Proposal to change the Push Message Format Message-ID: Hi, I was looking at our current Push Message Format[1] and I was wonderimg if you should not add some more structure to it, decoupling config, criterias and the message itself : { "config" : { "ttl" : 3600, "content-available" : true, "simple-push": "version=123" }, "criteria" : { "alias" : ["user at account.com", "someone at aerogear.org", ....], "categories" : ["someCategory", "otherCategory"], "deviceType" : ["iPad", "AndroidTablet"], "variants" : ["c3f0a94f-48de-4b77-a08e-68114460857e", "444939cd-ae63-4ce1-96a4-de74b77e3737"] } , "message": { "alert":"HELLO!", "sound":"default", "badge":7, "someKey":"some value", "anotherCustomKey":"some other value" }, } wdyt ? Sebi [1]http://aerogear.org/docs/specs/aerogear-push-messages/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140209/67146b53/attachment.html From matzew at apache.org Sun Feb 9 08:14:40 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Sun, 9 Feb 2014 14:14:40 +0100 Subject: [aerogear-dev] [UPS] Proposal to change the Push Message Format In-Reply-To: References: Message-ID: On Sun, Feb 9, 2014 at 12:06 PM, Sebastien Blanc wrote: > Hi, > I was looking at our current Push Message Format[1] and I was wonderimg if > you should not add some more structure to it, decoupling config, criterias > and the message itself : > > > { > "config" : { > > "ttl" : 3600, > "content-available" : true, > "simple-push": "version=123" > > }, > "criteria" : { > > "alias" : ["user at account.com", "someone at aerogear.org", ....], > "categories" : ["someCategory", "otherCategory"], > "deviceType" : ["iPad", "AndroidTablet"], > "variants" : ["c3f0a94f-48de-4b77-a08e-68114460857e", "444939cd-ae63-4ce1-96a4-de74b77e3737"] > } > , > "message": { > "alert":"HELLO!", > "sound":"default", > "badge":7, > > "someKey":"some value", > > "anotherCustomKey":"some other value" > > }, > } > > wdyt ? > > interesting idea - it looks better structured. Regarding "simple-push": "version=123", I'd vote this not to be part of the 'configuration' section, it's the actual message/payload for SP -M > Sebi > > [1]http://aerogear.org/docs/specs/aerogear-push-messages/ > > > _______________________________________________ > 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/20140209/831f2c9b/attachment-0001.html From scm.blanc at gmail.com Sun Feb 9 09:06:30 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Sun, 9 Feb 2014 15:06:30 +0100 Subject: [aerogear-dev] [UPS] Proposal to change the Push Message Format In-Reply-To: References: Message-ID: On Sun, Feb 9, 2014 at 2:14 PM, Matthias Wessendorf wrote: > > > > On Sun, Feb 9, 2014 at 12:06 PM, Sebastien Blanc wrote: > >> Hi, >> I was looking at our current Push Message Format[1] and I was wonderimg >> if you should not add some more structure to it, decoupling config, >> criterias and the message itself : >> >> >> { >> "config" : { >> >> "ttl" : 3600, >> "content-available" : true, >> >> "simple-push": "version=123" >> >> }, >> "criteria" : { >> >> "alias" : ["user at account.com", "someone at aerogear.org", ....], >> >> "categories" : ["someCategory", "otherCategory"], >> >> "deviceType" : ["iPad", "AndroidTablet"], >> >> "variants" : ["c3f0a94f-48de-4b77-a08e-68114460857e", "444939cd-ae63-4ce1-96a4-de74b77e3737"] >> >> } >> , >> "message": { >> "alert":"HELLO!", >> "sound":"default", >> "badge":7, >> >> "someKey":"some value", >> >> "anotherCustomKey":"some other value" >> >> }, >> } >> >> wdyt ? >> >> > interesting idea - it looks better structured. > > Regarding "simple-push": "version=123", I'd vote this not to be part of > the 'configuration' section, it's the actual message/payload for SP > Right ! here the updated gist https://gist.github.com/sebastienblanc/8897596 > > > -M > > >> Sebi >> >> >> [1]http://aerogear.org/docs/specs/aerogear-push-messages/ >> >> >> _______________________________________________ >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140209/d9983786/attachment.html From bruno at abstractj.org Mon Feb 10 04:02:14 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Mon, 10 Feb 2014 07:02:14 -0200 Subject: [aerogear-dev] Team meeting agenda for today Message-ID: http://oksoclap.com/p/UemilzzAVV -- abstractj From corinnekrych at gmail.com Mon Feb 10 06:38:49 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Mon, 10 Feb 2014 12:38:49 +0100 Subject: [aerogear-dev] DataSync or SyncPipe API proposal Message-ID: <49EB4088-E00E-40F2-A231-E294A8687171@gmail.com> Hello Guys, Following discussion on ML thread [1], and JIRA discussion [2] (sorry guys I catched up the discussion late, I wasn?t watching the JIRa ticket so i didn?t get notifications) here is the 2 gists we have: 1. DataSync (JS naming) [3] 2. SyncPipe(ios naming) [4] I guess we should call them the same and agree on a name. I like to use ?pipe? in the naming just to recall it?s async and going through network. I found DataSync a too generic term which may lead to confusion. This is not the same object that will save data offline and trigger sync. Main differences are: in iOS one I defined a readAll method. Also for save/update I define a third callbacks ?conflict? which take 3 arguments . @summers do you have a gist for java API? thoughts? ++ Corinne [1] http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-sync-To-pipe-or-not-to-pipe-td6135.html [2] https://issues.jboss.org/browse/AEROGEAR-1408 [3] https://gist.github.com/lholmquist/81de9737b5c91367aa3c [4] https://gist.github.com/corinnekrych/8914290 From daniel.bevenius at gmail.com Mon Feb 10 07:41:58 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Mon, 10 Feb 2014 13:41:58 +0100 Subject: [aerogear-dev] Sync Data model Message-ID: Hi, I've done some work on [1] in regards to coming up with a common sync data format for our clients, but I and messed it up [2]. Long story short is that I did not take into account some of client languages features. So here is a new suggestion that will hopefully work with all our client languages: public interface SyncObject { ID objectId(); String revision(); T content(); } What do people think about this? [1] https://issues.jboss.org/browse/AEROGEAR-1406 [2] https://github.com/aerogear/aerogear.org/commit/5e81e5526b5850485eeb83a8ff7ddc1e4d6d2c40 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140210/bcd471a1/attachment.html From aemmanou at redhat.com Mon Feb 10 07:47:48 2014 From: aemmanou at redhat.com (Apostolos Emmanouilidis) Date: Mon, 10 Feb 2014 13:47:48 +0100 Subject: [aerogear-dev] AeroGear on StackOverflow Message-ID: <1392036468.2586.4.camel@dhcp129-205.brq.redhat.com> Hi, I've created a tag and wiki excerpt for AeroGear on StackOverflow [1]. You can edit them and add more info about the project :) -- Tolis [1]: http://stackoverflow.com/tags/aerogear/info From corinnekrych at gmail.com Mon Feb 10 07:51:34 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Mon, 10 Feb 2014 13:51:34 +0100 Subject: [aerogear-dev] Sync Data model In-Reply-To: References: Message-ID: <63F4856A-7D07-4E5F-B947-D42E603AB40B@gmail.com> On 10 Feb 2014, at 13:41, Daniel Bevenius wrote: > Hi, > > I've done some work on [1] in regards to coming up with a common sync data format for our clients, but I and messed it up [2]. Long story short is that I did not take into account some of client languages features. So here is a new suggestion that will hopefully work with all our client languages: > > public interface SyncObject { So this is a new voc proposal to replace Document. +1 on my side > ID objectId(); +1 objectId will work on iOS (better than just id) > String revision(); > T content(); > } > > What do people think about this? > > > [1] https://issues.jboss.org/browse/AEROGEAR-1406 > [2] https://github.com/aerogear/aerogear.org/commit/5e81e5526b5850485eeb83a8ff7ddc1e4d6d2c40 > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From corinnekrych at gmail.com Mon Feb 10 07:56:46 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Mon, 10 Feb 2014 13:56:46 +0100 Subject: [aerogear-dev] Sync Data model In-Reply-To: <63F4856A-7D07-4E5F-B947-D42E603AB40B@gmail.com> References: <63F4856A-7D07-4E5F-B947-D42E603AB40B@gmail.com> Message-ID: <32BE3EB7-C5CC-4600-89EE-FB60E31A2EC8@gmail.com> Here is a new gist [1] Link to the ML discussion [2] ++ Corinne [1] https://gist.github.com/corinnekrych/8915378 [2] http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-DataSync-or-SyncPipe-API-proposal-td6220.html On 10 Feb 2014, at 13:51, Corinne Krych wrote: > > On 10 Feb 2014, at 13:41, Daniel Bevenius wrote: > >> Hi, >> >> I've done some work on [1] in regards to coming up with a common sync data format for our clients, but I and messed it up [2]. Long story short is that I did not take into account some of client languages features. So here is a new suggestion that will hopefully work with all our client languages: >> >> public interface SyncObject { > > So this is a new voc proposal to replace Document. > +1 on my side > >> ID objectId(); > > +1 > objectId will work on iOS (better than just id) > >> String revision(); >> T content(); >> } >> >> What do people think about this? >> >> >> [1] https://issues.jboss.org/browse/AEROGEAR-1406 >> [2] https://github.com/aerogear/aerogear.org/commit/5e81e5526b5850485eeb83a8ff7ddc1e4d6d2c40 >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > From bruno at abstractj.org Mon Feb 10 08:35:43 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Mon, 10 Feb 2014 11:35:43 -0200 Subject: [aerogear-dev] Offline Authentication and friends Message-ID: Good morning peeps, on the last week me and @passos spent most part of the time reading/testing/deleting and struggling with the best approach to provide offline authentication, encrypted cache and friends on AeroGear. This is our initial draft?https://github.com/aerogear/aerogear.org/pull/247 planned to be released with AG Security 1.4.0 if we survive to the global warming. Feedback is welcome.? -- abstractj From lholmqui at redhat.com Mon Feb 10 08:40:34 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Mon, 10 Feb 2014 08:40:34 -0500 Subject: [aerogear-dev] DataSync or SyncPipe API proposal In-Reply-To: <49EB4088-E00E-40F2-A231-E294A8687171@gmail.com> References: <49EB4088-E00E-40F2-A231-E294A8687171@gmail.com> Message-ID: On Feb 10, 2014, at 6:38 AM, Corinne Krych wrote: > Hello Guys, > > Following discussion on ML thread [1], and JIRA discussion [2] (sorry guys I catched up the discussion late, I wasn?t watching the JIRa ticket so i didn?t get notifications) here is the 2 gists we have: > 1. DataSync (JS naming) [3] > 2. SyncPipe(ios naming) [4] > > I guess we should call them the same and agree on a name. I like to use ?pipe? in the naming just to recall it?s async and going through network. I found DataSync a too generic term which may lead to confusion. This is not the same object that will save data offline and trigger sync. > > Main differences are: in iOS one I defined a readAll method. Also for save/update I define a third callbacks ?conflict? which take 3 arguments . in JS the read method can also be "read all", should probably update that gist > > @summers do you have a gist for java API? > thoughts? > > ++ > Corinne > [1] http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-sync-To-pipe-or-not-to-pipe-td6135.html > [2] https://issues.jboss.org/browse/AEROGEAR-1408 > [3] https://gist.github.com/lholmquist/81de9737b5c91367aa3c > [4] https://gist.github.com/corinnekrych/8914290 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From corinnekrych at gmail.com Mon Feb 10 08:44:26 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Mon, 10 Feb 2014 14:44:26 +0100 Subject: [aerogear-dev] DataSync or SyncPipe API proposal In-Reply-To: References: <49EB4088-E00E-40F2-A231-E294A8687171@gmail.com> Message-ID: <7ED4C154-86DB-4E10-9AB0-2232A93F9800@gmail.com> So iOS and JS are at the same level of API fucntionalities and same method names. we?re just left to pick a name DataSync vs SyncPipe Let?s see for the Java version ++ Corinne On 10 Feb 2014, at 14:40, Lucas Holmquist wrote: > > On Feb 10, 2014, at 6:38 AM, Corinne Krych wrote: > >> Hello Guys, >> >> Following discussion on ML thread [1], and JIRA discussion [2] (sorry guys I catched up the discussion late, I wasn?t watching the JIRa ticket so i didn?t get notifications) here is the 2 gists we have: >> 1. DataSync (JS naming) [3] >> 2. SyncPipe(ios naming) [4] >> >> I guess we should call them the same and agree on a name. I like to use ?pipe? in the naming just to recall it?s async and going through network. I found DataSync a too generic term which may lead to confusion. This is not the same object that will save data offline and trigger sync. >> >> Main differences are: in iOS one I defined a readAll method. Also for save/update I define a third callbacks ?conflict? which take 3 arguments . > > in JS the read method can also be "read all", should probably update that gist > >> >> @summers do you have a gist for java API? >> thoughts? >> >> ++ >> Corinne >> [1] http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-sync-To-pipe-or-not-to-pipe-td6135.html >> [2] https://issues.jboss.org/browse/AEROGEAR-1408 >> [3] https://gist.github.com/lholmquist/81de9737b5c91367aa3c >> [4] https://gist.github.com/corinnekrych/8914290 >> _______________________________________________ >> 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 From lholmqui at redhat.com Mon Feb 10 08:46:55 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Mon, 10 Feb 2014 08:46:55 -0500 Subject: [aerogear-dev] DataSync or SyncPipe API proposal In-Reply-To: <7ED4C154-86DB-4E10-9AB0-2232A93F9800@gmail.com> References: <49EB4088-E00E-40F2-A231-E294A8687171@gmail.com> <7ED4C154-86DB-4E10-9AB0-2232A93F9800@gmail.com> Message-ID: <8EB9D831-421D-40B3-97BB-9F6FB1F968A1@redhat.com> On Feb 10, 2014, at 8:44 AM, Corinne Krych wrote: > So iOS and JS are at the same level of API fucntionalities and same method names. > we?re just left to pick a name DataSync vs SyncPipe yea, i wasn't really thrilled with DataSync when i named it that > Let?s see for the Java version > > ++ > Corinne > On 10 Feb 2014, at 14:40, Lucas Holmquist wrote: > >> >> On Feb 10, 2014, at 6:38 AM, Corinne Krych wrote: >> >>> Hello Guys, >>> >>> Following discussion on ML thread [1], and JIRA discussion [2] (sorry guys I catched up the discussion late, I wasn?t watching the JIRa ticket so i didn?t get notifications) here is the 2 gists we have: >>> 1. DataSync (JS naming) [3] >>> 2. SyncPipe(ios naming) [4] >>> >>> I guess we should call them the same and agree on a name. I like to use ?pipe? in the naming just to recall it?s async and going through network. I found DataSync a too generic term which may lead to confusion. This is not the same object that will save data offline and trigger sync. >>> >>> Main differences are: in iOS one I defined a readAll method. Also for save/update I define a third callbacks ?conflict? which take 3 arguments . >> >> in JS the read method can also be "read all", should probably update that gist >> >>> >>> @summers do you have a gist for java API? >>> thoughts? >>> >>> ++ >>> Corinne >>> [1] http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-sync-To-pipe-or-not-to-pipe-td6135.html >>> [2] https://issues.jboss.org/browse/AEROGEAR-1408 >>> [3] https://gist.github.com/lholmquist/81de9737b5c91367aa3c >>> [4] https://gist.github.com/corinnekrych/8914290 >>> _______________________________________________ >>> 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 > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From lholmqui at redhat.com Mon Feb 10 08:23:50 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Mon, 10 Feb 2014 08:23:50 -0500 Subject: [aerogear-dev] [UPS] Proposal to change the Push Message Format In-Reply-To: References: Message-ID: <3AD4DCCE-F0D6-4870-9632-EA3B83720B0A@redhat.com> here is the current format for comparison https://gist.github.com/lholmquist/8915817 +1 to being more structured. one thing though, in the current format, simplePush is not part of the message, but it's own thing On Feb 9, 2014, at 9:06 AM, Sebastien Blanc wrote: > > > > On Sun, Feb 9, 2014 at 2:14 PM, Matthias Wessendorf wrote: > > > > On Sun, Feb 9, 2014 at 12:06 PM, Sebastien Blanc wrote: > Hi, > I was looking at our current Push Message Format[1] and I was wonderimg if you should not add some more structure to it, decoupling config, criterias and the message itself : > > > > { > "config" : { > > "ttl" : 3600, > "content-available" : true, > > > > "simple-push": "version=123" > > }, > "criteria" : { > > "alias" : ["user at account.com", "someone at aerogear.org", ....], > > > > "categories" : ["someCategory", "otherCategory"], > > > > "deviceType" : ["iPad", "AndroidTablet"], > > > > "variants" : ["c3f0a94f-48de-4b77-a08e-68114460857e", "444939cd-ae63-4ce1-96a4-de74b77e3737"] > > > > } > , > "message": { > > "alert":"HELLO!", > > "sound":"default", > > "badge":7, > > "someKey":"some value", > > "anotherCustomKey":"some other value" > > }, > > } > > > wdyt ? > > interesting idea - it looks better structured. > > Regarding "simple-push": "version=123", I'd vote this not to be part of the 'configuration' section, it's the actual message/payload for SP > Right ! here the updated gist https://gist.github.com/sebastienblanc/8897596 > > > -M > > > > Sebi > > > > > [1]http://aerogear.org/docs/specs/aerogear-push-messages/ > > > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140210/24c564cd/attachment.html From scm.blanc at gmail.com Mon Feb 10 09:36:20 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Mon, 10 Feb 2014 15:36:20 +0100 Subject: [aerogear-dev] [UPS] Proposal to change the Push Message Format In-Reply-To: <3AD4DCCE-F0D6-4870-9632-EA3B83720B0A@redhat.com> References: <3AD4DCCE-F0D6-4870-9632-EA3B83720B0A@redhat.com> Message-ID: On Mon, Feb 10, 2014 at 2:23 PM, Lucas Holmquist wrote: > here is the current format for comparison > > https://gist.github.com/lholmquist/8915817 > > +1 to being more structured. > > one thing though, in the current format, simplePush is not part of the > message, but it's own thing > Yeah, that's why I put it in the config section in my first version but Matzew suggested it was more part of the message payload > > On Feb 9, 2014, at 9:06 AM, Sebastien Blanc wrote: > > > > > On Sun, Feb 9, 2014 at 2:14 PM, Matthias Wessendorf wrote: > >> >> >> >> On Sun, Feb 9, 2014 at 12:06 PM, Sebastien Blanc wrote: >> >>> Hi, >>> I was looking at our current Push Message Format[1] and I was wonderimg >>> if you should not add some more structure to it, decoupling config, >>> criterias and the message itself : >>> >>> >>> { >>> "config" : { >>> >>> "ttl" : 3600, >>> "content-available" : true, >>> >>> >>> "simple-push": "version=123" >>> >>> }, >>> "criteria" : { >>> >>> "alias" : ["user at account.com", "someone at aerogear.org", ....], >>> >>> >>> "categories" : ["someCategory", "otherCategory"], >>> >>> >>> "deviceType" : ["iPad", "AndroidTablet"], >>> >>> >>> "variants" : ["c3f0a94f-48de-4b77-a08e-68114460857e", "444939cd-ae63-4ce1-96a4-de74b77e3737"] >>> >>> >>> } >>> , >>> "message": { >>> "alert":"HELLO!", >>> "sound":"default", >>> "badge":7, >>> >>> "someKey":"some value", >>> >>> "anotherCustomKey":"some other value" >>> >>> }, >>> } >>> >>> wdyt ? >>> >>> >> interesting idea - it looks better structured. >> >> Regarding "simple-push": "version=123", I'd vote this not to be part of >> the 'configuration' section, it's the actual message/payload for SP >> > Right ! here the updated gist > https://gist.github.com/sebastienblanc/8897596 > >> >> >> -M >> >> >>> Sebi >>> >>> >>> >>> [1]http://aerogear.org/docs/specs/aerogear-push-messages/ >>> >>> >>> _______________________________________________ >>> 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 > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140210/662b17b0/attachment-0001.html From supittma at redhat.com Mon Feb 10 09:46:17 2014 From: supittma at redhat.com (Summers Pittman) Date: Mon, 10 Feb 2014 09:46:17 -0500 Subject: [aerogear-dev] DataSync or SyncPipe API proposal In-Reply-To: <49EB4088-E00E-40F2-A231-E294A8687171@gmail.com> References: <49EB4088-E00E-40F2-A231-E294A8687171@gmail.com> Message-ID: <52F8E639.7060207@redhat.com> On 02/10/2014 06:38 AM, Corinne Krych wrote: > Hello Guys, > > Following discussion on ML thread [1], and JIRA discussion [2] (sorry guys I catched up the discussion late, I wasn?t watching the JIRa ticket so i didn?t get notifications) here is the 2 gists we have: > 1. DataSync (JS naming) [3] > 2. SyncPipe(ios naming) [4] > > I guess we should call them the same and agree on a name. I like to use ?pipe? in the naming just to recall it?s async and going through network. Not necessarily. Managing revisions and checking two documents for conflicts Shouldn't require network usage. > I found DataSync a too generic term which may lead to confusion. This is not the same object that will save data offline and trigger sync. Right. This is basically an inspection into the state of sync offering two items of information 1) Is there a new document on the server 2) Does replacing the synced document with a revised document generate a conflict and it offers a convenience function a) Update this documents revision. If there is a conflict tell me. Managing the client<-> Server connection is outside of the object (and can be delegated to a Pipe) > > Main differences are: in iOS one I defined a readAll method. Also for save/update I define a third callbacks ?conflict? which take 3 arguments . > > @summers do you have a gist for java API? I took a completely different approach a long time ago to this. My idea was there is an object which does the thing I just described and you register listeners on it for it to callback to. https://github.com/aerogear/aerogear-android/blob/sync_strawman/src/org/jboss/aerogear/android/sync/Synchronizer.java and https://github.com/aerogear/aerogear-android/blob/sync_strawman/src/org/jboss/aerogear/android/sync/SynchronizeEventListener.java Obviously this is slightly out of date, but I havn't really been satisfied with the proposals so far. They feel too imperative and developer driven. I'm not really sure how they will fit when we expand them into something which can be automated by the underlying system. > thoughts? > > ++ > Corinne > [1] http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-sync-To-pipe-or-not-to-pipe-td6135.html > [2] https://issues.jboss.org/browse/AEROGEAR-1408 > [3] https://gist.github.com/lholmquist/81de9737b5c91367aa3c > [4] https://gist.github.com/corinnekrych/8914290 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From daniel at passos.me Mon Feb 10 09:47:06 2014 From: daniel at passos.me (Daniel Passos) Date: Mon, 10 Feb 2014 12:47:06 -0200 Subject: [aerogear-dev] Backend (jax-rs) Project In-Reply-To: <996ACE2C-F429-4224-9E3D-E9836DFEB0DD@gmail.com> References: <996ACE2C-F429-4224-9E3D-E9836DFEB0DD@gmail.com> Message-ID: fyi Have added the push endpoint[1] and a clean interface[2] to send message from server. The cookbook app was updated[3] to use it [1]?https://github.com/danielpassos/aerogear-integration-tests-server#push [2]?https://www.dropbox.com/sh/on2cqcogbqmadjg/rTk-ILpYM2 [3]?https://github.com/danielpassos/aerogear-android-cookbook/tree/new-server-endpoint --? Daniel Passos On January 20, 2014 at 4:54:00 PM, Christos Vasilakis (cvasilak at gmail.com) wrote: fyi have added multipart upload support endpoint that simply echo backs(json) the request and in the case of ?file? parts ?just the file file size of each. I am Planning to use on our ig-tests and cookbook [1]?https://github.com/danielpassos/aerogear-integration-tests-server/pull/1 Regards - Christos On Jan 14, 2014, at 3:20 PM, Daniel Passos wrote: Hi folks, I started a new backend project[1] using jax-rs. The idea of this project is provide some endpoints to use in the demos, integration tests and cookbooks. I have tried to fix and add new features to the old project[2], but the legacy is big and hard to fix I created a jira for it[3]. Feel free to add (and take) new sub tasks and send PRs [1]?https://github.com/danielpassos/aerogear-integration-tests-server [2]?https://github.com/aerogear/aerogear-jaxrs-demo? [3]?https://issues.jboss.org/browse/AEROGEAR-1388 --? Daniel Passos _______________________________________________ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140210/9298b88d/attachment.html From supittma at redhat.com Mon Feb 10 09:48:26 2014 From: supittma at redhat.com (Summers Pittman) Date: Mon, 10 Feb 2014 09:48:26 -0500 Subject: [aerogear-dev] DataSync or SyncPipe API proposal In-Reply-To: <8EB9D831-421D-40B3-97BB-9F6FB1F968A1@redhat.com> References: <49EB4088-E00E-40F2-A231-E294A8687171@gmail.com> <7ED4C154-86DB-4E10-9AB0-2232A93F9800@gmail.com> <8EB9D831-421D-40B3-97BB-9F6FB1F968A1@redhat.com> Message-ID: <52F8E6BA.1030408@redhat.com> On 02/10/2014 08:46 AM, Lucas Holmquist wrote: > On Feb 10, 2014, at 8:44 AM, Corinne Krych wrote: > >> So iOS and JS are at the same level of API fucntionalities and same method names. >> we?re just left to pick a name DataSync vs SyncPipe > yea, i wasn't really thrilled with DataSync when i named it that Because it isn't Sync. It is VersionControl >> Let?s see for the Java version >> >> ++ >> Corinne >> On 10 Feb 2014, at 14:40, Lucas Holmquist wrote: >> >>> On Feb 10, 2014, at 6:38 AM, Corinne Krych wrote: >>> >>>> Hello Guys, >>>> >>>> Following discussion on ML thread [1], and JIRA discussion [2] (sorry guys I catched up the discussion late, I wasn?t watching the JIRa ticket so i didn?t get notifications) here is the 2 gists we have: >>>> 1. DataSync (JS naming) [3] >>>> 2. SyncPipe(ios naming) [4] >>>> >>>> I guess we should call them the same and agree on a name. I like to use ?pipe? in the naming just to recall it?s async and going through network. I found DataSync a too generic term which may lead to confusion. This is not the same object that will save data offline and trigger sync. >>>> >>>> Main differences are: in iOS one I defined a readAll method. Also for save/update I define a third callbacks ?conflict? which take 3 arguments . >>> in JS the read method can also be "read all", should probably update that gist >>> >>>> @summers do you have a gist for java API? >>>> thoughts? >>>> >>>> ++ >>>> Corinne >>>> [1] http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-sync-To-pipe-or-not-to-pipe-td6135.html >>>> [2] https://issues.jboss.org/browse/AEROGEAR-1408 >>>> [3] https://gist.github.com/lholmquist/81de9737b5c91367aa3c >>>> [4] https://gist.github.com/corinnekrych/8914290 >>>> _______________________________________________ >>>> 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 >> >> _______________________________________________ >> 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 From supittma at redhat.com Mon Feb 10 09:49:50 2014 From: supittma at redhat.com (Summers Pittman) Date: Mon, 10 Feb 2014 09:49:50 -0500 Subject: [aerogear-dev] Sync Data model In-Reply-To: References: Message-ID: <52F8E70E.6000802@redhat.com> On 02/10/2014 07:41 AM, Daniel Bevenius wrote: > Hi, > > I've done some work on [1] in regards to coming up with a common sync > data format for our clients, but I and messed it up [2]. Long story > short is that I did not take into account some of client languages > features. So here is a new suggestion that will hopefully work with > all our client languages: > > public interface SyncObject { > ID objectId(); > String revision(); > T content(); > } > What do people think about this? One of the things I'm wondering about is, in the far far future when our code is told we have the server push^H^H^H^H asynchronously notifying the device of data changes, how will Java know what type the data coming in is? It MAY be useful to have a name space feature in the message. > > > [1] https://issues.jboss.org/browse/AEROGEAR-1406 > [2] > https://github.com/aerogear/aerogear.org/commit/5e81e5526b5850485eeb83a8ff7ddc1e4d6d2c40 > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140210/cdbd27aa/attachment.html From corinnekrych at gmail.com Mon Feb 10 10:06:01 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Mon, 10 Feb 2014 16:06:01 +0100 Subject: [aerogear-dev] Sync Data model In-Reply-To: <52F8E70E.6000802@redhat.com> References: <52F8E70E.6000802@redhat.com> Message-ID: On 10 Feb 2014, at 15:49, Summers Pittman wrote: > On 02/10/2014 07:41 AM, Daniel Bevenius wrote: >> Hi, >> >> I've done some work on [1] in regards to coming up with a common sync data format for our clients, but I and messed it up [2]. Long story short is that I did not take into account some of client languages features. So here is a new suggestion that will hopefully work with all our client languages: >> >> public interface SyncObject { >> ID objectId(); >> String revision(); >> T content(); >> } >> What do people think about this? > One of the things I'm wondering about is, in the far far future in the far far future we?ll review the API. 2.0. I?ll rather to stick to what we need for M1/M2 to start with... > when our code is told we have the server push^H^H^H^H asynchronously notifying the device of data changes, how will Java know what type the data coming in is? It MAY be useful to have a name space feature in the message. >> >> >> [1] https://issues.jboss.org/browse/AEROGEAR-1406 >> [2] https://github.com/aerogear/aerogear.org/commit/5e81e5526b5850485eeb83a8ff7ddc1e4d6d2c40 >> >> >> >> _______________________________________________ >> 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 From supittma at redhat.com Mon Feb 10 10:09:04 2014 From: supittma at redhat.com (Summers Pittman) Date: Mon, 10 Feb 2014 10:09:04 -0500 Subject: [aerogear-dev] Sync Data model In-Reply-To: References: <52F8E70E.6000802@redhat.com> Message-ID: <52F8EB90.2020209@redhat.com> On 02/10/2014 10:06 AM, Corinne Krych wrote: > On 10 Feb 2014, at 15:49, Summers Pittman wrote: > >> On 02/10/2014 07:41 AM, Daniel Bevenius wrote: >>> Hi, >>> >>> I've done some work on [1] in regards to coming up with a common sync data format for our clients, but I and messed it up [2]. Long story short is that I did not take into account some of client languages features. So here is a new suggestion that will hopefully work with all our client languages: >>> >>> public interface SyncObject { >>> ID objectId(); >>> String revision(); >>> T content(); >>> } >>> What do people think about this? >> One of the things I'm wondering about is, in the far far future > in the far far future we?ll review the API. 2.0. > > I?ll rather to stick to what we need for M1/M2 to start with... https://issues.jboss.org/browse/AEROGEAR-1409 ^^ The future which is the second epic in the list. > > >> when our code is told we have the server push^H^H^H^H asynchronously notifying the device of data changes, how will Java know what type the data coming in is? It MAY be useful to have a name space feature in the message. > > >>> >>> [1] https://issues.jboss.org/browse/AEROGEAR-1406 >>> [2] https://github.com/aerogear/aerogear.org/commit/5e81e5526b5850485eeb83a8ff7ddc1e4d6d2c40 >>> >>> >>> >>> _______________________________________________ >>> 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 > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From lholmqui at redhat.com Mon Feb 10 10:24:58 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Mon, 10 Feb 2014 10:24:58 -0500 Subject: [aerogear-dev] DataSync or SyncPipe API proposal In-Reply-To: <52F8E6BA.1030408@redhat.com> References: <49EB4088-E00E-40F2-A231-E294A8687171@gmail.com> <7ED4C154-86DB-4E10-9AB0-2232A93F9800@gmail.com> <8EB9D831-421D-40B3-97BB-9F6FB1F968A1@redhat.com> <52F8E6BA.1030408@redhat.com> Message-ID: On Feb 10, 2014, at 9:48 AM, Summers Pittman wrote: > On 02/10/2014 08:46 AM, Lucas Holmquist wrote: >> On Feb 10, 2014, at 8:44 AM, Corinne Krych wrote: >> >>> So iOS and JS are at the same level of API fucntionalities and same method names. >>> we?re just left to pick a name DataSync vs SyncPipe >> yea, i wasn't really thrilled with DataSync when i named it that > Because it isn't Sync. It is VersionControl exactly, Then perhaps we should be calling this first set of Milestones, Version Control client API instead of Data Sync >>> Let?s see for the Java version >>> >>> ++ >>> Corinne >>> On 10 Feb 2014, at 14:40, Lucas Holmquist wrote: >>> >>>> On Feb 10, 2014, at 6:38 AM, Corinne Krych wrote: >>>> >>>>> Hello Guys, >>>>> >>>>> Following discussion on ML thread [1], and JIRA discussion [2] (sorry guys I catched up the discussion late, I wasn?t watching the JIRa ticket so i didn?t get notifications) here is the 2 gists we have: >>>>> 1. DataSync (JS naming) [3] >>>>> 2. SyncPipe(ios naming) [4] >>>>> >>>>> I guess we should call them the same and agree on a name. I like to use ?pipe? in the naming just to recall it?s async and going through network. I found DataSync a too generic term which may lead to confusion. This is not the same object that will save data offline and trigger sync. >>>>> >>>>> Main differences are: in iOS one I defined a readAll method. Also for save/update I define a third callbacks ?conflict? which take 3 arguments . >>>> in JS the read method can also be "read all", should probably update that gist >>>> >>>>> @summers do you have a gist for java API? >>>>> thoughts? >>>>> >>>>> ++ >>>>> Corinne >>>>> [1] http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-sync-To-pipe-or-not-to-pipe-td6135.html >>>>> [2] https://issues.jboss.org/browse/AEROGEAR-1408 >>>>> [3] https://gist.github.com/lholmquist/81de9737b5c91367aa3c >>>>> [4] https://gist.github.com/corinnekrych/8914290 >>>>> _______________________________________________ >>>>> 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 >>> >>> _______________________________________________ >>> 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 > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From corinnekrych at gmail.com Mon Feb 10 10:37:59 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Mon, 10 Feb 2014 16:37:59 +0100 Subject: [aerogear-dev] Sync Data model In-Reply-To: <52F8EB90.2020209@redhat.com> References: <52F8E70E.6000802@redhat.com> <52F8EB90.2020209@redhat.com> Message-ID: On 10 Feb 2014, at 16:09, Summers Pittman wrote: > On 02/10/2014 10:06 AM, Corinne Krych wrote: >> On 10 Feb 2014, at 15:49, Summers Pittman wrote: >> >>> On 02/10/2014 07:41 AM, Daniel Bevenius wrote: >>>> Hi, >>>> >>>> I've done some work on [1] in regards to coming up with a common sync data format for our clients, but I and messed it up [2]. Long story short is that I did not take into account some of client languages features. So here is a new suggestion that will hopefully work with all our client languages: >>>> >>>> public interface SyncObject { >>>> ID objectId(); >>>> String revision(); >>>> T content(); >>>> } >>>> What do people think about this? >>> One of the things I'm wondering about is, in the far far future >> in the far far future we?ll review the API. 2.0. >> >> I?ll rather to stick to what we need for M1/M2 to start with... > https://issues.jboss.org/browse/AEROGEAR-1409 > > ^^ The future which is the second epic in the list. Here i?ll use 'set reconciliation problem? vocabulary rather than synchronisation, it?s when we get data from others. Could we put the namespace in the configuration of the ReconciliationObject? like we did for pipe or store. >> >> >>> when our code is told we have the server push^H^H^H^H asynchronously notifying the device of data changes, how will Java know what type the data coming in is? It MAY be useful to have a name space feature in the message. >> >> >>>> >>>> [1] https://issues.jboss.org/browse/AEROGEAR-1406 >>>> [2] https://github.com/aerogear/aerogear.org/commit/5e81e5526b5850485eeb83a8ff7ddc1e4d6d2c40 >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 >> >> _______________________________________________ >> 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 From corinnekrych at gmail.com Mon Feb 10 10:41:51 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Mon, 10 Feb 2014 16:41:51 +0100 Subject: [aerogear-dev] DataSync or SyncPipe API proposal In-Reply-To: References: <49EB4088-E00E-40F2-A231-E294A8687171@gmail.com> <7ED4C154-86DB-4E10-9AB0-2232A93F9800@gmail.com> <8EB9D831-421D-40B3-97BB-9F6FB1F968A1@redhat.com> <52F8E6BA.1030408@redhat.com> Message-ID: <9323CFD7-059A-44AF-B35C-F1F422B34438@gmail.com> On 10 Feb 2014, at 16:24, Lucas Holmquist wrote: > > On Feb 10, 2014, at 9:48 AM, Summers Pittman wrote: > >> On 02/10/2014 08:46 AM, Lucas Holmquist wrote: >>> On Feb 10, 2014, at 8:44 AM, Corinne Krych wrote: >>> >>>> So iOS and JS are at the same level of API fucntionalities and same method names. >>>> we?re just left to pick a name DataSync vs SyncPipe >>> yea, i wasn't really thrilled with DataSync when i named it that >> Because it isn't Sync. It is VersionControl > exactly, Then perhaps we should be calling this first set of Milestones, Version Control client API instead of Data Sync > +1 Conflict Detection to be more precise. > >>>> Let?s see for the Java version >>>> >>>> ++ >>>> Corinne >>>> On 10 Feb 2014, at 14:40, Lucas Holmquist wrote: >>>> >>>>> On Feb 10, 2014, at 6:38 AM, Corinne Krych wrote: >>>>> >>>>>> Hello Guys, >>>>>> >>>>>> Following discussion on ML thread [1], and JIRA discussion [2] (sorry guys I catched up the discussion late, I wasn?t watching the JIRa ticket so i didn?t get notifications) here is the 2 gists we have: >>>>>> 1. DataSync (JS naming) [3] >>>>>> 2. SyncPipe(ios naming) [4] >>>>>> >>>>>> I guess we should call them the same and agree on a name. I like to use ?pipe? in the naming just to recall it?s async and going through network. I found DataSync a too generic term which may lead to confusion. This is not the same object that will save data offline and trigger sync. >>>>>> >>>>>> Main differences are: in iOS one I defined a readAll method. Also for save/update I define a third callbacks ?conflict? which take 3 arguments . >>>>> in JS the read method can also be "read all", should probably update that gist >>>>> >>>>>> @summers do you have a gist for java API? >>>>>> thoughts? >>>>>> >>>>>> ++ >>>>>> Corinne >>>>>> [1] http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-sync-To-pipe-or-not-to-pipe-td6135.html >>>>>> [2] https://issues.jboss.org/browse/AEROGEAR-1408 >>>>>> [3] https://gist.github.com/lholmquist/81de9737b5c91367aa3c >>>>>> [4] https://gist.github.com/corinnekrych/8914290 >>>>>> _______________________________________________ >>>>>> 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 >>>> >>>> _______________________________________________ >>>> 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 >> >> _______________________________________________ >> 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 From supittma at redhat.com Mon Feb 10 10:26:51 2014 From: supittma at redhat.com (Summers Pittman) Date: Mon, 10 Feb 2014 10:26:51 -0500 Subject: [aerogear-dev] DataSync or SyncPipe API proposal In-Reply-To: References: <49EB4088-E00E-40F2-A231-E294A8687171@gmail.com> <7ED4C154-86DB-4E10-9AB0-2232A93F9800@gmail.com> <8EB9D831-421D-40B3-97BB-9F6FB1F968A1@redhat.com> <52F8E6BA.1030408@redhat.com> Message-ID: <52F8EFBB.7050605@redhat.com> On 02/10/2014 10:24 AM, Lucas Holmquist wrote: > On Feb 10, 2014, at 9:48 AM, Summers Pittman wrote: > >> On 02/10/2014 08:46 AM, Lucas Holmquist wrote: >>> On Feb 10, 2014, at 8:44 AM, Corinne Krych wrote: >>> >>>> So iOS and JS are at the same level of API fucntionalities and same method names. >>>> we?re just left to pick a name DataSync vs SyncPipe >>> yea, i wasn't really thrilled with DataSync when i named it that >> Because it isn't Sync. It is VersionControl > exactly, Then perhaps we should be calling this first set of Milestones, Version Control client API instead of Data Sync +1 > > >>>> Let?s see for the Java version >>>> >>>> ++ >>>> Corinne >>>> On 10 Feb 2014, at 14:40, Lucas Holmquist wrote: >>>> >>>>> On Feb 10, 2014, at 6:38 AM, Corinne Krych wrote: >>>>> >>>>>> Hello Guys, >>>>>> >>>>>> Following discussion on ML thread [1], and JIRA discussion [2] (sorry guys I catched up the discussion late, I wasn?t watching the JIRa ticket so i didn?t get notifications) here is the 2 gists we have: >>>>>> 1. DataSync (JS naming) [3] >>>>>> 2. SyncPipe(ios naming) [4] >>>>>> >>>>>> I guess we should call them the same and agree on a name. I like to use ?pipe? in the naming just to recall it?s async and going through network. I found DataSync a too generic term which may lead to confusion. This is not the same object that will save data offline and trigger sync. >>>>>> >>>>>> Main differences are: in iOS one I defined a readAll method. Also for save/update I define a third callbacks ?conflict? which take 3 arguments . >>>>> in JS the read method can also be "read all", should probably update that gist >>>>> >>>>>> @summers do you have a gist for java API? >>>>>> thoughts? >>>>>> >>>>>> ++ >>>>>> Corinne >>>>>> [1] http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-sync-To-pipe-or-not-to-pipe-td6135.html >>>>>> [2] https://issues.jboss.org/browse/AEROGEAR-1408 >>>>>> [3] https://gist.github.com/lholmquist/81de9737b5c91367aa3c >>>>>> [4] https://gist.github.com/corinnekrych/8914290 >>>>>> _______________________________________________ >>>>>> 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 >>>> _______________________________________________ >>>> 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 >> _______________________________________________ >> 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 From matzew at apache.org Mon Feb 10 10:46:05 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 10 Feb 2014 16:46:05 +0100 Subject: [aerogear-dev] [UPS] Proposal to change the Push Message Format In-Reply-To: References: <3AD4DCCE-F0D6-4870-9632-EA3B83720B0A@redhat.com> Message-ID: On Monday, February 10, 2014, Sebastien Blanc wrote: > > > > On Mon, Feb 10, 2014 at 2:23 PM, Lucas Holmquist > > wrote: > >> here is the current format for comparison >> >> https://gist.github.com/lholmquist/8915817 >> >> +1 to being more structured. >> >> one thing though, in the current format, simplePush is not part of the >> message, but it's own thing >> > Yeah, that's why I put it in the config section in my first version but > Matzew suggested it was more part of the message payload > Nope to config; should stay its own, does not (IMO) make sense to include in tve message for richer platforms like Android/iOS > > On Feb 9, 2014, at 9:06 AM, Sebastien Blanc wrote: > > > > > On Sun, Feb 9, 2014 at 2:14 PM, Matthias Wessendorf wrote: > > > > > On Sun, Feb 9, 2014 at 12:06 PM, Sebastien Blanc wrote: > > Hi, > I was looking at our current Push Message Format[1] and I was wonderimg if > you should not add some more structure to it, decoupling config, criterias > and the message itself : > > > { > "config" : { > > "ttl" : 3600, > "content-available" : true, > > > > "simple-push": "version=123" > > }, > "criteria" : { > > "alias" : ["user at account.com", "someone at aerogear.org", ....], > > > > "categories" : ["someCategory", "otherCategory"], > > > > "deviceType" : ["iPad", "AndroidTablet"], > > > > "variants" : ["c3f0a94f-48de-4b77-a08e-68114460857e", "444939cd-ae63-4ce1-96a4-de74b77e3737"] > > > > } > , > "message": { > "alert":"HELLO!", > "sound":"default", > "badge":7, > > "someKey":"some value", > > "anotherCustomKey":"some other value" > > }, > } > > wdyt ? > > > interesting idea - it looks better structured. > > Re > > > -- Sent from Gmail Mobile -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140210/098a09ef/attachment-0001.html From corinnekrych at gmail.com Mon Feb 10 10:47:21 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Mon, 10 Feb 2014 16:47:21 +0100 Subject: [aerogear-dev] DataSync or SyncPipe API proposal In-Reply-To: <52F8E639.7060207@redhat.com> References: <49EB4088-E00E-40F2-A231-E294A8687171@gmail.com> <52F8E639.7060207@redhat.com> Message-ID: <7461BF44-902F-4B25-8AC2-3A1C2AA1BAB4@gmail.com> On 10 Feb 2014, at 15:46, Summers Pittman wrote: > On 02/10/2014 06:38 AM, Corinne Krych wrote: >> Hello Guys, >> >> Following discussion on ML thread [1], and JIRA discussion [2] (sorry guys I catched up the discussion late, I wasn?t watching the JIRa ticket so i didn?t get notifications) here is the 2 gists we have: >> 1. DataSync (JS naming) [3] >> 2. SyncPipe(ios naming) [4] >> >> I guess we should call them the same and agree on a name. I like to use ?pipe? in the naming just to recall it?s async and going through network. > Not necessarily. Managing revisions and checking two documents for > conflicts Shouldn't require network usage. >> I found DataSync a too generic term which may lead to confusion. This is not the same object that will save data offline and trigger sync. > Right. This is basically an inspection into the state of sync offering > two items of information > 1) Is there a new document on the server > 2) Does replacing the synced document with a revised document generate a > conflict > > and it offers a convenience function > a) Update this documents revision. If there is a conflict tell me. > > Managing the client<-> Server connection is outside of the object (and > can be delegated to a Pipe) oki @summers : Where is your SyncPipe/DataSync/ConflictMgr/VersionControlMgr in https://github.com/aerogear/aerogear-android/tree/sync_strawman/src/org/jboss/aerogear/android/sync ? > >> >> Main differences are: in iOS one I defined a readAll method. Also for save/update I define a third callbacks ?conflict? which take 3 arguments . >> >> @summers do you have a gist for java API? > I took a completely different approach a long time ago to this. My idea > was there is an object which does the thing I just described and you > register listeners on it for it to callback to. > > https://github.com/aerogear/aerogear-android/blob/sync_strawman/src/org/jboss/aerogear/android/sync/Synchronizer.java > and > https://github.com/aerogear/aerogear-android/blob/sync_strawman/src/org/jboss/aerogear/android/sync/SynchronizeEventListener.java > > Obviously this is slightly out of date, but I havn't really been > satisfied with the proposals so far. They feel too imperative and > developer driven. I'm not really sure how they will fit when we expand > them into something which can be automated by the underlying system. >> thoughts? >> >> ++ >> Corinne >> [1] http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-sync-To-pipe-or-not-to-pipe-td6135.html >> [2] https://issues.jboss.org/browse/AEROGEAR-1408 >> [3] https://gist.github.com/lholmquist/81de9737b5c91367aa3c >> [4] https://gist.github.com/corinnekrych/8914290 >> _______________________________________________ >> 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 From supittma at redhat.com Mon Feb 10 11:31:11 2014 From: supittma at redhat.com (Summers Pittman) Date: Mon, 10 Feb 2014 11:31:11 -0500 Subject: [aerogear-dev] DataSync or SyncPipe API proposal In-Reply-To: <7461BF44-902F-4B25-8AC2-3A1C2AA1BAB4@gmail.com> References: <49EB4088-E00E-40F2-A231-E294A8687171@gmail.com> <52F8E639.7060207@redhat.com> <7461BF44-902F-4B25-8AC2-3A1C2AA1BAB4@gmail.com> Message-ID: <52F8FECF.9020101@redhat.com> On 02/10/2014 10:47 AM, Corinne Krych wrote: > On 10 Feb 2014, at 15:46, Summers Pittman wrote: > >> On 02/10/2014 06:38 AM, Corinne Krych wrote: >>> Hello Guys, >>> >>> Following discussion on ML thread [1], and JIRA discussion [2] (sorry guys I catched up the discussion late, I wasn?t watching the JIRa ticket so i didn?t get notifications) here is the 2 gists we have: >>> 1. DataSync (JS naming) [3] >>> 2. SyncPipe(ios naming) [4] >>> >>> I guess we should call them the same and agree on a name. I like to use ?pipe? in the naming just to recall it?s async and going through network. >> Not necessarily. Managing revisions and checking two documents for >> conflicts Shouldn't require network usage. >>> I found DataSync a too generic term which may lead to confusion. This is not the same object that will save data offline and trigger sync. >> Right. This is basically an inspection into the state of sync offering >> two items of information >> 1) Is there a new document on the server >> 2) Does replacing the synced document with a revised document generate a >> conflict >> >> and it offers a convenience function >> a) Update this documents revision. If there is a conflict tell me. >> >> Managing the client<-> Server connection is outside of the object (and >> can be delegated to a Pipe) > oki > @summers : Where is your SyncPipe/DataSync/ConflictMgr/VersionControlMgr in > https://github.com/aerogear/aerogear-android/tree/sync_strawman/src/org/jboss/aerogear/android/sync ? That is the Synchronizer interface. As I said, this was done BEFORE we had any of these concepts (even at this stage) and reflects a FUNDAMENTALLY DIFFERENT idea of how sync should work. Also I tossed up up months ago and people really didn't comment on it (other than to say this is where we would like to end up). > > >>> Main differences are: in iOS one I defined a readAll method. Also for save/update I define a third callbacks ?conflict? which take 3 arguments . >>> >>> @summers do you have a gist for java API? >> I took a completely different approach a long time ago to this. My idea >> was there is an object which does the thing I just described and you >> register listeners on it for it to callback to. >> >> https://github.com/aerogear/aerogear-android/blob/sync_strawman/src/org/jboss/aerogear/android/sync/Synchronizer.java >> and >> https://github.com/aerogear/aerogear-android/blob/sync_strawman/src/org/jboss/aerogear/android/sync/SynchronizeEventListener.java >> >> Obviously this is slightly out of date, but I havn't really been >> satisfied with the proposals so far. They feel too imperative and >> developer driven. I'm not really sure how they will fit when we expand >> them into something which can be automated by the underlying system. >>> thoughts? >>> >>> ++ >>> Corinne >>> [1] http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-sync-To-pipe-or-not-to-pipe-td6135.html >>> [2] https://issues.jboss.org/browse/AEROGEAR-1408 >>> [3] https://gist.github.com/lholmquist/81de9737b5c91367aa3c >>> [4] https://gist.github.com/corinnekrych/8914290 >>> _______________________________________________ >>> 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 > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From supittma at redhat.com Mon Feb 10 11:33:30 2014 From: supittma at redhat.com (Summers Pittman) Date: Mon, 10 Feb 2014 11:33:30 -0500 Subject: [aerogear-dev] DataSync or SyncPipe API proposal In-Reply-To: <52F8FECF.9020101@redhat.com> References: <49EB4088-E00E-40F2-A231-E294A8687171@gmail.com> <52F8E639.7060207@redhat.com> <7461BF44-902F-4B25-8AC2-3A1C2AA1BAB4@gmail.com> <52F8FECF.9020101@redhat.com> Message-ID: <52F8FF5A.9050602@redhat.com> On 02/10/2014 11:31 AM, Summers Pittman wrote: > On 02/10/2014 10:47 AM, Corinne Krych wrote: >> On 10 Feb 2014, at 15:46, Summers Pittman wrote: >> >>> On 02/10/2014 06:38 AM, Corinne Krych wrote: >>>> Hello Guys, >>>> >>>> Following discussion on ML thread [1], and JIRA discussion [2] (sorry guys I catched up the discussion late, I wasn?t watching the JIRa ticket so i didn?t get notifications) here is the 2 gists we have: >>>> 1. DataSync (JS naming) [3] >>>> 2. SyncPipe(ios naming) [4] >>>> >>>> I guess we should call them the same and agree on a name. I like to use ?pipe? in the naming just to recall it?s async and going through network. >>> Not necessarily. Managing revisions and checking two documents for >>> conflicts Shouldn't require network usage. >>>> I found DataSync a too generic term which may lead to confusion. This is not the same object that will save data offline and trigger sync. >>> Right. This is basically an inspection into the state of sync offering >>> two items of information >>> 1) Is there a new document on the server >>> 2) Does replacing the synced document with a revised document generate a >>> conflict >>> >>> and it offers a convenience function >>> a) Update this documents revision. If there is a conflict tell me. >>> >>> Managing the client<-> Server connection is outside of the object (and >>> can be delegated to a Pipe) >> oki >> @summers : Where is your SyncPipe/DataSync/ConflictMgr/VersionControlMgr in >> https://github.com/aerogear/aerogear-android/tree/sync_strawman/src/org/jboss/aerogear/android/sync ? > That is the Synchronizer interface. > > As I said, this was done BEFORE we had any of these concepts (even at > this stage) and reflects a FUNDAMENTALLY DIFFERENT idea of how sync > should work. > > Also I tossed up up months ago and people really didn't comment on it > (other than to say this is where we would like to end up). However to actually answer your question. loadRemoteChanges() is responsible for checking the server for changes, and detecting if the data we have would generate a conflict. sync() pushes our changes to the server and checks the response for conflicts. This methods execute asynchronously and send their results to Listeners. >> >>>> Main differences are: in iOS one I defined a readAll method. Also for save/update I define a third callbacks ?conflict? which take 3 arguments . >>>> >>>> @summers do you have a gist for java API? >>> I took a completely different approach a long time ago to this. My idea >>> was there is an object which does the thing I just described and you >>> register listeners on it for it to callback to. >>> >>> https://github.com/aerogear/aerogear-android/blob/sync_strawman/src/org/jboss/aerogear/android/sync/Synchronizer.java >>> and >>> https://github.com/aerogear/aerogear-android/blob/sync_strawman/src/org/jboss/aerogear/android/sync/SynchronizeEventListener.java >>> >>> Obviously this is slightly out of date, but I havn't really been >>> satisfied with the proposals so far. They feel too imperative and >>> developer driven. I'm not really sure how they will fit when we expand >>> them into something which can be automated by the underlying system. >>>> thoughts? >>>> >>>> ++ >>>> Corinne >>>> [1] http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-sync-To-pipe-or-not-to-pipe-td6135.html >>>> [2] https://issues.jboss.org/browse/AEROGEAR-1408 >>>> [3] https://gist.github.com/lholmquist/81de9737b5c91367aa3c >>>> [4] https://gist.github.com/corinnekrych/8914290 >>>> _______________________________________________ >>>> 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 >> _______________________________________________ >> 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 From cvasilak at gmail.com Mon Feb 10 12:55:29 2014 From: cvasilak at gmail.com (Christos Vasilakis) Date: Mon, 10 Feb 2014 19:55:29 +0200 Subject: [aerogear-dev] Team meeting agenda for today In-Reply-To: References: Message-ID: fyi meeting minutes: jbott: Meeting ended Mon Feb 10 15:07:22 2014 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) [5:18pm] jbott: Minutes: http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-02-10-14.50.html [5:18pm] jbott: Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-02-10-14.50.txt [5:18pm] jbott: Log: http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-02-10-14.50.log.html On Mon, Feb 10, 2014 at 11:02 AM, Bruno Oliveira wrote: > http://oksoclap.com/p/UemilzzAVV > > -- > abstractj > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140210/773b4bcd/attachment.html From cvasilak at gmail.com Tue Feb 11 06:31:30 2014 From: cvasilak at gmail.com (Christos Vasilakis) Date: Tue, 11 Feb 2014 13:31:30 +0200 Subject: [aerogear-dev] Updating crypto dependency Message-ID: Hi team, aerogear-crypto latest version v0.2, requires iOS 7 and later and aerogear-ios has a dependency for. Currently, for aerogear-ios updating to iOS 7 is scheduled fro the 1.5 frame so it makes sense for the upcoming 1.4 release of the aerogear-ios library to leave the dependency for crypto in 0.1 Internally, the crypto functionality used by aerogear-ios (symmetric encryption) hasn?t been changed in the 0.2 which was focused more on asymmetric and digital signatures, so staying in 0.1 makes sense (for now). wdyth? Thanks, Christos From bruno at abstractj.org Tue Feb 11 06:33:44 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Tue, 11 Feb 2014 09:33:44 -0200 Subject: [aerogear-dev] Updating crypto dependency In-Reply-To: References: Message-ID: Do we have a date for 1.5? -- abstractj On February 11, 2014 at 9:31:43 AM, Christos Vasilakis (cvasilak at gmail.com) wrote: > > Hi team, > > aerogear-crypto latest version v0.2, requires iOS 7 and later > and aerogear-ios has a dependency for. Currently, for aerogear-ios > updating to iOS 7 is scheduled fro the 1.5 frame so it makes sense > for the upcoming 1.4 release of the aerogear-ios library to leave > the dependency for crypto in 0.1 > > Internally, the crypto functionality used by aerogear-ios > (symmetric encryption) hasn?t been changed in the 0.2 which > was focused more on asymmetric and digital signatures, so staying > in 0.1 makes sense (for now). > > wdyth? From cvasilak at gmail.com Tue Feb 11 07:06:24 2014 From: cvasilak at gmail.com (Christos Vasilakis) Date: Tue, 11 Feb 2014 14:06:24 +0200 Subject: [aerogear-dev] Updating crypto dependency In-Reply-To: References: Message-ID: <678862A7-C3D0-4C35-A78D-BE6F2C817D23@gmail.com> On Feb 11, 2014, at 1:33 PM, Bruno Oliveira wrote: > Do we have a date for 1.5? not sure yet Bruno, best-effort plan is mid-March but exact dates needs to be discussed. as Matthias pointed in a previous email [1], prior to sync work, we can have an interim release 1.5 with the upgrades to iOS 7 and AFNetworking to 2.x (which will include the crypto lib update) let us know your thought and concern. Thanks, Christos [1] http://lists.jboss.org/pipermail/aerogear-dev/2014-January/005732.html > > -- > abstractj > > On February 11, 2014 at 9:31:43 AM, Christos Vasilakis (cvasilak at gmail.com) wrote: >>> Hi team, >> >> aerogear-crypto latest version v0.2, requires iOS 7 and later >> and aerogear-ios has a dependency for. Currently, for aerogear-ios >> updating to iOS 7 is scheduled fro the 1.5 frame so it makes sense >> for the upcoming 1.4 release of the aerogear-ios library to leave >> the dependency for crypto in 0.1 >> >> Internally, the crypto functionality used by aerogear-ios >> (symmetric encryption) hasn?t been changed in the 0.2 which >> was focused more on asymmetric and digital signatures, so staying >> in 0.1 makes sense (for now). >> >> wdyth? > From bruno at abstractj.org Tue Feb 11 07:15:43 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Tue, 11 Feb 2014 10:15:43 -0200 Subject: [aerogear-dev] Updating crypto dependency In-Reply-To: <678862A7-C3D0-4C35-A78D-BE6F2C817D23@gmail.com> References: <678862A7-C3D0-4C35-A78D-BE6F2C817D23@gmail.com> Message-ID: Sounds good, no concerns here. -- abstractj On February 11, 2014 at 10:06:41 AM, Christos Vasilakis (cvasilak at gmail.com) wrote: > > not sure yet Bruno, best-effort plan is mid-March but exact > dates needs to be discussed. > > as Matthias pointed in a previous email [1], prior to sync work, > we can have an interim release 1.5 with the upgrades to iOS 7 and > AFNetworking to 2.x (which will include the crypto lib update) > > let us know your thought and concern. > > Thanks, > Christos From corinnekrych at gmail.com Tue Feb 11 07:55:22 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Tue, 11 Feb 2014 13:55:22 +0100 Subject: [aerogear-dev] aerogear.org revamp: where to fit in platform example page? Message-ID: Hello Hylke, We already discussed it in this thread [1], but I rather have the question in its own dedicated thread. Atm, the mockup defines 3 pages/layers: HOME, GET IT, and EXMAPLE page. I think we're missing a PLATFORM EXAMPLE page. This page wil explain in more details with the user prefered platform how to deal with AG Core Pipe etc... Idally this page will have a github cookbook repo assiciated to it. We have cookbook for the 3 plaforms: android, iOS, JS so far and we also have demo repo. A crossrefence table like this one [2] could also be useful. An example page with high level concept and definition illustrated with code snippet is good. But not enough. Besides, atm we have an extensive documentation that goes in much more details and i really think we should keep this level of details. My question is: How do me transition from EXAMPLE to PALTFORM EXAMPLE? Does it make sense to you? wdyt? Last time I did a hackengarten on AeroGear, people told me: Woah, you've got such a great documentation, explaining step by step. And I told them wait until we've got our killer revamp ;) ++ Corinne [1] http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Fwd-Website-restructure-td5837.html [2] https://github.com/aerogear/aerogear-ios-cookbook/blob/master/README.md -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140211/69c57bcc/attachment.html From scm.blanc at gmail.com Tue Feb 11 13:15:18 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Tue, 11 Feb 2014 19:15:18 +0100 Subject: [aerogear-dev] Differences between Firefox OS "native" Push lib and AeroGear's Push adapter In-Reply-To: References: Message-ID: Ok, I've been doing some tests by using the PushEndpoint as device token. For registration it works but I just faced an issue by trying to unregister because the URL for the DELETE looks like : https://judconpush-sblanc.rhcloud.com/rest/registry/device/https://updates.push.services.mozilla.com/update/my_personnal_psuhendpoint_id[ And the REST endpoint get a bit crazy by the extra "/" present in the endpoint URL. Therefore, I think we must just use the last URL fragment as deviceToken. On Thu, Feb 6, 2014 at 3:27 PM, Matthias Wessendorf wrote: > > > > On Thu, Feb 6, 2014 at 3:11 PM, Sebastien Blanc wrote: > >> >> >> >> On Thu, Feb 6, 2014 at 12:28 PM, Matthias Wessendorf wrote: >> >>> >>> >>> >>> On Wed, Feb 5, 2014 at 11:52 PM, Matthias Wessendorf wrote: >>> >>>> >>>> >>>> >>>> On Wed, Feb 5, 2014 at 11:22 PM, Sebastien Blanc wrote: >>>> >>>>> Hi, >>>>> While playing today with my Firefox Device and its native Simple Push >>>>> support I noticed some differences between our implementation and the >>>>> native Push regarding the success callback after a register : >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> //Native FFOS Push >>>>> broadcastRequest = navigator.push.register(); >>>>> broadcastRequest.onsuccess = function (event) { >>>>> broadcastEndpoint = broadcastRequest.result; // only contains the pushURL >>>>> } >>>>> >>>>> >>>>> //Aerogear Push Adapter >>>>> broadcastRequest = navigator.push.register(); >>>>> broadcastRequest.onsuccess = function (event) { >>>>> broadcastEndpoint = broadcastRequest.result.pushEndpoint; >>>>> channelID = broadcastRequest.result.channelID; >>>>> version = broadcastRequest.result.version; >>>>> status = broadcastRequest.result.status >>>>> } >>>>> >>>>> So, the AeroGear Push exposes much more in the callback that it should >>>>> suppose to do : just exposing the pushEndpoint. >>>>> >>>>> The reason we do that I suppose, but Luke or Kris could confirm that, >>>>> is that we thought respecting the SPS protocol, which indeed returns a >>>>> whole object containing all the info. It is just that the Native Push >>>>> Client API filter that out in the callback response. >>>>> >>>> >>>> >>>> Did they change that recently? Or was theirs always like it is now ? >>>> >>>> >>>> >>>>> After discussing that on the #push channel with the Mozilla people >>>>> they confirmed me that we should only expoe the pushEndpoint. >>>>> >>>> >>>> >>>> yep, I agree on changing our JS polyfil >>>> >>>> >>>> >>>>> >>>>> If we keep it as is, this can be problematic when we want to use the >>>>> same code both for native and with the adapter when, for instance, >>>>> registering to the UPS : >>>>> >>>>> broadcastRequest = navigator.push.register(); >>>>> broadcastRequest.onsuccess = function (event) { >>>>> broadcastEndpoint = event.target.result; >>>>> var broadCastSettings = { >>>>> metadata: { >>>>> deviceToken: broadcastEndpoint.channelID, >>>>> simplePushEndpoint: broadcastEndpoint.pushEndpoint >>>>> } >>>>> } >>>>> UPClient.registerWithPushServer(broadCastSettings); >>>>> } >>>>> >>>>> >>>>> >>>>> This won't work with the native push since "broadcastEndpoint.channelID" >>>>> will be undefined. >>>>> >>>> >>>> sweet :-) >>>> >>>> >>>>> >>>>> So I propose that we change the behaviour, to return only the >>>>> pushEndpoint in the callback, even if that means a bit of String >>>>> manipulation when we want to perform the registration to the UPS : >>>>> >>>>> var broadCastSettings = { >>>>> metadata: { >>>>> deviceToken: broadcastEndpoint.substr(broadcastEndpoint.lastIndexOf('/') + 1), >>>>> simplePushEndpoint: broadcastEndpoint >>>>> } >>>>> } >>>>> >>>>> >>>>> >>>> well, that's not really good for security reasons, since their looooong >>>> 'substring' was done for that. Also that's just redundant. >>>> >>>> The I guess, the deviceToken (channelID registration) might be a bit >>>> bogus, for SimplePush. Let me think about it.... >>>> >>> >>> >>> Right now we use the channelID as the deviceToken, but we should not >>> really 'leak' the channelID (see [1]), so I guess the here proposed change >>> makes sense. Don't recall exactly why we did it in the past, but yeah - >>> let's change it. >>> >>> >>> Thinking about the consequence: I think we should use store the value of >>> the returned 'pushEndpoint' string as our device-token. At the end the >>> device-token is really the thing that identifies a device w/in the target >>> network. Apple/Google uses a unique string, and if Mozilla uses a URL, >>> that's totally fine. >>> >>> Reading the protocol definitions (see [1]) for the 'endpoint' I think it >>> is fair to use that (unique) URL string as the device-token; And we could >>> use this token value as well for the unregister calls, instead of the >>> channelIDs. >>> >> >> After reading your comment on the PR >> https://github.com/aerogear/aerogear-js/pull/105#issuecomment-34324732 I >> understand that you just want to use the deviceToken and not pass the >> simplePushEndpoint to UPS anymore, is that right ? >> > > > yep > > > > > > > > >> >>> >>> Any thoughts ? >>> >>> >>> -Matthias >>> >>> [1] https://wiki.mozilla.org/WebAPI/SimplePush/Protocol#Definitions >>> >>> >>> >>> >>>> >>>> That said, we still have no clue how to proper clean-up 'out dated' >>>> channels, since the SimplePush Server/Protocol is silent on that (unlike >>>> APNs / GCM). but that's really a different thread (yep, we have a future >>>> JIRA for that) >>>> >>>> >>>> -M >>>> >>>> >>>> >>>>> wdyt ? >>>>> >>>>> Seb >>>>> >>>>> >>>>> ps : our SPS Server implementation stays correct and returns what >>>>> should be returned, it's really just the client part and how we expose the >>>>> result >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>>> >>> >>> >>> >>> -- >>> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140211/8ef6106f/attachment-0001.html From scm.blanc at gmail.com Wed Feb 12 03:53:33 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Wed, 12 Feb 2014 09:53:33 +0100 Subject: [aerogear-dev] Differences between Firefox OS "native" Push lib and AeroGear's Push adapter In-Reply-To: References: Message-ID: On Tue, Feb 11, 2014 at 7:15 PM, Sebastien Blanc wrote: > Ok, > I've been doing some tests by using the PushEndpoint as device token. For > registration it works but I just faced an issue by trying to unregister > because the URL for the DELETE looks like : > > > https://judconpush-sblanc.rhcloud.com/rest/registry/device/https://updates.push.services.mozilla.com/update/my_personnal_psuhendpoint_id[ > > And the REST endpoint get a bit crazy by the extra "/" present in the > endpoint URL. Therefore, I think we must just use the last URL fragment as > deviceToken. > Ok answering to myself ;) That won't work neither since if we do that UPS won't have the compllete push endpoint URL. So how do we deal with that ? > > > On Thu, Feb 6, 2014 at 3:27 PM, Matthias Wessendorf wrote: > >> >> >> >> On Thu, Feb 6, 2014 at 3:11 PM, Sebastien Blanc wrote: >> >>> >>> >>> >>> On Thu, Feb 6, 2014 at 12:28 PM, Matthias Wessendorf wrote: >>> >>>> >>>> >>>> >>>> On Wed, Feb 5, 2014 at 11:52 PM, Matthias Wessendorf >>> > wrote: >>>> >>>>> >>>>> >>>>> >>>>> On Wed, Feb 5, 2014 at 11:22 PM, Sebastien Blanc wrote: >>>>> >>>>>> Hi, >>>>>> While playing today with my Firefox Device and its native Simple Push >>>>>> support I noticed some differences between our implementation and the >>>>>> native Push regarding the success callback after a register : >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> //Native FFOS Push >>>>>> broadcastRequest = navigator.push.register(); >>>>>> broadcastRequest.onsuccess = function (event) { >>>>>> broadcastEndpoint = broadcastRequest.result; // only contains the pushURL >>>>>> } >>>>>> >>>>>> >>>>>> //Aerogear Push Adapter >>>>>> broadcastRequest = navigator.push.register(); >>>>>> broadcastRequest.onsuccess = function (event) { >>>>>> broadcastEndpoint = broadcastRequest.result.pushEndpoint; >>>>>> channelID = broadcastRequest.result.channelID; >>>>>> version = broadcastRequest.result.version; >>>>>> status = broadcastRequest.result.status >>>>>> } >>>>>> >>>>>> So, the AeroGear Push exposes much more in the callback that it >>>>>> should suppose to do : just exposing the pushEndpoint. >>>>>> >>>>>> The reason we do that I suppose, but Luke or Kris could confirm that, >>>>>> is that we thought respecting the SPS protocol, which indeed returns a >>>>>> whole object containing all the info. It is just that the Native Push >>>>>> Client API filter that out in the callback response. >>>>>> >>>>> >>>>> >>>>> Did they change that recently? Or was theirs always like it is now ? >>>>> >>>>> >>>>> >>>>>> After discussing that on the #push channel with the Mozilla people >>>>>> they confirmed me that we should only expoe the pushEndpoint. >>>>>> >>>>> >>>>> >>>>> yep, I agree on changing our JS polyfil >>>>> >>>>> >>>>> >>>>>> >>>>>> If we keep it as is, this can be problematic when we want to use the >>>>>> same code both for native and with the adapter when, for instance, >>>>>> registering to the UPS : >>>>>> >>>>>> broadcastRequest = navigator.push.register(); >>>>>> broadcastRequest.onsuccess = function (event) { >>>>>> broadcastEndpoint = event.target.result; >>>>>> var broadCastSettings = { >>>>>> metadata: { >>>>>> deviceToken: broadcastEndpoint.channelID, >>>>>> simplePushEndpoint: broadcastEndpoint.pushEndpoint >>>>>> } >>>>>> } >>>>>> UPClient.registerWithPushServer(broadCastSettings); >>>>>> } >>>>>> >>>>>> >>>>>> >>>>>> This won't work with the native push since "broadcastEndpoint.channelID" >>>>>> will be undefined. >>>>>> >>>>> >>>>> sweet :-) >>>>> >>>>> >>>>>> >>>>>> So I propose that we change the behaviour, to return only the >>>>>> pushEndpoint in the callback, even if that means a bit of String >>>>>> manipulation when we want to perform the registration to the UPS : >>>>>> >>>>>> var broadCastSettings = { >>>>>> metadata: { >>>>>> deviceToken: broadcastEndpoint.substr(broadcastEndpoint.lastIndexOf('/') + 1), >>>>>> simplePushEndpoint: broadcastEndpoint >>>>>> } >>>>>> } >>>>>> >>>>>> >>>>>> >>>>> well, that's not really good for security reasons, since their >>>>> looooong 'substring' was done for that. Also that's just redundant. >>>>> >>>>> The I guess, the deviceToken (channelID registration) might be a bit >>>>> bogus, for SimplePush. Let me think about it.... >>>>> >>>> >>>> >>>> Right now we use the channelID as the deviceToken, but we should not >>>> really 'leak' the channelID (see [1]), so I guess the here proposed change >>>> makes sense. Don't recall exactly why we did it in the past, but yeah - >>>> let's change it. >>>> >>>> >>>> Thinking about the consequence: I think we should use store the value >>>> of the returned 'pushEndpoint' string as our device-token. At the end the >>>> device-token is really the thing that identifies a device w/in the target >>>> network. Apple/Google uses a unique string, and if Mozilla uses a URL, >>>> that's totally fine. >>>> >>>> Reading the protocol definitions (see [1]) for the 'endpoint' I think >>>> it is fair to use that (unique) URL string as the device-token; And we >>>> could use this token value as well for the unregister calls, instead of the >>>> channelIDs. >>>> >>> >>> After reading your comment on the PR >>> https://github.com/aerogear/aerogear-js/pull/105#issuecomment-34324732I understand that you just want to use the deviceToken and not pass the >>> simplePushEndpoint to UPS anymore, is that right ? >>> >> >> >> yep >> >> >> >> >> >> >> >> >>> >>>> >>>> Any thoughts ? >>>> >>>> >>>> -Matthias >>>> >>>> [1] https://wiki.mozilla.org/WebAPI/SimplePush/Protocol#Definitions >>>> >>>> >>>> >>>> >>>>> >>>>> That said, we still have no clue how to proper clean-up 'out dated' >>>>> channels, since the SimplePush Server/Protocol is silent on that (unlike >>>>> APNs / GCM). but that's really a different thread (yep, we have a future >>>>> JIRA for that) >>>>> >>>>> >>>>> -M >>>>> >>>>> >>>>> >>>>>> wdyt ? >>>>>> >>>>>> Seb >>>>>> >>>>>> >>>>>> ps : our SPS Server implementation stays correct and returns what >>>>>> should be returned, it's really just the client part and how we expose the >>>>>> result >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>>> >>>> >>>> >>>> >>>> -- >>>> 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 >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140212/c4da885f/attachment-0001.html From lholmqui at redhat.com Wed Feb 12 08:30:07 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Wed, 12 Feb 2014 08:30:07 -0500 Subject: [aerogear-dev] Differences between Firefox OS "native" Push lib and AeroGear's Push adapter In-Reply-To: References: Message-ID: <9B70BDB9-4774-4BF0-9FF7-5213185E4F52@redhat.com> i might have a couple thoughts, but i need to try some things out first On Feb 12, 2014, at 3:53 AM, Sebastien Blanc wrote: > > > > On Tue, Feb 11, 2014 at 7:15 PM, Sebastien Blanc wrote: > Ok, > I've been doing some tests by using the PushEndpoint as device token. For registration it works but I just faced an issue by trying to unregister because the URL for the DELETE looks like : > > https://judconpush-sblanc.rhcloud.com/rest/registry/device/https://updates.push.services.mozilla.com/update/my_personnal_psuhendpoint_id [ > > And the REST endpoint get a bit crazy by the extra "/" present in the endpoint URL. Therefore, I think we must just use the last URL fragment as deviceToken. > > Ok answering to myself ;) That won't work neither since if we do that UPS won't have the compllete push endpoint URL. > So how do we deal with that ? > > > On Thu, Feb 6, 2014 at 3:27 PM, Matthias Wessendorf wrote: > > > > On Thu, Feb 6, 2014 at 3:11 PM, Sebastien Blanc wrote: > > > > On Thu, Feb 6, 2014 at 12:28 PM, Matthias Wessendorf wrote: > > > > On Wed, Feb 5, 2014 at 11:52 PM, Matthias Wessendorf wrote: > > > > On Wed, Feb 5, 2014 at 11:22 PM, Sebastien Blanc wrote: > Hi, > While playing today with my Firefox Device and its native Simple Push support I noticed some differences between our implementation and the native Push regarding the success callback after a register : > > > > > > > > > > > //Native FFOS Push > broadcastRequest = navigator.push.register(); > broadcastRequest.onsuccess = function (event) { > broadcastEndpoint = broadcastRequest.result; // only contains the pushURL > } > > > //Aerogear Push Adapter > broadcastRequest = navigator.push.register(); > broadcastRequest.onsuccess = function (event) { > broadcastEndpoint = broadcastRequest.result.pushEndpoint; > channelID = broadcastRequest.result.channelID; > version = broadcastRequest.result.version; > status = broadcastRequest.result.status > } > So, the AeroGear Push exposes much more in the callback that it should suppose to do : just exposing the pushEndpoint. > > The reason we do that I suppose, but Luke or Kris could confirm that, is that we thought respecting the SPS protocol, which indeed returns a whole object containing all the info. It is just that the Native Push Client API filter that out in the callback response. > > > Did they change that recently? Or was theirs always like it is now ? > > > After discussing that on the #push channel with the Mozilla people they confirmed me that we should only expoe the pushEndpoint. > > > yep, I agree on changing our JS polyfil > > > > If we keep it as is, this can be problematic when we want to use the same code both for native and with the adapter when, for instance, registering to the UPS : > > broadcastRequest = navigator.push.register(); > broadcastRequest.onsuccess = function (event) { > broadcastEndpoint = event.target.result; > var broadCastSettings = { > metadata: { > deviceToken: broadcastEndpoint.channelID, > simplePushEndpoint: broadcastEndpoint.pushEndpoint > } > } > UPClient.registerWithPushServer(broadCastSettings); > } > > > This won't work with the native push since "broadcastEndpoint.channelID" will be undefined. > > sweet :-) > > > So I propose that we change the behaviour, to return only the pushEndpoint in the callback, even if that means a bit of String manipulation when we want to perform the registration to the UPS : > > var broadCastSettings = { > metadata: { > deviceToken: broadcastEndpoint.substr(broadcastEndpoint.lastIndexOf('/') + 1), > simplePushEndpoint: broadcastEndpoint > } > } > > > well, that's not really good for security reasons, since their looooong 'substring' was done for that. Also that's just redundant. > > The I guess, the deviceToken (channelID registration) might be a bit bogus, for SimplePush. Let me think about it.... > > > Right now we use the channelID as the deviceToken, but we should not really 'leak' the channelID (see [1]), so I guess the here proposed change makes sense. Don't recall exactly why we did it in the past, but yeah - let's change it. > > > Thinking about the consequence: I think we should use store the value of the returned 'pushEndpoint' string as our device-token. At the end the device-token is really the thing that identifies a device w/in the target network. Apple/Google uses a unique string, and if Mozilla uses a URL, that's totally fine. > > Reading the protocol definitions (see [1]) for the 'endpoint' I think it is fair to use that (unique) URL string as the device-token; And we could use this token value as well for the unregister calls, instead of the channelIDs. > > After reading your comment on the PR https://github.com/aerogear/aerogear-js/pull/105#issuecomment-34324732 I understand that you just want to use the deviceToken and not pass the simplePushEndpoint to UPS anymore, is that right ? > > > yep > > > > > > > > > > Any thoughts ? > > > -Matthias > > [1] https://wiki.mozilla.org/WebAPI/SimplePush/Protocol#Definitions > > > > > That said, we still have no clue how to proper clean-up 'out dated' channels, since the SimplePush Server/Protocol is silent on that (unlike APNs / GCM). but that's really a different thread (yep, we have a future JIRA for that) > > > -M > > > wdyt ? > > Seb > > > ps : our SPS Server implementation stays correct and returns what should be returned, it's really just the client part and how we expose the result > > > _______________________________________________ > 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 > > > > -- > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140212/e28da738/attachment-0001.html From bruno at abstractj.org Wed Feb 12 09:15:41 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Wed, 12 Feb 2014 12:15:41 -0200 Subject: [aerogear-dev] Passphrase protection proposal and UPS Message-ID: Good morning, over the weekend I was thinking about how to protect the way how the passphrases are provided in UPS (https://issues.jboss.org/browse/AGPUSH-358) and would like to propose some changes, but before moving forward let's validate if what I am saying makes sense. **Note**: Matthias already started some thread about it (http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Question-around-encryption-for-iOS-push-certificate-passphrase-td6174.html). But I didn't get the chance to look UPS and have a decent answer. I would like to hear what do you think to start to file Jiras or change the proposal. URL:?https://gist.github.com/abstractj/4c6cd242584f4ab406aa # Passphrase protection and friends ## Current scenario - At the moment passphrases and certificates are protected with *HTTPS*, but we also have *CRIME*, *BEAST* and friends. - From the *UPS* dictionary (http://aerogear.org/docs/specs/aerogear-server-push/) I understand a Variant as an application (Android, iPhone....) - From the usage scenarios, I understand that's possible to send messages to a group of devices. *Ex*: Bruno sends "ahoy" to 3 different variants. - Currently the passphrase is stored in plaintext Reading the sources from *UPS* and the whole documentation I could clearly understand that what do we need might be the same thing being developed for offline, a key management server. I think this must be a separated project to everyone benefit of it. ## What is the whole idea? The idea is kinda of simple, but must be validated to check how it meet your needs, each developer with access on the server side will have her own key pair generated and encoded in binary format.? ![](http://photon.abstractj.org/keymgmt_20140212_113030_20140212_113032.jpg) ### Some considerations - The key pair will be generated in a separated project, not on UPS - For the key store I'm considering to support the same data stores provided by SPS. What Dan did is a nice a idea (https://github.com/aerogear/aerogear-simplepush-server/tree/master/datastores) - For each key pair will be generated a self signed certificated encoded in DER format and stored into the database (http://en.wikipedia.org/wiki/X.509) - The key pair will be unique per user, like GPG does.? - We only provide a public key for encryption after successful authentication into the system ## Changes suggested on UPS server 1. Login endpoint - Current login endpoint: ? ? ? ?POST /rest/auth/login ? ? - Suggested change: I'm not sure if we really need **POST** for login, unless we are changing the state of some resource GET /rest/auth/login Response: {public-key: } 2. Register push app - Our push clients will need to change to accept the public key provided by the server and encrypt the passphrase. We can make use of *AG Crypto* for it - The basic workflow for our clients would be: - Send a login request - Get the public key - Encrypt the passphrase - Send a request like we do at the moment - For non *AG UPS* clients like *cURL*, the steps with *OpenSSL* will be provided. I also consider the possibility of use GPG as alternative, but something to be tested and evaluated.? ## Future - Generate a key pair on the client side to sign our HTTP requests - Generate the keys per session (http://en.wikipedia.org/wiki/Ephemeral_key) ? -- abstractj From matzew at apache.org Wed Feb 12 10:56:33 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 12 Feb 2014 16:56:33 +0100 Subject: [aerogear-dev] Differences between Firefox OS "native" Push lib and AeroGear's Push adapter In-Reply-To: <9B70BDB9-4774-4BF0-9FF7-5213185E4F52@redhat.com> References: <9B70BDB9-4774-4BF0-9FF7-5213185E4F52@redhat.com> Message-ID: What about using the encodeURIComponent() function ? On Wed, Feb 12, 2014 at 2:30 PM, Lucas Holmquist wrote: > i might have a couple thoughts, but i need to try some things out first > > On Feb 12, 2014, at 3:53 AM, Sebastien Blanc wrote: > > > > > On Tue, Feb 11, 2014 at 7:15 PM, Sebastien Blanc wrote: > >> Ok, >> I've been doing some tests by using the PushEndpoint as device token. For >> registration it works but I just faced an issue by trying to unregister >> because the URL for the DELETE looks like : >> >> >> https://judconpush-sblanc.rhcloud.com/rest/registry/device/https://updates.push.services.mozilla.com/update/my_personnal_psuhendpoint_id[ >> >> And the REST endpoint get a bit crazy by the extra "/" present in the >> endpoint URL. Therefore, I think we must just use the last URL fragment as >> deviceToken. >> > > Ok answering to myself ;) That won't work neither since if we do that UPS > won't have the compllete push endpoint URL. > So how do we deal with that ? > >> >> >> On Thu, Feb 6, 2014 at 3:27 PM, Matthias Wessendorf wrote: >> >>> >>> >>> >>> On Thu, Feb 6, 2014 at 3:11 PM, Sebastien Blanc wrote: >>> >>>> >>>> >>>> >>>> On Thu, Feb 6, 2014 at 12:28 PM, Matthias Wessendorf >>> > wrote: >>>> >>>>> >>>>> >>>>> >>>>> On Wed, Feb 5, 2014 at 11:52 PM, Matthias Wessendorf < >>>>> matzew at apache.org> wrote: >>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Wed, Feb 5, 2014 at 11:22 PM, Sebastien Blanc >>>>> > wrote: >>>>>> >>>>>>> Hi, >>>>>>> While playing today with my Firefox Device and its native Simple >>>>>>> Push support I noticed some differences between our implementation and the >>>>>>> native Push regarding the success callback after a register : >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> //Native FFOS Push >>>>>>> broadcastRequest = navigator.push.register(); >>>>>>> broadcastRequest.onsuccess = function (event) { >>>>>>> broadcastEndpoint = broadcastRequest.result; // only contains the pushURL >>>>>>> } >>>>>>> >>>>>>> >>>>>>> //Aerogear Push Adapter >>>>>>> broadcastRequest = navigator.push.register(); >>>>>>> broadcastRequest.onsuccess = function (event) { >>>>>>> broadcastEndpoint = broadcastRequest.result.pushEndpoint; >>>>>>> channelID = broadcastRequest.result.channelID; >>>>>>> version = broadcastRequest.result.version; >>>>>>> status = broadcastRequest.result.status >>>>>>> } >>>>>>> >>>>>>> So, the AeroGear Push exposes much more in the callback that it >>>>>>> should suppose to do : just exposing the pushEndpoint. >>>>>>> >>>>>>> The reason we do that I suppose, but Luke or Kris could confirm >>>>>>> that, is that we thought respecting the SPS protocol, which indeed returns >>>>>>> a whole object containing all the info. It is just that the Native Push >>>>>>> Client API filter that out in the callback response. >>>>>>> >>>>>> >>>>>> >>>>>> Did they change that recently? Or was theirs always like it is now ? >>>>>> >>>>>> >>>>>> >>>>>>> After discussing that on the #push channel with the Mozilla people >>>>>>> they confirmed me that we should only expoe the pushEndpoint. >>>>>>> >>>>>> >>>>>> >>>>>> yep, I agree on changing our JS polyfil >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> If we keep it as is, this can be problematic when we want to use the >>>>>>> same code both for native and with the adapter when, for instance, >>>>>>> registering to the UPS : >>>>>>> >>>>>>> broadcastRequest = navigator.push.register(); >>>>>>> broadcastRequest.onsuccess = function (event) { >>>>>>> broadcastEndpoint = event.target.result; >>>>>>> var broadCastSettings = { >>>>>>> metadata: { >>>>>>> deviceToken: broadcastEndpoint.channelID, >>>>>>> simplePushEndpoint: broadcastEndpoint.pushEndpoint >>>>>>> } >>>>>>> } >>>>>>> UPClient.registerWithPushServer(broadCastSettings); >>>>>>> } >>>>>>> >>>>>>> >>>>>>> >>>>>>> This won't work with the native push since "broadcastEndpoint.channelID" >>>>>>> will be undefined. >>>>>>> >>>>>> >>>>>> sweet :-) >>>>>> >>>>>> >>>>>>> >>>>>>> So I propose that we change the behaviour, to return only the >>>>>>> pushEndpoint in the callback, even if that means a bit of String >>>>>>> manipulation when we want to perform the registration to the UPS : >>>>>>> >>>>>>> var broadCastSettings = { >>>>>>> metadata: { >>>>>>> deviceToken: broadcastEndpoint.substr(broadcastEndpoint.lastIndexOf('/') + 1), >>>>>>> simplePushEndpoint: broadcastEndpoint >>>>>>> } >>>>>>> } >>>>>>> >>>>>>> >>>>>>> >>>>>> well, that's not really good for security reasons, since their >>>>>> looooong 'substring' was done for that. Also that's just redundant. >>>>>> >>>>>> The I guess, the deviceToken (channelID registration) might be a bit >>>>>> bogus, for SimplePush. Let me think about it.... >>>>>> >>>>> >>>>> >>>>> Right now we use the channelID as the deviceToken, but we should not >>>>> really 'leak' the channelID (see [1]), so I guess the here proposed change >>>>> makes sense. Don't recall exactly why we did it in the past, but yeah - >>>>> let's change it. >>>>> >>>>> >>>>> Thinking about the consequence: I think we should use store the value >>>>> of the returned 'pushEndpoint' string as our device-token. At the end the >>>>> device-token is really the thing that identifies a device w/in the target >>>>> network. Apple/Google uses a unique string, and if Mozilla uses a URL, >>>>> that's totally fine. >>>>> >>>>> Reading the protocol definitions (see [1]) for the 'endpoint' I think >>>>> it is fair to use that (unique) URL string as the device-token; And we >>>>> could use this token value as well for the unregister calls, instead of the >>>>> channelIDs. >>>>> >>>> >>>> After reading your comment on the PR >>>> https://github.com/aerogear/aerogear-js/pull/105#issuecomment-34324732I understand that you just want to use the deviceToken and not pass the >>>> simplePushEndpoint to UPS anymore, is that right ? >>>> >>> >>> >>> yep >>> >>> >>> >>> >>> >>> >>> >>> >>>> >>>>> >>>>> Any thoughts ? >>>>> >>>>> >>>>> -Matthias >>>>> >>>>> [1] https://wiki.mozilla.org/WebAPI/SimplePush/Protocol#Definitions >>>>> >>>>> >>>>> >>>>> >>>>>> >>>>>> That said, we still have no clue how to proper clean-up 'out dated' >>>>>> channels, since the SimplePush Server/Protocol is silent on that (unlike >>>>>> APNs / GCM). but that's really a different thread (yep, we have a future >>>>>> JIRA for that) >>>>>> >>>>>> >>>>>> -M >>>>>> >>>>>> >>>>>> >>>>>>> wdyt ? >>>>>>> >>>>>>> Seb >>>>>>> >>>>>>> >>>>>>> ps : our SPS Server implementation stays correct and returns what >>>>>>> should be returned, it's really just the client part and how we expose the >>>>>>> result >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> 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 > > > > _______________________________________________ > 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/20140212/33679064/attachment-0001.html From matzew at apache.org Wed Feb 12 11:19:15 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 12 Feb 2014 17:19:15 +0100 Subject: [aerogear-dev] [UnifiedPush] Time for a release? Message-ID: Hello, I'd like to release the next version of UPS (0.10.0), we covered a lot of items since our last release ([1]). However, there are some open PRs ([2] and [3]) around the user-management work that Sebi did, with help of Bruno. As we have been discussing on different threads (e.g. [4]), we started looking at Keycloak and it also offers the facility for user management as well. I'd like to get the Keycloak integration as the primary goal for the next release, beides fixes and other potential features (e.g. around security). That said, but IMO this kind makes the PRs around user-management redundant. Especially since in [2] we filed a bunch of new JIRAs to cover/fix issues and weak design etc. I'd really like to skip the user-mangement PR (see [2]). We might want to keep the branch - just in case, but I'd really like to see this not landing, especially as we are already looking towards keycloak integration. Any thoughts ? -Matthias [1] https://issues.jboss.org/browse/AGPUSH/fixforversion/12321876 [2] https://github.com/aerogear/aerogear-unifiedpush-server/pull/118 [3] https://github.com/aerogear/aerogear-unifiedpush-server/pull/123 [4] http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Keycloak-on-AeroGear-td5663.html -- 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/20140212/ee036399/attachment.html From scm.blanc at gmail.com Wed Feb 12 11:45:04 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Wed, 12 Feb 2014 17:45:04 +0100 Subject: [aerogear-dev] [UnifiedPush] Time for a release? In-Reply-To: References: Message-ID: +1 On Wed, Feb 12, 2014 at 5:19 PM, Matthias Wessendorf wrote: > Hello, > > I'd like to release the next version of UPS (0.10.0), we covered a lot of > items since our last release ([1]). > > However, there are some open PRs ([2] and [3]) around the user-management > work that Sebi did, with help of Bruno. As we have been discussing on > different threads (e.g. [4]), we started looking at Keycloak and it also > offers the facility for user management as well. > > I'd like to get the Keycloak integration as the primary goal for the next > release, beides fixes and other potential features (e.g. around security). > That said, but IMO this kind makes the PRs around user-management > redundant. Especially since in [2] we filed a bunch of new JIRAs to > cover/fix issues and weak design etc. > > I'd really like to skip the user-mangement PR (see [2]). We might want to > keep the branch - just in case, but I'd really like to see this not > landing, especially as we are already looking towards keycloak integration. > > > Any thoughts ? > > -Matthias > > > [1] https://issues.jboss.org/browse/AGPUSH/fixforversion/12321876 > [2] https://github.com/aerogear/aerogear-unifiedpush-server/pull/118 > [3] https://github.com/aerogear/aerogear-unifiedpush-server/pull/123 > [4] > http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Keycloak-on-AeroGear-td5663.html > > > > -- > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140212/521047ec/attachment.html From scm.blanc at gmail.com Wed Feb 12 11:47:34 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Wed, 12 Feb 2014 17:47:34 +0100 Subject: [aerogear-dev] Differences between Firefox OS "native" Push lib and AeroGear's Push adapter In-Reply-To: References: <9B70BDB9-4774-4BF0-9FF7-5213185E4F52@redhat.com> Message-ID: On Wed, Feb 12, 2014 at 4:56 PM, Matthias Wessendorf wrote: > What about using the encodeURIComponent() function ? > Ah yes :) that would be the best solution , and using URLDecoder on the other (UPS server) side ? > > > On Wed, Feb 12, 2014 at 2:30 PM, Lucas Holmquist wrote: > >> i might have a couple thoughts, but i need to try some things out first >> >> On Feb 12, 2014, at 3:53 AM, Sebastien Blanc wrote: >> >> >> >> >> On Tue, Feb 11, 2014 at 7:15 PM, Sebastien Blanc wrote: >> >>> Ok, >>> I've been doing some tests by using the PushEndpoint as device token. >>> For registration it works but I just faced an issue by trying to unregister >>> because the URL for the DELETE looks like : >>> >>> >>> https://judconpush-sblanc.rhcloud.com/rest/registry/device/https://updates.push.services.mozilla.com/update/my_personnal_psuhendpoint_id[ >>> >>> And the REST endpoint get a bit crazy by the extra "/" present in the >>> endpoint URL. Therefore, I think we must just use the last URL fragment as >>> deviceToken. >>> >> >> Ok answering to myself ;) That won't work neither since if we do that UPS >> won't have the compllete push endpoint URL. >> So how do we deal with that ? >> >>> >>> >>> On Thu, Feb 6, 2014 at 3:27 PM, Matthias Wessendorf wrote: >>> >>>> >>>> >>>> >>>> On Thu, Feb 6, 2014 at 3:11 PM, Sebastien Blanc wrote: >>>> >>>>> >>>>> >>>>> >>>>> On Thu, Feb 6, 2014 at 12:28 PM, Matthias Wessendorf < >>>>> matzew at apache.org> wrote: >>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Wed, Feb 5, 2014 at 11:52 PM, Matthias Wessendorf < >>>>>> matzew at apache.org> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Wed, Feb 5, 2014 at 11:22 PM, Sebastien Blanc < >>>>>>> scm.blanc at gmail.com> wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> While playing today with my Firefox Device and its native Simple >>>>>>>> Push support I noticed some differences between our implementation and the >>>>>>>> native Push regarding the success callback after a register : >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> //Native FFOS Push >>>>>>>> broadcastRequest = navigator.push.register(); >>>>>>>> broadcastRequest.onsuccess = function (event) { >>>>>>>> broadcastEndpoint = broadcastRequest.result; // only contains the pushURL >>>>>>>> } >>>>>>>> >>>>>>>> >>>>>>>> //Aerogear Push Adapter >>>>>>>> broadcastRequest = navigator.push.register(); >>>>>>>> broadcastRequest.onsuccess = function (event) { >>>>>>>> broadcastEndpoint = broadcastRequest.result.pushEndpoint; >>>>>>>> channelID = broadcastRequest.result.channelID; >>>>>>>> version = broadcastRequest.result.version; >>>>>>>> status = broadcastRequest.result.status >>>>>>>> } >>>>>>>> >>>>>>>> So, the AeroGear Push exposes much more in the callback that it >>>>>>>> should suppose to do : just exposing the pushEndpoint. >>>>>>>> >>>>>>>> The reason we do that I suppose, but Luke or Kris could confirm >>>>>>>> that, is that we thought respecting the SPS protocol, which indeed returns >>>>>>>> a whole object containing all the info. It is just that the Native Push >>>>>>>> Client API filter that out in the callback response. >>>>>>>> >>>>>>> >>>>>>> >>>>>>> Did they change that recently? Or was theirs always like it is now ? >>>>>>> >>>>>>> >>>>>>> >>>>>>>> After discussing that on the #push channel with the Mozilla >>>>>>>> people they confirmed me that we should only expoe the pushEndpoint. >>>>>>>> >>>>>>> >>>>>>> >>>>>>> yep, I agree on changing our JS polyfil >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> If we keep it as is, this can be problematic when we want to use >>>>>>>> the same code both for native and with the adapter when, for instance, >>>>>>>> registering to the UPS : >>>>>>>> >>>>>>>> broadcastRequest = navigator.push.register(); >>>>>>>> broadcastRequest.onsuccess = function (event) { >>>>>>>> broadcastEndpoint = event.target.result; >>>>>>>> var broadCastSettings = { >>>>>>>> metadata: { >>>>>>>> deviceToken: broadcastEndpoint.channelID, >>>>>>>> simplePushEndpoint: broadcastEndpoint.pushEndpoint >>>>>>>> } >>>>>>>> } >>>>>>>> UPClient.registerWithPushServer(broadCastSettings); >>>>>>>> } >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> This won't work with the native push since "broadcastEndpoint.channelID" >>>>>>>> will be undefined. >>>>>>>> >>>>>>> >>>>>>> sweet :-) >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> So I propose that we change the behaviour, to return only the >>>>>>>> pushEndpoint in the callback, even if that means a bit of String >>>>>>>> manipulation when we want to perform the registration to the UPS : >>>>>>>> >>>>>>>> var broadCastSettings = { >>>>>>>> metadata: { >>>>>>>> deviceToken: broadcastEndpoint.substr(broadcastEndpoint.lastIndexOf('/') + 1), >>>>>>>> simplePushEndpoint: broadcastEndpoint >>>>>>>> } >>>>>>>> } >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> well, that's not really good for security reasons, since their >>>>>>> looooong 'substring' was done for that. Also that's just redundant. >>>>>>> >>>>>>> The I guess, the deviceToken (channelID registration) might be a bit >>>>>>> bogus, for SimplePush. Let me think about it.... >>>>>>> >>>>>> >>>>>> >>>>>> Right now we use the channelID as the deviceToken, but we should not >>>>>> really 'leak' the channelID (see [1]), so I guess the here proposed change >>>>>> makes sense. Don't recall exactly why we did it in the past, but yeah - >>>>>> let's change it. >>>>>> >>>>>> >>>>>> Thinking about the consequence: I think we should use store the value >>>>>> of the returned 'pushEndpoint' string as our device-token. At the end the >>>>>> device-token is really the thing that identifies a device w/in the target >>>>>> network. Apple/Google uses a unique string, and if Mozilla uses a URL, >>>>>> that's totally fine. >>>>>> >>>>>> Reading the protocol definitions (see [1]) for the 'endpoint' I think >>>>>> it is fair to use that (unique) URL string as the device-token; And we >>>>>> could use this token value as well for the unregister calls, instead of the >>>>>> channelIDs. >>>>>> >>>>> >>>>> After reading your comment on the PR >>>>> https://github.com/aerogear/aerogear-js/pull/105#issuecomment-34324732I understand that you just want to use the deviceToken and not pass the >>>>> simplePushEndpoint to UPS anymore, is that right ? >>>>> >>>> >>>> >>>> yep >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> >>>>>> >>>>>> Any thoughts ? >>>>>> >>>>>> >>>>>> -Matthias >>>>>> >>>>>> [1] https://wiki.mozilla.org/WebAPI/SimplePush/Protocol#Definitions >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> That said, we still have no clue how to proper clean-up 'out dated' >>>>>>> channels, since the SimplePush Server/Protocol is silent on that (unlike >>>>>>> APNs / GCM). but that's really a different thread (yep, we have a future >>>>>>> JIRA for that) >>>>>>> >>>>>>> >>>>>>> -M >>>>>>> >>>>>>> >>>>>>> >>>>>>>> wdyt ? >>>>>>>> >>>>>>>> Seb >>>>>>>> >>>>>>>> >>>>>>>> ps : our SPS Server implementation stays correct and returns what >>>>>>>> should be returned, it's really just the client part and how we expose the >>>>>>>> result >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> 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 >> >> >> >> _______________________________________________ >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140212/dea009b1/attachment-0001.html From lholmqui at redhat.com Wed Feb 12 12:24:23 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Wed, 12 Feb 2014 12:24:23 -0500 Subject: [aerogear-dev] [UnifiedPush] Time for a release? In-Reply-To: References: Message-ID: +1 sounds reasonable On Feb 12, 2014, at 11:19 AM, Matthias Wessendorf wrote: > Hello, > > I'd like to release the next version of UPS (0.10.0), we covered a lot of items since our last release ([1]). > > However, there are some open PRs ([2] and [3]) around the user-management work that Sebi did, with help of Bruno. As we have been discussing on different threads (e.g. [4]), we started looking at Keycloak and it also offers the facility for user management as well. > > I'd like to get the Keycloak integration as the primary goal for the next release, beides fixes and other potential features (e.g. around security). That said, but IMO this kind makes the PRs around user-management redundant. Especially since in [2] we filed a bunch of new JIRAs to cover/fix issues and weak design etc. > > I'd really like to skip the user-mangement PR (see [2]). We might want to keep the branch - just in case, but I'd really like to see this not landing, especially as we are already looking towards keycloak integration. > > > Any thoughts ? > > -Matthias > > > [1] https://issues.jboss.org/browse/AGPUSH/fixforversion/12321876 > [2] https://github.com/aerogear/aerogear-unifiedpush-server/pull/118 > [3] https://github.com/aerogear/aerogear-unifiedpush-server/pull/123 > [4] http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Keycloak-on-AeroGear-td5663.html > > > > -- > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140212/6dbf1b17/attachment.html From kpiwko at redhat.com Thu Feb 13 04:20:36 2014 From: kpiwko at redhat.com (Karel Piwko) Date: Thu, 13 Feb 2014 10:20:36 +0100 Subject: [aerogear-dev] [UnifiedPush] Time for a release? In-Reply-To: References: Message-ID: <20140213102036.0682df41@kapy-ntb-x220> +1, makes perfect sense to me. On Wed, 12 Feb 2014 17:19:15 +0100 Matthias Wessendorf wrote: > Hello, > > I'd like to release the next version of UPS (0.10.0), we covered a lot of > items since our last release ([1]). > > However, there are some open PRs ([2] and [3]) around the user-management > work that Sebi did, with help of Bruno. As we have been discussing on > different threads (e.g. [4]), we started looking at Keycloak and it also > offers the facility for user management as well. > > I'd like to get the Keycloak integration as the primary goal for the next > release, beides fixes and other potential features (e.g. around security). > That said, but IMO this kind makes the PRs around user-management > redundant. Especially since in [2] we filed a bunch of new JIRAs to > cover/fix issues and weak design etc. > > I'd really like to skip the user-mangement PR (see [2]). We might want to > keep the branch - just in case, but I'd really like to see this not > landing, especially as we are already looking towards keycloak integration. > > > Any thoughts ? > > -Matthias > > > [1] https://issues.jboss.org/browse/AGPUSH/fixforversion/12321876 > [2] https://github.com/aerogear/aerogear-unifiedpush-server/pull/118 > [3] https://github.com/aerogear/aerogear-unifiedpush-server/pull/123 > [4] > http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Keycloak-on-AeroGear-td5663.html > > > From corinnekrych at gmail.com Thu Feb 13 04:47:20 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Thu, 13 Feb 2014 10:47:20 +0100 Subject: [aerogear-dev] [ag.org] Make our doc even dryer Message-ID: Hello Guys, To keep your documentation DRY, Karel suggested the usage of acsciidoc include in this ML thread [1]. We tried with Erik* some experiment, it's in this gist [2]. I think it's aneat feature and we could use it in different way: 1) reuse some cookbook documentation page (if in asciidoc format) 2) embed source code snippet in our documentation to make sure our doc is always up to date with latest code Just wanted to check with you if you like the idea bacause it will involve some documentation format changes (part of your web site revamp). Note: we could use code snippet include (option2) without option 1). wdyt? ++ Corinne [1] http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Fwd-Website-restructure-td5837.html [2] https://gist.github.com/anonymous/dac8efdb7c90206acffe *asciisoc hero -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140213/0384f0e2/attachment.html From edewit at redhat.com Thu Feb 13 04:58:17 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Thu, 13 Feb 2014 10:58:17 +0100 Subject: [aerogear-dev] [ag.org] Make our doc even dryer In-Reply-To: References: Message-ID: I think it?s a great idea having the same examples and code fragments all over the place is a bad thing. This way our documentation code snippets are guaranteed to compile and execute and can even be refactored! From bruno at abstractj.org Thu Feb 13 05:08:21 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Thu, 13 Feb 2014 08:08:21 -0200 Subject: [aerogear-dev] Offline Authentication and friends In-Reply-To: References: Message-ID: Jiras created?https://issues.jboss.org/issues/?jql=fixVersion%20%3D%20%221.4.0%22%20AND%20project%20%3D%20AGSEC%20AND%20created%3E%3D-1w%20ORDER%20BY%20created%20DESC -- abstractj On February 10, 2014 at 11:35:47 AM, Bruno Oliveira (bruno at abstractj.org) wrote: > > Good morning peeps, on the last week me and @passos spent most > part of the time reading/testing/deleting and struggling with > the best approach to provide offline authentication, encrypted > cache and friends on AeroGear. > > This is our initial draft https://github.com/aerogear/aerogear.org/pull/247 > planned to be released with AG Security 1.4.0 if we survive to > the global warming. > > Feedback is welcome. > > -- > abstractj > From kpiwko at redhat.com Thu Feb 13 06:26:30 2014 From: kpiwko at redhat.com (Karel Piwko) Date: Thu, 13 Feb 2014 12:26:30 +0100 Subject: [aerogear-dev] [ag.org] Make our doc even dryer In-Reply-To: References: Message-ID: <20140213122630.51986d0d@kapy-ntb-x220> One other improvement I was thinking of was to setup a git commit hook. The idea is that asciidoc reference snippets by file+line# This hook will basically do following: 1/ Check files for asciidoc annotatations in the repository - e.g. // @asciidoc-example-start public void mySuperPipeExampleThatGoesToPipeDoc(Pipe p) { p.ftw(); } // @asciidoc-example-end 2/ Apply commit 3/ Check once again if the line numbers of asciidoc annotations is the same 4/ If not, produce a *FAT* warning that commiter should update aerogear.github.com repo with new line numbers to align doc. This should keep code and doc up-to-date. I can create such hook, the question is what is "the most usual env"(tm) so it would be working for everybody - assuming sh/awk/grep will do? Karel On Thu, 13 Feb 2014 10:58:17 +0100 Erik Jan de Wit wrote: > I think it?s a great idea having the same examples and code fragments all > over the place is a bad thing. This way our documentation code snippets are > guaranteed to compile and execute and can even be refactored! > _______________________________________________ aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From edewit at redhat.com Thu Feb 13 06:57:42 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Thu, 13 Feb 2014 12:57:42 +0100 Subject: [aerogear-dev] [ag.org] Make our doc even dryer In-Reply-To: <20140213122630.51986d0d@kapy-ntb-x220> References: <20140213122630.51986d0d@kapy-ntb-x220> Message-ID: <23351E4E-68E1-418E-BC0E-CFF0750CE718@redhat.com> Like it, that way it will not get misaligned by accident On 13 Feb,2014, at 12:26 , Karel Piwko wrote: > One other improvement I was thinking of was to setup a git commit hook. > > The idea is that asciidoc reference snippets by file+line# > > This hook will basically do following: > > 1/ Check files for asciidoc annotatations in the repository - e.g. > > // @asciidoc-example-start > public void mySuperPipeExampleThatGoesToPipeDoc(Pipe p) { > p.ftw(); > } > // @asciidoc-example-end > > 2/ Apply commit > 3/ Check once again if the line numbers of asciidoc annotations is the same > 4/ If not, produce a *FAT* warning that commiter should update > aerogear.github.com repo with new line numbers to align doc. > > This should keep code and doc up-to-date. > > I can create such hook, the question is what is "the most usual env"(tm) > so it would be working for everybody - assuming sh/awk/grep will do? > > Karel > > On Thu, 13 Feb 2014 10:58:17 +0100 > Erik Jan de Wit wrote: > >> I think it?s a great idea having the same examples and code fragments all >> over the place is a bad thing. This way our documentation code snippets are >> guaranteed to compile and execute and can even be refactored! >> _______________________________________________ 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 From matzew at apache.org Thu Feb 13 11:13:12 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 13 Feb 2014 17:13:12 +0100 Subject: [aerogear-dev] unifiedpush-java-client (0.5.0) Message-ID: Hi Folks, I'm happy to announce the a new version of the 'unifiedpush-java-client' (0.5.0) has been staged. https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-2601/ Here is the changelog : * Adding unit tests for untested builder methods * Adding content-available builder + unit tests (support of iOS7 silent messages on the builder) * fix groupId and artifactId If they aren't any objections or remarks I will release the bits to maven central on Monday morning -Matthias -- 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/20140213/5e030a6f/attachment-0001.html From matzew at apache.org Thu Feb 13 14:13:04 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 13 Feb 2014 20:13:04 +0100 Subject: [aerogear-dev] staging of UnifiedPush Server 0.10.0 Message-ID: Hello, for the upcoming release we fixed several tickets: https://issues.jboss.org/browse/AGPUSH/fixforversion/12321876 Before finishing the release, let's see if there are issues w/ the server, hence I have staged the WAR file on my private webspace: http://people.apache.org/~matzew/aerogear-staging/org/jboss/aerogear/unifiedpush/unifiedpush-server/0.10.0/ If they aren't any objections or remarks I will release the bits to maven central on Monday morning -Matthias -- 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/20140213/180bb2e1/attachment.html From scm.blanc at gmail.com Thu Feb 13 15:39:18 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Thu, 13 Feb 2014 21:39:18 +0100 Subject: [aerogear-dev] Differences between Firefox OS "native" Push lib and AeroGear's Push adapter In-Reply-To: <9B70BDB9-4774-4BF0-9FF7-5213185E4F52@redhat.com> References: <9B70BDB9-4774-4BF0-9FF7-5213185E4F52@redhat.com> Message-ID: On Wed, Feb 12, 2014 at 2:30 PM, Lucas Holmquist wrote: > i might have a couple thoughts, but i need to try some things out first > Any update on that or does the solution proposed by Matzew (using encodeURIComponent() ) could be enough ? > > On Feb 12, 2014, at 3:53 AM, Sebastien Blanc wrote: > > > > > On Tue, Feb 11, 2014 at 7:15 PM, Sebastien Blanc wrote: > >> Ok, >> I've been doing some tests by using the PushEndpoint as device token. For >> registration it works but I just faced an issue by trying to unregister >> because the URL for the DELETE looks like : >> >> >> https://judconpush-sblanc.rhcloud.com/rest/registry/device/https://updates.push.services.mozilla.com/update/my_personnal_psuhendpoint_id[ >> >> And the REST endpoint get a bit crazy by the extra "/" present in the >> endpoint URL. Therefore, I think we must just use the last URL fragment as >> deviceToken. >> > > Ok answering to myself ;) That won't work neither since if we do that UPS > won't have the compllete push endpoint URL. > So how do we deal with that ? > >> >> >> On Thu, Feb 6, 2014 at 3:27 PM, Matthias Wessendorf wrote: >> >>> >>> >>> >>> On Thu, Feb 6, 2014 at 3:11 PM, Sebastien Blanc wrote: >>> >>>> >>>> >>>> >>>> On Thu, Feb 6, 2014 at 12:28 PM, Matthias Wessendorf >>> > wrote: >>>> >>>>> >>>>> >>>>> >>>>> On Wed, Feb 5, 2014 at 11:52 PM, Matthias Wessendorf < >>>>> matzew at apache.org> wrote: >>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Wed, Feb 5, 2014 at 11:22 PM, Sebastien Blanc >>>>> > wrote: >>>>>> >>>>>>> Hi, >>>>>>> While playing today with my Firefox Device and its native Simple >>>>>>> Push support I noticed some differences between our implementation and the >>>>>>> native Push regarding the success callback after a register : >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> //Native FFOS Push >>>>>>> broadcastRequest = navigator.push.register(); >>>>>>> broadcastRequest.onsuccess = function (event) { >>>>>>> broadcastEndpoint = broadcastRequest.result; // only contains the pushURL >>>>>>> } >>>>>>> >>>>>>> >>>>>>> //Aerogear Push Adapter >>>>>>> broadcastRequest = navigator.push.register(); >>>>>>> broadcastRequest.onsuccess = function (event) { >>>>>>> broadcastEndpoint = broadcastRequest.result.pushEndpoint; >>>>>>> channelID = broadcastRequest.result.channelID; >>>>>>> version = broadcastRequest.result.version; >>>>>>> status = broadcastRequest.result.status >>>>>>> } >>>>>>> >>>>>>> So, the AeroGear Push exposes much more in the callback that it >>>>>>> should suppose to do : just exposing the pushEndpoint. >>>>>>> >>>>>>> The reason we do that I suppose, but Luke or Kris could confirm >>>>>>> that, is that we thought respecting the SPS protocol, which indeed returns >>>>>>> a whole object containing all the info. It is just that the Native Push >>>>>>> Client API filter that out in the callback response. >>>>>>> >>>>>> >>>>>> >>>>>> Did they change that recently? Or was theirs always like it is now ? >>>>>> >>>>>> >>>>>> >>>>>>> After discussing that on the #push channel with the Mozilla people >>>>>>> they confirmed me that we should only expoe the pushEndpoint. >>>>>>> >>>>>> >>>>>> >>>>>> yep, I agree on changing our JS polyfil >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> If we keep it as is, this can be problematic when we want to use the >>>>>>> same code both for native and with the adapter when, for instance, >>>>>>> registering to the UPS : >>>>>>> >>>>>>> broadcastRequest = navigator.push.register(); >>>>>>> broadcastRequest.onsuccess = function (event) { >>>>>>> broadcastEndpoint = event.target.result; >>>>>>> var broadCastSettings = { >>>>>>> metadata: { >>>>>>> deviceToken: broadcastEndpoint.channelID, >>>>>>> simplePushEndpoint: broadcastEndpoint.pushEndpoint >>>>>>> } >>>>>>> } >>>>>>> UPClient.registerWithPushServer(broadCastSettings); >>>>>>> } >>>>>>> >>>>>>> >>>>>>> >>>>>>> This won't work with the native push since "broadcastEndpoint.channelID" >>>>>>> will be undefined. >>>>>>> >>>>>> >>>>>> sweet :-) >>>>>> >>>>>> >>>>>>> >>>>>>> So I propose that we change the behaviour, to return only the >>>>>>> pushEndpoint in the callback, even if that means a bit of String >>>>>>> manipulation when we want to perform the registration to the UPS : >>>>>>> >>>>>>> var broadCastSettings = { >>>>>>> metadata: { >>>>>>> deviceToken: broadcastEndpoint.substr(broadcastEndpoint.lastIndexOf('/') + 1), >>>>>>> simplePushEndpoint: broadcastEndpoint >>>>>>> } >>>>>>> } >>>>>>> >>>>>>> >>>>>>> >>>>>> well, that's not really good for security reasons, since their >>>>>> looooong 'substring' was done for that. Also that's just redundant. >>>>>> >>>>>> The I guess, the deviceToken (channelID registration) might be a bit >>>>>> bogus, for SimplePush. Let me think about it.... >>>>>> >>>>> >>>>> >>>>> Right now we use the channelID as the deviceToken, but we should not >>>>> really 'leak' the channelID (see [1]), so I guess the here proposed change >>>>> makes sense. Don't recall exactly why we did it in the past, but yeah - >>>>> let's change it. >>>>> >>>>> >>>>> Thinking about the consequence: I think we should use store the value >>>>> of the returned 'pushEndpoint' string as our device-token. At the end the >>>>> device-token is really the thing that identifies a device w/in the target >>>>> network. Apple/Google uses a unique string, and if Mozilla uses a URL, >>>>> that's totally fine. >>>>> >>>>> Reading the protocol definitions (see [1]) for the 'endpoint' I think >>>>> it is fair to use that (unique) URL string as the device-token; And we >>>>> could use this token value as well for the unregister calls, instead of the >>>>> channelIDs. >>>>> >>>> >>>> After reading your comment on the PR >>>> https://github.com/aerogear/aerogear-js/pull/105#issuecomment-34324732I understand that you just want to use the deviceToken and not pass the >>>> simplePushEndpoint to UPS anymore, is that right ? >>>> >>> >>> >>> yep >>> >>> >>> >>> >>> >>> >>> >>> >>>> >>>>> >>>>> Any thoughts ? >>>>> >>>>> >>>>> -Matthias >>>>> >>>>> [1] https://wiki.mozilla.org/WebAPI/SimplePush/Protocol#Definitions >>>>> >>>>> >>>>> >>>>> >>>>>> >>>>>> That said, we still have no clue how to proper clean-up 'out dated' >>>>>> channels, since the SimplePush Server/Protocol is silent on that (unlike >>>>>> APNs / GCM). but that's really a different thread (yep, we have a future >>>>>> JIRA for that) >>>>>> >>>>>> >>>>>> -M >>>>>> >>>>>> >>>>>> >>>>>>> wdyt ? >>>>>>> >>>>>>> Seb >>>>>>> >>>>>>> >>>>>>> ps : our SPS Server implementation stays correct and returns what >>>>>>> should be returned, it's really just the client part and how we expose the >>>>>>> result >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> 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 > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140213/e644e597/attachment-0001.html From lholmqui at redhat.com Fri Feb 14 08:06:21 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Fri, 14 Feb 2014 08:06:21 -0500 Subject: [aerogear-dev] Differences between Firefox OS "native" Push lib and AeroGear's Push adapter In-Reply-To: References: <9B70BDB9-4774-4BF0-9FF7-5213185E4F52@redhat.com> Message-ID: <51C9D854-0730-4B2A-9A92-9DC92649947D@redhat.com> still exploring On Feb 13, 2014, at 3:39 PM, Sebastien Blanc wrote: > > > > On Wed, Feb 12, 2014 at 2:30 PM, Lucas Holmquist wrote: > i might have a couple thoughts, but i need to try some things out first > > Any update on that or does the solution proposed by Matzew (using encodeURIComponent() ) could be enough ? > > On Feb 12, 2014, at 3:53 AM, Sebastien Blanc wrote: > >> >> >> >> On Tue, Feb 11, 2014 at 7:15 PM, Sebastien Blanc wrote: >> Ok, >> I've been doing some tests by using the PushEndpoint as device token. For registration it works but I just faced an issue by trying to unregister because the URL for the DELETE looks like : >> >> https://judconpush-sblanc.rhcloud.com/rest/registry/device/https://updates.push.services.mozilla.com/update/my_personnal_psuhendpoint_id [ >> >> And the REST endpoint get a bit crazy by the extra "/" present in the endpoint URL. Therefore, I think we must just use the last URL fragment as deviceToken. >> >> Ok answering to myself ;) That won't work neither since if we do that UPS won't have the compllete push endpoint URL. >> So how do we deal with that ? >> >> >> On Thu, Feb 6, 2014 at 3:27 PM, Matthias Wessendorf wrote: >> >> >> >> On Thu, Feb 6, 2014 at 3:11 PM, Sebastien Blanc wrote: >> >> >> >> On Thu, Feb 6, 2014 at 12:28 PM, Matthias Wessendorf wrote: >> >> >> >> On Wed, Feb 5, 2014 at 11:52 PM, Matthias Wessendorf wrote: >> >> >> >> On Wed, Feb 5, 2014 at 11:22 PM, Sebastien Blanc wrote: >> Hi, >> While playing today with my Firefox Device and its native Simple Push support I noticed some differences between our implementation and the native Push regarding the success callback after a register : >> >> >> >> >> >> >> >> >> >> >> >> >> //Native FFOS Push >> broadcastRequest = navigator.push.register(); >> broadcastRequest.onsuccess = function (event) { >> broadcastEndpoint = broadcastRequest.result; // only contains the pushURL >> } >> >> >> //Aerogear Push Adapter >> broadcastRequest = navigator.push.register(); >> broadcastRequest.onsuccess = function (event) { >> broadcastEndpoint = broadcastRequest.result.pushEndpoint; >> channelID = broadcastRequest.result.channelID; >> version = broadcastRequest.result.version; >> status = broadcastRequest.result.status >> } >> So, the AeroGear Push exposes much more in the callback that it should suppose to do : just exposing the pushEndpoint. >> >> The reason we do that I suppose, but Luke or Kris could confirm that, is that we thought respecting the SPS protocol, which indeed returns a whole object containing all the info. It is just that the Native Push Client API filter that out in the callback response. >> >> >> Did they change that recently? Or was theirs always like it is now ? >> >> >> After discussing that on the #push channel with the Mozilla people they confirmed me that we should only expoe the pushEndpoint. >> >> >> yep, I agree on changing our JS polyfil >> >> >> >> If we keep it as is, this can be problematic when we want to use the same code both for native and with the adapter when, for instance, registering to the UPS : >> >> broadcastRequest = navigator.push.register(); >> broadcastRequest.onsuccess = function (event) { >> broadcastEndpoint = event.target.result; >> var broadCastSettings = { >> metadata: { >> deviceToken: broadcastEndpoint.channelID, >> simplePushEndpoint: broadcastEndpoint.pushEndpoint >> } >> } >> UPClient.registerWithPushServer(broadCastSettings); >> } >> >> >> This won't work with the native push since "broadcastEndpoint.channelID" will be undefined. >> >> sweet :-) >> >> >> So I propose that we change the behaviour, to return only the pushEndpoint in the callback, even if that means a bit of String manipulation when we want to perform the registration to the UPS : >> >> var broadCastSettings = { >> metadata: { >> deviceToken: broadcastEndpoint.substr(broadcastEndpoint.lastIndexOf('/') + 1), >> simplePushEndpoint: broadcastEndpoint >> } >> } >> >> >> well, that's not really good for security reasons, since their looooong 'substring' was done for that. Also that's just redundant. >> >> The I guess, the deviceToken (channelID registration) might be a bit bogus, for SimplePush. Let me think about it.... >> >> >> Right now we use the channelID as the deviceToken, but we should not really 'leak' the channelID (see [1]), so I guess the here proposed change makes sense. Don't recall exactly why we did it in the past, but yeah - let's change it. >> >> >> Thinking about the consequence: I think we should use store the value of the returned 'pushEndpoint' string as our device-token. At the end the device-token is really the thing that identifies a device w/in the target network. Apple/Google uses a unique string, and if Mozilla uses a URL, that's totally fine. >> >> Reading the protocol definitions (see [1]) for the 'endpoint' I think it is fair to use that (unique) URL string as the device-token; And we could use this token value as well for the unregister calls, instead of the channelIDs. >> >> After reading your comment on the PR https://github.com/aerogear/aerogear-js/pull/105#issuecomment-34324732 I understand that you just want to use the deviceToken and not pass the simplePushEndpoint to UPS anymore, is that right ? >> >> >> yep >> >> >> >> >> >> >> >> >> >> Any thoughts ? >> >> >> -Matthias >> >> [1] https://wiki.mozilla.org/WebAPI/SimplePush/Protocol#Definitions >> >> >> >> >> That said, we still have no clue how to proper clean-up 'out dated' channels, since the SimplePush Server/Protocol is silent on that (unlike APNs / GCM). but that's really a different thread (yep, we have a future JIRA for that) >> >> >> -M >> >> >> wdyt ? >> >> Seb >> >> >> ps : our SPS Server implementation stays correct and returns what should be returned, it's really just the client part and how we expose the result >> >> >> _______________________________________________ >> 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 >> >> >> >> -- >> 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 > > > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140214/4438b185/attachment-0001.html From cvasilak at gmail.com Fri Feb 14 08:35:03 2014 From: cvasilak at gmail.com (Christos Vasilakis) Date: Fri, 14 Feb 2014 15:35:03 +0200 Subject: [aerogear-dev] Bump up version of aerogear-push-ios-registration Message-ID: <4401DB10-0C2C-4DE1-9F5F-E9B0C51AE500@gmail.com> Hi team, since the last 0.8 release of the aerogear-push-ios-registration lib, we have upgraded it to use AFNetworking lib to 1.3.3. Since the release of aerogear-ios has been upgraded too 1.3.3 also, and can depend on push lib, in order to not have problems with the dependency what to you think of bumping up the version of aerogear-push-ios-registration to 0.8.1 and releasing to cocoapods. Thoughts? Thanks, Christos From matzew at apache.org Fri Feb 14 08:38:14 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 14 Feb 2014 14:38:14 +0100 Subject: [aerogear-dev] Bump up version of aerogear-push-ios-registration In-Reply-To: <4401DB10-0C2C-4DE1-9F5F-E9B0C51AE500@gmail.com> References: <4401DB10-0C2C-4DE1-9F5F-E9B0C51AE500@gmail.com> Message-ID: +1 On Fri, Feb 14, 2014 at 2:35 PM, Christos Vasilakis wrote: > Hi team, > > since the last 0.8 release of the aerogear-push-ios-registration lib, we > have upgraded it to use AFNetworking lib to 1.3.3. Since the release of > aerogear-ios has been upgraded too 1.3.3 also, and can depend on push lib, > in order to not have problems with the dependency what to you think of > bumping up the version of aerogear-push-ios-registration to 0.8.1 and > releasing to cocoapods. > > Thoughts? > > Thanks, > Christos > > > _______________________________________________ > 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/20140214/13e8285c/attachment.html From jbalunas at redhat.com Fri Feb 14 09:31:32 2014 From: jbalunas at redhat.com (Jay Balunas) Date: Fri, 14 Feb 2014 09:31:32 -0500 Subject: [aerogear-dev] AeroGear project leadership updates Message-ID: <9993ED20-E46D-4768-87D3-4EA65E92B4F0@redhat.com> Hi All, The AeroGear project has come a long way and Qmx a.k.a. Douglas Campos has been at the helm. Qmx has decided to transition to an individual contributor and full time code monkey :-) Thanks for your time and effort leading the project Qmx! I'm very happy to announce that Matthias Wessendorf has agreed to take over the AeroGear project lead role! He's been part of the team since nearly the beginning and has already shown great leadership qualities to go along with his technical experience in both mobile, enterprise, and open source domains. As part of this transition we're also announcing some additional leadership roles within client teams. These tech leads will help Matthias coordinate and navigate the complex waters of mobile client SDK development. Corinne Krych iOS -- a.k.a. "Corrine.dmg" Luke Holmquist JavaScript -- a.k.a. "Luke.js" Daniel Passos Android -- a.k.a. "Passos.apk" I just want to say that i'm proud of the whole team, and I'm excited to see what we can accomplish in the coming year. Congratulation to everyone and thanks again Qmx for you time at the helm! -Jay From bruno at abstractj.org Fri Feb 14 09:45:51 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Fri, 14 Feb 2014 12:45:51 -0200 Subject: [aerogear-dev] AeroGear project leadership updates In-Reply-To: <9993ED20-E46D-4768-87D3-4EA65E92B4F0@redhat.com> References: <9993ED20-E46D-4768-87D3-4EA65E92B4F0@redhat.com> Message-ID: How that is possible?! I didn?t scheduled a leadership interview with Matthias, Luke, Daniel and Corinne! Jokes aside, congratulation to you guys! -- abstractj On February 14, 2014 at 12:31:37 PM, Jay Balunas (jbalunas at redhat.com) wrote: > > Hi All, > > The AeroGear project has come a long way and Qmx a.k.a. Douglas > Campos has been at the helm. Qmx has decided to transition to an > individual contributor and full time code monkey :-) Thanks > for your time and effort leading the project Qmx! > > I'm very happy to announce that Matthias Wessendorf has agreed > to take over the AeroGear project lead role! He's been part of > the team since nearly the beginning and has already shown great > leadership qualities to go along with his technical experience > in both mobile, enterprise, and open source domains. > > As part of this transition we're also announcing some additional > leadership roles within client teams. These tech leads will > help Matthias coordinate and navigate the complex waters of > mobile client SDK development. > > Corinne Krych iOS -- a.k.a. "Corrine.dmg" > Luke Holmquist JavaScript -- a.k.a. "Luke.js" > Daniel Passos Android -- a.k.a. "Passos.apk" > > I just want to say that i'm proud of the whole team, and I'm excited > to see what we can accomplish in the coming year. > > Congratulation to everyone and thanks again Qmx for you time > at the helm! > > -Jay From daniel.bevenius at gmail.com Fri Feb 14 09:56:37 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Fri, 14 Feb 2014 15:56:37 +0100 Subject: [aerogear-dev] AeroGear project leadership updates In-Reply-To: References: <9993ED20-E46D-4768-87D3-4EA65E92B4F0@redhat.com> Message-ID: Thanks Qmx, and congrats to all of you! On 14 February 2014 15:45, Bruno Oliveira wrote: > How that is possible?! I didn't scheduled a leadership interview with > Matthias, Luke, Daniel and Corinne! > > Jokes aside, congratulation to you guys! > > -- > abstractj > > On February 14, 2014 at 12:31:37 PM, Jay Balunas (jbalunas at redhat.com) > wrote: > > > Hi All, > > > > The AeroGear project has come a long way and Qmx a.k.a. Douglas > > Campos has been at the helm. Qmx has decided to transition to an > > individual contributor and full time code monkey :-) Thanks > > for your time and effort leading the project Qmx! > > > > I'm very happy to announce that Matthias Wessendorf has agreed > > to take over the AeroGear project lead role! He's been part of > > the team since nearly the beginning and has already shown great > > leadership qualities to go along with his technical experience > > in both mobile, enterprise, and open source domains. > > > > As part of this transition we're also announcing some additional > > leadership roles within client teams. These tech leads will > > help Matthias coordinate and navigate the complex waters of > > mobile client SDK development. > > > > Corinne Krych iOS -- a.k.a. "Corrine.dmg" > > Luke Holmquist JavaScript -- a.k.a. "Luke.js" > > Daniel Passos Android -- a.k.a. "Passos.apk" > > > > I just want to say that i'm proud of the whole team, and I'm excited > > to see what we can accomplish in the coming year. > > > > Congratulation to everyone and thanks again Qmx for you time > > at the helm! > > > > -Jay > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140214/80a58949/attachment.html From stian at redhat.com Fri Feb 14 10:08:14 2014 From: stian at redhat.com (Stian Thorgersen) Date: Fri, 14 Feb 2014 10:08:14 -0500 (EST) Subject: [aerogear-dev] AeroGear project leadership updates In-Reply-To: <9993ED20-E46D-4768-87D3-4EA65E92B4F0@redhat.com> References: <9993ED20-E46D-4768-87D3-4EA65E92B4F0@redhat.com> Message-ID: <673348891.7380131.1392390494085.JavaMail.zimbra@redhat.com> Congratulations to you all :) ----- Original Message ----- > From: "Jay Balunas" > To: "AeroGear Developer Mailing List" > Sent: Friday, 14 February, 2014 2:31:32 PM > Subject: [aerogear-dev] AeroGear project leadership updates > > Hi All, > > The AeroGear project has come a long way and Qmx a.k.a. Douglas Campos has > been at the helm. Qmx has decided to transition to an individual > contributor and full time code monkey :-) Thanks for your time and effort > leading the project Qmx! > > I'm very happy to announce that Matthias Wessendorf has agreed to take over > the AeroGear project lead role! He's been part of the team since nearly the > beginning and has already shown great leadership qualities to go along with > his technical experience in both mobile, enterprise, and open source > domains. > > As part of this transition we're also announcing some additional leadership > roles within client teams. These tech leads will help Matthias coordinate > and navigate the complex waters of mobile client SDK development. > > Corinne Krych iOS -- a.k.a. "Corrine.dmg" > Luke Holmquist JavaScript -- a.k.a. "Luke.js" > Daniel Passos Android -- a.k.a. "Passos.apk" > > I just want to say that i'm proud of the whole team, and I'm excited to see > what we can accomplish in the coming year. > > Congratulation to everyone and thanks again Qmx for you time at the helm! > > -Jay > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > From scm.blanc at gmail.com Fri Feb 14 12:28:32 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Fri, 14 Feb 2014 18:28:32 +0100 Subject: [aerogear-dev] staging of UnifiedPush Server 0.10.0 In-Reply-To: References: Message-ID: Hi, I just give it a test , it deploys well and works but ... Looking at the Admin UI, it stills mention 0.10.0-SNAPSHOT in the title, that should be fixed. The latest UI update on UPS is from 14/01, would not hurt to make another UI release to be integrated in UPS to be sure we miss no UI fixes in the release. I can do the PR if you are okay ? Seb On Thu, Feb 13, 2014 at 8:13 PM, Matthias Wessendorf wrote: > Hello, > > for the upcoming release we fixed several tickets: > https://issues.jboss.org/browse/AGPUSH/fixforversion/12321876 > > Before finishing the release, let's see if there are issues w/ the server, > hence I have staged the WAR file on my private webspace: > > > > http://people.apache.org/~matzew/aerogear-staging/org/jboss/aerogear/unifiedpush/unifiedpush-server/0.10.0/ > > > If they aren't any objections or remarks I will release the bits to maven > central on Monday morning > > -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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140214/6d684066/attachment-0001.html From matzew at apache.org Fri Feb 14 12:33:17 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 14 Feb 2014 18:33:17 +0100 Subject: [aerogear-dev] staging of UnifiedPush Server 0.10.0 In-Reply-To: References: Message-ID: On Fri, Feb 14, 2014 at 6:28 PM, Sebastien Blanc wrote: > Hi, > I just give it a test , it deploys well and works but ... > Looking at the Admin UI, it stills mention 0.10.0-SNAPSHOT in the title, > that should be fixed. > Oh, I didn't really pay attention to that, to be honest! Glad you found it > > The latest UI update on UPS is from 14/01, would not hurt to make another > UI release to be integrated in UPS to be sure we miss no UI fixes in the > release. > > I can do the PR if you are okay ? > Let's drop the 0.10.0 TAG; go back to 0.10.0-SNAPSHOT on master; update the AdminUI bits on master; and simple re-run the bits. Thanks for looking into this. -Matthias > Seb > > > > On Thu, Feb 13, 2014 at 8:13 PM, Matthias Wessendorf wrote: > >> Hello, >> >> for the upcoming release we fixed several tickets: >> https://issues.jboss.org/browse/AGPUSH/fixforversion/12321876 >> >> Before finishing the release, let's see if there are issues w/ the >> server, hence I have staged the WAR file on my private webspace: >> >> >> >> http://people.apache.org/~matzew/aerogear-staging/org/jboss/aerogear/unifiedpush/unifiedpush-server/0.10.0/ >> >> >> If they aren't any objections or remarks I will release the bits to maven >> central on Monday morning >> >> -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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140214/8864ff2a/attachment.html From lholmqui at redhat.com Fri Feb 14 13:42:38 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Fri, 14 Feb 2014 13:42:38 -0500 Subject: [aerogear-dev] staging of UnifiedPush Server 0.10.0 In-Reply-To: References: Message-ID: <0A2DAF78-924D-4042-BC9C-5D72E4E0EEC1@redhat.com> On Feb 14, 2014, at 12:28 PM, Sebastien Blanc wrote: > Hi, > I just give it a test , it deploys well and works but ... > Looking at the Admin UI, it stills mention 0.10.0-SNAPSHOT in the title, that should be fixed. > > The latest UI update on UPS is from 14/01, would not hurt to make another UI release to be integrated in UPS to be sure we miss no UI fixes in the release. > > I can do the PR if you are okay ? > good idea since ember just released a security fix > Seb > > > > On Thu, Feb 13, 2014 at 8:13 PM, Matthias Wessendorf wrote: > Hello, > > for the upcoming release we fixed several tickets: > https://issues.jboss.org/browse/AGPUSH/fixforversion/12321876 > > Before finishing the release, let's see if there are issues w/ the server, hence I have staged the WAR file on my private webspace: > > > http://people.apache.org/~matzew/aerogear-staging/org/jboss/aerogear/unifiedpush/unifiedpush-server/0.10.0/ > > > If they aren't any objections or remarks I will release the bits to maven central on Monday morning > > -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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140214/b99804b5/attachment.html From matzew at apache.org Fri Feb 14 13:50:17 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 14 Feb 2014 19:50:17 +0100 Subject: [aerogear-dev] staging of UnifiedPush Server 0.10.0 In-Reply-To: <0A2DAF78-924D-4042-BC9C-5D72E4E0EEC1@redhat.com> References: <0A2DAF78-924D-4042-BC9C-5D72E4E0EEC1@redhat.com> Message-ID: On Fri, Feb 14, 2014 at 7:42 PM, Lucas Holmquist wrote: > > On Feb 14, 2014, at 12:28 PM, Sebastien Blanc wrote: > > Hi, > I just give it a test , it deploys well and works but ... > Looking at the Admin UI, it stills mention 0.10.0-SNAPSHOT in the title, > that should be fixed. > > The latest UI update on UPS is from 14/01, would not hurt to make another > UI release to be integrated in UPS to be sure we miss no UI fixes in the > release. > > I can do the PR if you are okay ? > > good idea since ember just released a security fix > > is that included here ? https://github.com/aerogear/aerogear-unifiedpush-server/pull/132/files -M > > Seb > > > > On Thu, Feb 13, 2014 at 8:13 PM, Matthias Wessendorf wrote: > >> Hello, >> >> for the upcoming release we fixed several tickets: >> https://issues.jboss.org/browse/AGPUSH/fixforversion/12321876 >> >> Before finishing the release, let's see if there are issues w/ the >> server, hence I have staged the WAR file on my private webspace: >> >> >> >> http://people.apache.org/~matzew/aerogear-staging/org/jboss/aerogear/unifiedpush/unifiedpush-server/0.10.0/ >> >> >> If they aren't any objections or remarks I will release the bits to maven >> central on Monday morning >> >> -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 > > > > _______________________________________________ > 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/20140214/a572845b/attachment.html From lholmqui at redhat.com Fri Feb 14 13:52:10 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Fri, 14 Feb 2014 13:52:10 -0500 Subject: [aerogear-dev] staging of UnifiedPush Server 0.10.0 In-Reply-To: References: <0A2DAF78-924D-4042-BC9C-5D72E4E0EEC1@redhat.com> Message-ID: <5FF28062-F341-4818-B519-52F937D6AD79@redhat.com> On Feb 14, 2014, at 1:50 PM, Matthias Wessendorf wrote: > > > > On Fri, Feb 14, 2014 at 7:42 PM, Lucas Holmquist wrote: > > On Feb 14, 2014, at 12:28 PM, Sebastien Blanc wrote: > >> Hi, >> I just give it a test , it deploys well and works but ... >> Looking at the Admin UI, it stills mention 0.10.0-SNAPSHOT in the title, that should be fixed. >> >> The latest UI update on UPS is from 14/01, would not hurt to make another UI release to be integrated in UPS to be sure we miss no UI fixes in the release. >> >> I can do the PR if you are okay ? >> > > good idea since ember just released a security fix > > > is that included here ? > > https://github.com/aerogear/aerogear-unifiedpush-server/pull/132/files sho is > > -M > > > >> Seb >> >> >> >> On Thu, Feb 13, 2014 at 8:13 PM, Matthias Wessendorf wrote: >> Hello, >> >> for the upcoming release we fixed several tickets: >> https://issues.jboss.org/browse/AGPUSH/fixforversion/12321876 >> >> Before finishing the release, let's see if there are issues w/ the server, hence I have staged the WAR file on my private webspace: >> >> >> http://people.apache.org/~matzew/aerogear-staging/org/jboss/aerogear/unifiedpush/unifiedpush-server/0.10.0/ >> >> >> If they aren't any objections or remarks I will release the bits to maven central on Monday morning >> >> -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 > > > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140214/af56d31d/attachment-0001.html From scm.blanc at gmail.com Fri Feb 14 14:01:07 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Fri, 14 Feb 2014 20:01:07 +0100 Subject: [aerogear-dev] staging of UnifiedPush Server 0.10.0 In-Reply-To: <5FF28062-F341-4818-B519-52F937D6AD79@redhat.com> References: <0A2DAF78-924D-4042-BC9C-5D72E4E0EEC1@redhat.com> <5FF28062-F341-4818-B519-52F937D6AD79@redhat.com> Message-ID: Yeah I made sure to do pull on the admin master before doing the release On Fri, Feb 14, 2014 at 7:52 PM, Lucas Holmquist wrote: > > On Feb 14, 2014, at 1:50 PM, Matthias Wessendorf > wrote: > > > > > On Fri, Feb 14, 2014 at 7:42 PM, Lucas Holmquist wrote: > >> >> On Feb 14, 2014, at 12:28 PM, Sebastien Blanc >> wrote: >> >> Hi, >> I just give it a test , it deploys well and works but ... >> Looking at the Admin UI, it stills mention 0.10.0-SNAPSHOT in the title, >> that should be fixed. >> >> The latest UI update on UPS is from 14/01, would not hurt to make another >> UI release to be integrated in UPS to be sure we miss no UI fixes in the >> release. >> >> I can do the PR if you are okay ? >> >> good idea since ember just released a security fix >> >> > is that included here ? > > https://github.com/aerogear/aerogear-unifiedpush-server/pull/132/files > > > sho is > > > -M > > > >> >> Seb >> >> >> >> On Thu, Feb 13, 2014 at 8:13 PM, Matthias Wessendorf wrote: >> >>> Hello, >>> >>> for the upcoming release we fixed several tickets: >>> https://issues.jboss.org/browse/AGPUSH/fixforversion/12321876 >>> >>> Before finishing the release, let's see if there are issues w/ the >>> server, hence I have staged the WAR file on my private webspace: >>> >>> >>> >>> http://people.apache.org/~matzew/aerogear-staging/org/jboss/aerogear/unifiedpush/unifiedpush-server/0.10.0/ >>> >>> >>> If they aren't any objections or remarks I will release the bits to >>> maven central on Monday morning >>> >>> -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 >> >> >> >> _______________________________________________ >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140214/4c12e811/attachment.html From matzew at apache.org Sat Feb 15 06:00:44 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Sat, 15 Feb 2014 12:00:44 +0100 Subject: [aerogear-dev] Second try (was: Re: staging of UnifiedPush Server 0.10.0) Message-ID: Alright, I have included the UI related updates and staged the new WAR file on my private webspace: http://people.apache.org/~matzew/aerogear-staging/org/jboss/aerogear/unifiedpush/unifiedpush-server/0.10.0/ Please give it a shot! If they aren't any objections or major issues, the release to Bintray will happen on Tuesday. PS: this time we have a 0.10.x branch - just in case; after releasing, I will tag that branch ;-) https://github.com/aerogear/aerogear-unifiedpush-server/tree/0.10.x -Matthias On Fri, Feb 14, 2014 at 8:01 PM, Sebastien Blanc wrote: > Yeah I made sure to do pull on the admin master before doing the release > > > On Fri, Feb 14, 2014 at 7:52 PM, Lucas Holmquist wrote: > >> >> On Feb 14, 2014, at 1:50 PM, Matthias Wessendorf >> wrote: >> >> >> >> >> On Fri, Feb 14, 2014 at 7:42 PM, Lucas Holmquist wrote: >> >>> >>> On Feb 14, 2014, at 12:28 PM, Sebastien Blanc >>> wrote: >>> >>> Hi, >>> I just give it a test , it deploys well and works but ... >>> Looking at the Admin UI, it stills mention 0.10.0-SNAPSHOT in the title, >>> that should be fixed. >>> >>> The latest UI update on UPS is from 14/01, would not hurt to make >>> another UI release to be integrated in UPS to be sure we miss no UI fixes >>> in the release. >>> >>> I can do the PR if you are okay ? >>> >>> good idea since ember just released a security fix >>> >>> >> is that included here ? >> >> https://github.com/aerogear/aerogear-unifiedpush-server/pull/132/files >> >> >> sho is >> >> >> -M >> >> >> >>> >>> Seb >>> >>> >>> >>> On Thu, Feb 13, 2014 at 8:13 PM, Matthias Wessendorf wrote: >>> >>>> Hello, >>>> >>>> for the upcoming release we fixed several tickets: >>>> https://issues.jboss.org/browse/AGPUSH/fixforversion/12321876 >>>> >>>> Before finishing the release, let's see if there are issues w/ the >>>> server, hence I have staged the WAR file on my private webspace: >>>> >>>> >>>> >>>> http://people.apache.org/~matzew/aerogear-staging/org/jboss/aerogear/unifiedpush/unifiedpush-server/0.10.0/ >>>> >>>> >>>> If they aren't any objections or remarks I will release the bits to >>>> maven central on Monday morning >>>> >>>> -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 >>> >>> >>> >>> _______________________________________________ >>> 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 >> > > > _______________________________________________ > 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/20140215/f545b83a/attachment.html From matzew at apache.org Sat Feb 15 08:24:53 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Sat, 15 Feb 2014 14:24:53 +0100 Subject: [aerogear-dev] Xcode Template - version updates Message-ID: Hello, since some iOS releases are coming up, I started a branch ([1]) to bump up all the affected versions! The update for the iOS Push registration SDK is already available on that branch. -Matthias [1] https://github.com/aerogear/aerogear-ios-xcode-template/tree/BumpDependenciesToNext -- 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/20140215/5f73bfc0/attachment-0001.html From scm.blanc at gmail.com Sat Feb 15 13:27:26 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Sat, 15 Feb 2014 19:27:26 +0100 Subject: [aerogear-dev] Second try (was: Re: staging of UnifiedPush Server 0.10.0) In-Reply-To: References: Message-ID: +1 , deployed and tested ! On Sat, Feb 15, 2014 at 12:00 PM, Matthias Wessendorf wrote: > Alright, I have included the UI related updates and staged the new WAR > file on my private webspace: > > > > http://people.apache.org/~matzew/aerogear-staging/org/jboss/aerogear/unifiedpush/unifiedpush-server/0.10.0/ > > > Please give it a shot! > > If they aren't any objections or major issues, the release to Bintray will > happen on Tuesday. > > PS: this time we have a 0.10.x branch - just in case; after releasing, I > will tag that branch ;-) > https://github.com/aerogear/aerogear-unifiedpush-server/tree/0.10.x > > > -Matthias > > > On Fri, Feb 14, 2014 at 8:01 PM, Sebastien Blanc wrote: > >> Yeah I made sure to do pull on the admin master before doing the release >> >> >> On Fri, Feb 14, 2014 at 7:52 PM, Lucas Holmquist wrote: >> >>> >>> On Feb 14, 2014, at 1:50 PM, Matthias Wessendorf >>> wrote: >>> >>> >>> >>> >>> On Fri, Feb 14, 2014 at 7:42 PM, Lucas Holmquist wrote: >>> >>>> >>>> On Feb 14, 2014, at 12:28 PM, Sebastien Blanc >>>> wrote: >>>> >>>> Hi, >>>> I just give it a test , it deploys well and works but ... >>>> Looking at the Admin UI, it stills mention 0.10.0-SNAPSHOT in the >>>> title, that should be fixed. >>>> >>>> The latest UI update on UPS is from 14/01, would not hurt to make >>>> another UI release to be integrated in UPS to be sure we miss no UI fixes >>>> in the release. >>>> >>>> I can do the PR if you are okay ? >>>> >>>> good idea since ember just released a security fix >>>> >>>> >>> is that included here ? >>> >>> https://github.com/aerogear/aerogear-unifiedpush-server/pull/132/files >>> >>> >>> sho is >>> >>> >>> -M >>> >>> >>> >>>> >>>> Seb >>>> >>>> >>>> >>>> On Thu, Feb 13, 2014 at 8:13 PM, Matthias Wessendorf >>> > wrote: >>>> >>>>> Hello, >>>>> >>>>> for the upcoming release we fixed several tickets: >>>>> https://issues.jboss.org/browse/AGPUSH/fixforversion/12321876 >>>>> >>>>> Before finishing the release, let's see if there are issues w/ the >>>>> server, hence I have staged the WAR file on my private webspace: >>>>> >>>>> >>>>> >>>>> http://people.apache.org/~matzew/aerogear-staging/org/jboss/aerogear/unifiedpush/unifiedpush-server/0.10.0/ >>>>> >>>>> >>>>> If they aren't any objections or remarks I will release the bits to >>>>> maven central on Monday morning >>>>> >>>>> -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 >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 >>> >> >> >> _______________________________________________ >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140215/2f294276/attachment.html From scm.blanc at gmail.com Sun Feb 16 08:01:52 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Sun, 16 Feb 2014 14:01:52 +0100 Subject: [aerogear-dev] unifiedpush-java-client (0.5.0) In-Reply-To: References: Message-ID: +1 tested with AeroDoc On Thu, Feb 13, 2014 at 5:13 PM, Matthias Wessendorf wrote: > Hi Folks, > > I'm happy to announce the a new version of the 'unifiedpush-java-client' > (0.5.0) has been staged. > > > https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-2601/ > > Here is the changelog : > * Adding unit tests for untested builder methods > * Adding content-available builder + unit tests (support of iOS7 silent > messages on the builder) > * fix groupId and artifactId > > > If they aren't any objections or remarks I will release the bits to maven > central on Monday morning > > > -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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140216/e0c00ee5/attachment.html From matzew at apache.org Sun Feb 16 13:06:54 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Sun, 16 Feb 2014 19:06:54 +0100 Subject: [aerogear-dev] AeroDoc: Show/Send leads - Geo map not showing agents near-by ? Message-ID: Hi, I tried to play w/ the Geo support on AeroDoc, but there are some issues. After I noticed that only 'john' (the admin) (see [1]) is able to update the log/lat data, I was wondering about the next thing: Does the map show where 'agents' are? (by lat/long?) I am not seeing an agent on my map: http://people.apache.org/~matzew/geo-map.png My long/lat values are OUTSIDE of that given radius (how can I change the radius), but my location is INSIDE of the visible map. Since a map is shown on that 'send leads' page, I was hoping to actually see a mark for my location. Or is this just not supported, atm ? Greetings, Matthias [1] https://issues.jboss.org/browse/AGPUSH-535 -- 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/20140216/aedbe028/attachment.html From matzew at apache.org Mon Feb 17 01:23:01 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 17 Feb 2014 07:23:01 +0100 Subject: [aerogear-dev] [aerogear-issues] Update In-Reply-To: References: Message-ID: Hello Miguel, forwarding this to our developer list (see [1]). Feel free to subscribe to it. Looking at your stacktrace, I think the problem here is that you are not using the https scheme (02-16 15:51:30.899: E/HttpRestProvider(21213): Error on POST of http://aerogear-metalpush.rhcloud.com/rest/registry/device) when posting to http, the server does a redirect (302) to the https scheme, looks like this is not understood by our Android library. Can you try the same registration process, but instead using https ( https://aerogear-metalpush.rhcloud.com ) ? Greetings, Matthias [1] https://lists.jboss.org/mailman/listinfo/aerogear-dev On Sun, Feb 16, 2014 at 5:25 PM, Miguel Lemos wrote: > Dear all, > > I made an update to your last library version and I get the same errors. > My app uses Cordova 3.3 and the device where I test the plugin runs > Android 4.1. > > I attach a small logcat file where is summarized what makes the app not > register (?) to the service. > > The errorHandler function, as I said before, throws this error: > > java.io.IOException:BufferedinputStream is closed > > The app itself keeps running, though... > I appreciate any help because I don't know what else I can do. > > A thing I noticed: > > Inside the Aerogear Console, where is the Android Variant with all data, > the table that describes the Token, Device, etc, is empty. I presume it's > only filled the first time the device manages to register, or else...? > > I think your solution is very promising and makes the right approach to a > real problem, but i must manage to make it work :-( > > Thanks again > > Miguel > > _______________________________________________ > aerogear-issues mailing list > aerogear-issues at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-issues > -- 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/20140217/b650da99/attachment-0001.html From matzew at apache.org Mon Feb 17 01:27:44 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 17 Feb 2014 07:27:44 +0100 Subject: [aerogear-dev] [aerogear-issues] Update In-Reply-To: References: Message-ID: Miguel, note the redirect to https is only on OpenShift - on you local machine, all stays http -M On Mon, Feb 17, 2014 at 7:23 AM, Matthias Wessendorf wrote: > Hello Miguel, > > forwarding this to our developer list (see [1]). Feel free to subscribe to > it. > > > Looking at your stacktrace, I think the problem here is that you are not > using the https scheme > (02-16 15:51:30.899: E/HttpRestProvider(21213): Error on POST of > http://aerogear-metalpush.rhcloud.com/rest/registry/device) > > when posting to http, the server does a redirect (302) to the https > scheme, looks like this is not understood by our Android library. > > Can you try the same registration process, but instead using https ( > https://aerogear-metalpush.rhcloud.com ) ? > > Greetings, > Matthias > > > > [1] https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > On Sun, Feb 16, 2014 at 5:25 PM, Miguel Lemos wrote: > >> Dear all, >> >> I made an update to your last library version and I get the same errors. >> My app uses Cordova 3.3 and the device where I test the plugin runs >> Android 4.1. >> >> I attach a small logcat file where is summarized what makes the app not >> register (?) to the service. >> >> The errorHandler function, as I said before, throws this error: >> >> java.io.IOException:BufferedinputStream is closed >> >> The app itself keeps running, though... >> I appreciate any help because I don't know what else I can do. >> >> A thing I noticed: >> >> Inside the Aerogear Console, where is the Android Variant with all data, >> the table that describes the Token, Device, etc, is empty. I presume it's >> only filled the first time the device manages to register, or else...? >> >> I think your solution is very promising and makes the right approach to a >> real problem, but i must manage to make it work :-( >> >> Thanks again >> >> Miguel >> >> _______________________________________________ >> aerogear-issues mailing list >> aerogear-issues at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-issues >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > -- 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/20140217/1f2f4575/attachment.html From edewit at redhat.com Mon Feb 17 02:20:28 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Mon, 17 Feb 2014 08:20:28 +0100 Subject: [aerogear-dev] AeroDoc: Show/Send leads - Geo map not showing agents near-by ? In-Reply-To: References: Message-ID: On 16 Feb,2014, at 19:06 , Matthias Wessendorf wrote: > Hi, > > I tried to play w/ the Geo support on AeroDoc, but there are some issues. > > After I noticed that only 'john' (the admin) (see [1]) is able to update the log/lat data, I was wondering about the next thing: Does the map show where 'agents' are? (by lat/long?) Didn?t change the security setting, guess it was always the case that only admins can update. If that is wrong we should change that. > > > I am not seeing an agent on my map: > http://people.apache.org/~matzew/geo-map.png > That is not supported at the moment. > My long/lat values are OUTSIDE of that given radius (how can I change the radius), but my location is INSIDE of the visible map. You click the radius and drag the handle (little circle on the bottom right) to increase the radius. > > Since a map is shown on that 'send leads' page, I was hoping to actually see a mark for my location. Or is this just not supported, atm ? right not supported, the idea is that you search sales agents that are within the radius and send them the lead. > > Greetings, > Matthias > > > [1] https://issues.jboss.org/browse/AGPUSH-535 > > -- > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140217/c00484cf/attachment.html From matzew at apache.org Mon Feb 17 02:42:48 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 17 Feb 2014 08:42:48 +0100 Subject: [aerogear-dev] AeroDoc: Show/Send leads - Geo map not showing agents near-by ? In-Reply-To: References: Message-ID: On Mon, Feb 17, 2014 at 8:20 AM, Erik Jan de Wit wrote: > > On 16 Feb,2014, at 19:06 , Matthias Wessendorf wrote: > > Hi, > > I tried to play w/ the Geo support on AeroDoc, but there are some issues. > > After I noticed that only 'john' (the admin) (see [1]) is able to update > the log/lat data, I was wondering about the next thing: Does the map show > where 'agents' are? (by lat/long?) > > > Didn't change the security setting, guess it was always the case that only > admins can update. If that is wrong we should change that. > Hrm, ok - perhaps Sebi knows more > > > > I am not seeing an agent on my map: > http://people.apache.org/~matzew/geo-map.png > > That is not supported at the moment. > Too bad ;-) Would be a nice feature :-) > > > My long/lat values are OUTSIDE of that given radius (how can I change the > radius), but my location is INSIDE of the visible map. > > > You click the radius and drag the handle (little circle on the bottom > right) to increase the radius. > Ahhh!!!!! :-) I noticed that yesterday night :-) Almost an easter egg :-) pretty good hidden :) But I guess that's due to the map we use, right ? > > > Since a map is shown on that 'send leads' page, I was hoping to actually > see a mark for my location. Or is this just not supported, atm ? > > > right not supported, the idea is that you search sales agents that are > within the radius and send them the lead. > Not sure that works :-) I added a lead in San Francisco, and had my agent use my coordinates. I updated the radius (increased by a few meters), than I think the search results updated, but john (location data: Germany, Emsdetten) was showing up :-) > > > Greetings, > Matthias > > > [1] https://issues.jboss.org/browse/AGPUSH-535 > > -- > 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/20140217/5c5be209/attachment.html From scm.blanc at gmail.com Mon Feb 17 02:47:27 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Mon, 17 Feb 2014 08:47:27 +0100 Subject: [aerogear-dev] AeroDoc: Show/Send leads - Geo map not showing agents near-by ? In-Reply-To: References: Message-ID: On Mon, Feb 17, 2014 at 8:42 AM, Matthias Wessendorf wrote: > > > > On Mon, Feb 17, 2014 at 8:20 AM, Erik Jan de Wit wrote: > >> >> On 16 Feb,2014, at 19:06 , Matthias Wessendorf wrote: >> >> Hi, >> >> I tried to play w/ the Geo support on AeroDoc, but there are some issues. >> >> After I noticed that only 'john' (the admin) (see [1]) is able to update >> the log/lat data, I was wondering about the next thing: Does the map show >> where 'agents' are? (by lat/long?) >> >> >> Didn't change the security setting, guess it was always the case that >> only admins can update. If that is wrong we should change that. >> > > Hrm, ok - perhaps Sebi knows more > Yeah, that is because of this https://github.com/aerogear/aerogear-aerodoc-backend/blob/master/src/main/java/org/jboss/aerogear/aerodoc/rest/SaleAgentEndpoint.java#L59 We should just override the update method with @Secure("simple") > >> >> >> I am not seeing an agent on my map: >> http://people.apache.org/~matzew/geo-map.png >> >> That is not supported at the moment. >> > > Too bad ;-) Would be a nice feature :-) > > >> >> >> My long/lat values are OUTSIDE of that given radius (how can I change the >> radius), but my location is INSIDE of the visible map. >> >> >> You click the radius and drag the handle (little circle on the bottom >> right) to increase the radius. >> > > Ahhh!!!!! :-) I noticed that yesterday night :-) Almost an easter egg :-) > pretty good hidden :) But I guess that's due to the map we use, right ? > Yeah, the handle is not very visible in the first place, Erik, could we change the style of this handle (more contrast, other color?) > > >> >> >> Since a map is shown on that 'send leads' page, I was hoping to actually >> see a mark for my location. Or is this just not supported, atm ? >> >> >> right not supported, the idea is that you search sales agents that are >> within the radius and send them the lead. >> > > Not sure that works :-) > > I added a lead in San Francisco, and had my agent use my coordinates. I > updated the radius (increased by a few meters), than I think the search > results updated, but john (location data: Germany, Emsdetten) was showing > up :-) > > > > >> >> >> Greetings, >> Matthias >> >> >> [1] https://issues.jboss.org/browse/AGPUSH-535 >> >> -- >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140217/bac72dea/attachment-0001.html From matzew at apache.org Mon Feb 17 02:53:38 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 17 Feb 2014 08:53:38 +0100 Subject: [aerogear-dev] AeroDoc: Show/Send leads - Geo map not showing agents near-by ? In-Reply-To: References: Message-ID: On Mon, Feb 17, 2014 at 8:47 AM, Sebastien Blanc wrote: > > > > On Mon, Feb 17, 2014 at 8:42 AM, Matthias Wessendorf wrote: > >> >> >> >> On Mon, Feb 17, 2014 at 8:20 AM, Erik Jan de Wit wrote: >> >>> >>> On 16 Feb,2014, at 19:06 , Matthias Wessendorf >>> wrote: >>> >>> Hi, >>> >>> I tried to play w/ the Geo support on AeroDoc, but there are some issues. >>> >>> After I noticed that only 'john' (the admin) (see [1]) is able to update >>> the log/lat data, I was wondering about the next thing: Does the map show >>> where 'agents' are? (by lat/long?) >>> >>> >>> Didn't change the security setting, guess it was always the case that >>> only admins can update. If that is wrong we should change that. >>> >> >> Hrm, ok - perhaps Sebi knows more >> > Yeah, that is because of this > https://github.com/aerogear/aerogear-aerodoc-backend/blob/master/src/main/java/org/jboss/aerogear/aerodoc/rest/SaleAgentEndpoint.java#L59 > We should just override the update method with @Secure("simple") > You might wanna see here: https://github.com/aerogear/aerogear-aerodoc-backend/blob/master/src/main/java/org/jboss/aerogear/aerodoc/rest/SaleAgentEndpoint.java#L115 > >>> >>> >>> I am not seeing an agent on my map: >>> http://people.apache.org/~matzew/geo-map.png >>> >>> That is not supported at the moment. >>> >> >> Too bad ;-) Would be a nice feature :-) >> >> >>> >>> >>> My long/lat values are OUTSIDE of that given radius (how can I change >>> the radius), but my location is INSIDE of the visible map. >>> >>> >>> You click the radius and drag the handle (little circle on the bottom >>> right) to increase the radius. >>> >> >> Ahhh!!!!! :-) I noticed that yesterday night :-) Almost an easter egg :-) >> pretty good hidden :) But I guess that's due to the map we use, right ? >> > > Yeah, the handle is not very visible in the first place, Erik, could we > change the style of this handle (more contrast, other color?) > >> >> >>> >>> >>> Since a map is shown on that 'send leads' page, I was hoping to actually >>> see a mark for my location. Or is this just not supported, atm ? >>> >>> >>> right not supported, the idea is that you search sales agents that are >>> within the radius and send them the lead. >>> >> >> Not sure that works :-) >> >> I added a lead in San Francisco, and had my agent use my coordinates. I >> updated the radius (increased by a few meters), than I think the search >> results updated, but john (location data: Germany, Emsdetten) was showing >> up :-) >> >> >> >> >>> >>> >>> Greetings, >>> Matthias >>> >>> >>> [1] https://issues.jboss.org/browse/AGPUSH-535 >>> >>> -- >>> 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/20140217/bfc2205e/attachment.html From scm.blanc at gmail.com Mon Feb 17 02:57:30 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Mon, 17 Feb 2014 08:57:30 +0100 Subject: [aerogear-dev] AeroDoc: Show/Send leads - Geo map not showing agents near-by ? In-Reply-To: References: Message-ID: On Mon, Feb 17, 2014 at 8:53 AM, Matthias Wessendorf wrote: > > > > On Mon, Feb 17, 2014 at 8:47 AM, Sebastien Blanc wrote: > >> >> >> >> On Mon, Feb 17, 2014 at 8:42 AM, Matthias Wessendorf wrote: >> >>> >>> >>> >>> On Mon, Feb 17, 2014 at 8:20 AM, Erik Jan de Wit wrote: >>> >>>> >>>> On 16 Feb,2014, at 19:06 , Matthias Wessendorf >>>> wrote: >>>> >>>> Hi, >>>> >>>> I tried to play w/ the Geo support on AeroDoc, but there are some >>>> issues. >>>> >>>> After I noticed that only 'john' (the admin) (see [1]) is able to >>>> update the log/lat data, I was wondering about the next thing: Does the map >>>> show where 'agents' are? (by lat/long?) >>>> >>>> >>>> Didn't change the security setting, guess it was always the case that >>>> only admins can update. If that is wrong we should change that. >>>> >>> >>> Hrm, ok - perhaps Sebi knows more >>> >> Yeah, that is because of this >> https://github.com/aerogear/aerogear-aerodoc-backend/blob/master/src/main/java/org/jboss/aerogear/aerodoc/rest/SaleAgentEndpoint.java#L59 >> We should just override the update method with @Secure("simple") >> > > You might wanna see here: > > https://github.com/aerogear/aerogear-aerodoc-backend/blob/master/src/main/java/org/jboss/aerogear/aerodoc/rest/SaleAgentEndpoint.java#L115 > Doh ! I'm probably not enough wake up :) Ok but then we should maybe flip the coin and protect the class with "simple" and override the "admin" ones with "admin". > > > >> >>>> >>>> >>>> I am not seeing an agent on my map: >>>> http://people.apache.org/~matzew/geo-map.png >>>> >>>> That is not supported at the moment. >>>> >>> >>> Too bad ;-) Would be a nice feature :-) >>> >>> >>>> >>>> >>>> My long/lat values are OUTSIDE of that given radius (how can I change >>>> the radius), but my location is INSIDE of the visible map. >>>> >>>> >>>> You click the radius and drag the handle (little circle on the bottom >>>> right) to increase the radius. >>>> >>> >>> Ahhh!!!!! :-) I noticed that yesterday night :-) Almost an easter egg >>> :-) pretty good hidden :) But I guess that's due to the map we use, right ? >>> >> >> Yeah, the handle is not very visible in the first place, Erik, could we >> change the style of this handle (more contrast, other color?) >> >>> >>> >>>> >>>> >>>> Since a map is shown on that 'send leads' page, I was hoping to >>>> actually see a mark for my location. Or is this just not supported, atm ? >>>> >>>> >>>> right not supported, the idea is that you search sales agents that are >>>> within the radius and send them the lead. >>>> >>> >>> Not sure that works :-) >>> >>> I added a lead in San Francisco, and had my agent use my coordinates. I >>> updated the radius (increased by a few meters), than I think the search >>> results updated, but john (location data: Germany, Emsdetten) was showing >>> up :-) >>> >>> >>> >>> >>>> >>>> >>>> Greetings, >>>> Matthias >>>> >>>> >>>> [1] https://issues.jboss.org/browse/AGPUSH-535 >>>> >>>> -- >>>> 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 > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140217/ed5ae2c8/attachment-0001.html From matzew at apache.org Mon Feb 17 03:00:54 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 17 Feb 2014 09:00:54 +0100 Subject: [aerogear-dev] AeroDoc: Show/Send leads - Geo map not showing agents near-by ? In-Reply-To: References: Message-ID: On Mon, Feb 17, 2014 at 8:57 AM, Sebastien Blanc wrote: > > > > On Mon, Feb 17, 2014 at 8:53 AM, Matthias Wessendorf wrote: > >> >> >> >> On Mon, Feb 17, 2014 at 8:47 AM, Sebastien Blanc wrote: >> >>> >>> >>> >>> On Mon, Feb 17, 2014 at 8:42 AM, Matthias Wessendorf wrote: >>> >>>> >>>> >>>> >>>> On Mon, Feb 17, 2014 at 8:20 AM, Erik Jan de Wit wrote: >>>> >>>>> >>>>> On 16 Feb,2014, at 19:06 , Matthias Wessendorf >>>>> wrote: >>>>> >>>>> Hi, >>>>> >>>>> I tried to play w/ the Geo support on AeroDoc, but there are some >>>>> issues. >>>>> >>>>> After I noticed that only 'john' (the admin) (see [1]) is able to >>>>> update the log/lat data, I was wondering about the next thing: Does the map >>>>> show where 'agents' are? (by lat/long?) >>>>> >>>>> >>>>> Didn't change the security setting, guess it was always the case that >>>>> only admins can update. If that is wrong we should change that. >>>>> >>>> >>>> Hrm, ok - perhaps Sebi knows more >>>> >>> Yeah, that is because of this >>> https://github.com/aerogear/aerogear-aerodoc-backend/blob/master/src/main/java/org/jboss/aerogear/aerodoc/rest/SaleAgentEndpoint.java#L59 >>> We should just override the update method with @Secure("simple") >>> >> >> You might wanna see here: >> >> https://github.com/aerogear/aerogear-aerodoc-backend/blob/master/src/main/java/org/jboss/aerogear/aerodoc/rest/SaleAgentEndpoint.java#L115 >> > > Doh ! I'm probably not enough wake up :) > Ok but then we should maybe flip the coin and protect the class with > "simple" and override the "admin" ones with "admin". > well, shouldn't it just work, w/ the override ? Let's first investigate if the source is really a bug, versus a wrong usage -< > > >> >> >> >>> >>>>> >>>>> >>>>> I am not seeing an agent on my map: >>>>> http://people.apache.org/~matzew/geo-map.png >>>>> >>>>> That is not supported at the moment. >>>>> >>>> >>>> Too bad ;-) Would be a nice feature :-) >>>> >>>> >>>>> >>>>> >>>>> My long/lat values are OUTSIDE of that given radius (how can I change >>>>> the radius), but my location is INSIDE of the visible map. >>>>> >>>>> >>>>> You click the radius and drag the handle (little circle on the bottom >>>>> right) to increase the radius. >>>>> >>>> >>>> Ahhh!!!!! :-) I noticed that yesterday night :-) Almost an easter egg >>>> :-) pretty good hidden :) But I guess that's due to the map we use, right ? >>>> >>> >>> Yeah, the handle is not very visible in the first place, Erik, could we >>> change the style of this handle (more contrast, other color?) >>> >>>> >>>> >>>>> >>>>> >>>>> Since a map is shown on that 'send leads' page, I was hoping to >>>>> actually see a mark for my location. Or is this just not supported, atm ? >>>>> >>>>> >>>>> right not supported, the idea is that you search sales agents that are >>>>> within the radius and send them the lead. >>>>> >>>> >>>> Not sure that works :-) >>>> >>>> I added a lead in San Francisco, and had my agent use my coordinates. I >>>> updated the radius (increased by a few meters), than I think the search >>>> results updated, but john (location data: Germany, Emsdetten) was showing >>>> up :-) >>>> >>>> >>>> >>>> >>>>> >>>>> >>>>> Greetings, >>>>> Matthias >>>>> >>>>> >>>>> [1] https://issues.jboss.org/browse/AGPUSH-535 >>>>> >>>>> -- >>>>> 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 >> >> _______________________________________________ >> 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/20140217/318ac293/attachment.html From scm.blanc at gmail.com Mon Feb 17 03:07:48 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Mon, 17 Feb 2014 09:07:48 +0100 Subject: [aerogear-dev] AeroDoc: Show/Send leads - Geo map not showing agents near-by ? In-Reply-To: References: Message-ID: On Mon, Feb 17, 2014 at 9:00 AM, Matthias Wessendorf wrote: > > > > On Mon, Feb 17, 2014 at 8:57 AM, Sebastien Blanc wrote: > >> >> >> >> On Mon, Feb 17, 2014 at 8:53 AM, Matthias Wessendorf wrote: >> >>> >>> >>> >>> On Mon, Feb 17, 2014 at 8:47 AM, Sebastien Blanc wrote: >>> >>>> >>>> >>>> >>>> On Mon, Feb 17, 2014 at 8:42 AM, Matthias Wessendorf >>> > wrote: >>>> >>>>> >>>>> >>>>> >>>>> On Mon, Feb 17, 2014 at 8:20 AM, Erik Jan de Wit wrote: >>>>> >>>>>> >>>>>> On 16 Feb,2014, at 19:06 , Matthias Wessendorf >>>>>> wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> I tried to play w/ the Geo support on AeroDoc, but there are some >>>>>> issues. >>>>>> >>>>>> After I noticed that only 'john' (the admin) (see [1]) is able to >>>>>> update the log/lat data, I was wondering about the next thing: Does the map >>>>>> show where 'agents' are? (by lat/long?) >>>>>> >>>>>> >>>>>> Didn't change the security setting, guess it was always the case that >>>>>> only admins can update. If that is wrong we should change that. >>>>>> >>>>> >>>>> Hrm, ok - perhaps Sebi knows more >>>>> >>>> Yeah, that is because of this >>>> https://github.com/aerogear/aerogear-aerodoc-backend/blob/master/src/main/java/org/jboss/aerogear/aerodoc/rest/SaleAgentEndpoint.java#L59 >>>> We should just override the update method with @Secure("simple") >>>> >>> >>> You might wanna see here: >>> >>> https://github.com/aerogear/aerogear-aerodoc-backend/blob/master/src/main/java/org/jboss/aerogear/aerodoc/rest/SaleAgentEndpoint.java#L115 >>> >> >> Doh ! I'm probably not enough wake up :) >> Ok but then we should maybe flip the coin and protect the class with >> "simple" and override the "admin" ones with "admin". >> > > well, shouldn't it just work, w/ the override ? Let's first investigate if > the source is really a bug, versus a wrong usage > Abstractj should confirm, but the override is not working this way, looking at https://github.com/aerogear/aerogear-security/blob/master/src/main/java/org/jboss/aerogear/security/interceptor/SecurityInterceptor.java#L54 it first validates on class level before looking at the method and an Exception will be thrown before it looks at the method annotation. > > -< > > >> >> >>> >>> >>> >>>> >>>>>> >>>>>> >>>>>> I am not seeing an agent on my map: >>>>>> http://people.apache.org/~matzew/geo-map.png >>>>>> >>>>>> That is not supported at the moment. >>>>>> >>>>> >>>>> Too bad ;-) Would be a nice feature :-) >>>>> >>>>> >>>>>> >>>>>> >>>>>> My long/lat values are OUTSIDE of that given radius (how can I change >>>>>> the radius), but my location is INSIDE of the visible map. >>>>>> >>>>>> >>>>>> You click the radius and drag the handle (little circle on the bottom >>>>>> right) to increase the radius. >>>>>> >>>>> >>>>> Ahhh!!!!! :-) I noticed that yesterday night :-) Almost an easter egg >>>>> :-) pretty good hidden :) But I guess that's due to the map we use, right ? >>>>> >>>> >>>> Yeah, the handle is not very visible in the first place, Erik, could we >>>> change the style of this handle (more contrast, other color?) >>>> >>>>> >>>>> >>>>>> >>>>>> >>>>>> Since a map is shown on that 'send leads' page, I was hoping to >>>>>> actually see a mark for my location. Or is this just not supported, atm ? >>>>>> >>>>>> >>>>>> right not supported, the idea is that you search sales agents that >>>>>> are within the radius and send them the lead. >>>>>> >>>>> >>>>> Not sure that works :-) >>>>> >>>>> I added a lead in San Francisco, and had my agent use my coordinates. >>>>> I updated the radius (increased by a few meters), than I think the search >>>>> results updated, but john (location data: Germany, Emsdetten) was showing >>>>> up :-) >>>>> >>>>> >>>>> >>>>> >>>>>> >>>>>> >>>>>> Greetings, >>>>>> Matthias >>>>>> >>>>>> >>>>>> [1] https://issues.jboss.org/browse/AGPUSH-535 >>>>>> >>>>>> -- >>>>>> 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 >>> >>> _______________________________________________ >>> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140217/17ba9c03/attachment-0001.html From matzew at apache.org Mon Feb 17 03:12:25 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 17 Feb 2014 09:12:25 +0100 Subject: [aerogear-dev] AeroDoc: Show/Send leads - Geo map not showing agents near-by ? In-Reply-To: References: Message-ID: On Mon, Feb 17, 2014 at 9:07 AM, Sebastien Blanc wrote: > > > > On Mon, Feb 17, 2014 at 9:00 AM, Matthias Wessendorf wrote: > >> >> >> >> On Mon, Feb 17, 2014 at 8:57 AM, Sebastien Blanc wrote: >> >>> >>> >>> >>> On Mon, Feb 17, 2014 at 8:53 AM, Matthias Wessendorf wrote: >>> >>>> >>>> >>>> >>>> On Mon, Feb 17, 2014 at 8:47 AM, Sebastien Blanc wrote: >>>> >>>>> >>>>> >>>>> >>>>> On Mon, Feb 17, 2014 at 8:42 AM, Matthias Wessendorf < >>>>> matzew at apache.org> wrote: >>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Mon, Feb 17, 2014 at 8:20 AM, Erik Jan de Wit wrote: >>>>>> >>>>>>> >>>>>>> On 16 Feb,2014, at 19:06 , Matthias Wessendorf >>>>>>> wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I tried to play w/ the Geo support on AeroDoc, but there are some >>>>>>> issues. >>>>>>> >>>>>>> After I noticed that only 'john' (the admin) (see [1]) is able to >>>>>>> update the log/lat data, I was wondering about the next thing: Does the map >>>>>>> show where 'agents' are? (by lat/long?) >>>>>>> >>>>>>> >>>>>>> Didn't change the security setting, guess it was always the case >>>>>>> that only admins can update. If that is wrong we should change that. >>>>>>> >>>>>> >>>>>> Hrm, ok - perhaps Sebi knows more >>>>>> >>>>> Yeah, that is because of this >>>>> https://github.com/aerogear/aerogear-aerodoc-backend/blob/master/src/main/java/org/jboss/aerogear/aerodoc/rest/SaleAgentEndpoint.java#L59 >>>>> We should just override the update method with @Secure("simple") >>>>> >>>> >>>> You might wanna see here: >>>> >>>> https://github.com/aerogear/aerogear-aerodoc-backend/blob/master/src/main/java/org/jboss/aerogear/aerodoc/rest/SaleAgentEndpoint.java#L115 >>>> >>> >>> Doh ! I'm probably not enough wake up :) >>> Ok but then we should maybe flip the coin and protect the class with >>> "simple" and override the "admin" ones with "admin". >>> >> >> well, shouldn't it just work, w/ the override ? Let's first investigate >> if the source is really a bug, versus a wrong usage >> > > Abstractj should confirm, but the override is not working this way, > looking at > https://github.com/aerogear/aerogear-security/blob/master/src/main/java/org/jboss/aerogear/security/interceptor/SecurityInterceptor.java#L54 it > first validates on class level before looking at the method and an > Exception will be thrown before it looks at the method annotation. > I see - sounds like incorrect usage on our demo application, in that case > > >> >> -< >> >> >>> >>> >>>> >>>> >>>> >>>>> >>>>>>> >>>>>>> >>>>>>> I am not seeing an agent on my map: >>>>>>> http://people.apache.org/~matzew/geo-map.png >>>>>>> >>>>>>> That is not supported at the moment. >>>>>>> >>>>>> >>>>>> Too bad ;-) Would be a nice feature :-) >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> My long/lat values are OUTSIDE of that given radius (how can I >>>>>>> change the radius), but my location is INSIDE of the visible map. >>>>>>> >>>>>>> >>>>>>> You click the radius and drag the handle (little circle on the >>>>>>> bottom right) to increase the radius. >>>>>>> >>>>>> >>>>>> Ahhh!!!!! :-) I noticed that yesterday night :-) Almost an easter egg >>>>>> :-) pretty good hidden :) But I guess that's due to the map we use, right ? >>>>>> >>>>> >>>>> Yeah, the handle is not very visible in the first place, Erik, could >>>>> we change the style of this handle (more contrast, other color?) >>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> Since a map is shown on that 'send leads' page, I was hoping to >>>>>>> actually see a mark for my location. Or is this just not supported, atm ? >>>>>>> >>>>>>> >>>>>>> right not supported, the idea is that you search sales agents that >>>>>>> are within the radius and send them the lead. >>>>>>> >>>>>> >>>>>> Not sure that works :-) >>>>>> >>>>>> I added a lead in San Francisco, and had my agent use my coordinates. >>>>>> I updated the radius (increased by a few meters), than I think the search >>>>>> results updated, but john (location data: Germany, Emsdetten) was showing >>>>>> up :-) >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> Greetings, >>>>>>> Matthias >>>>>>> >>>>>>> >>>>>>> [1] https://issues.jboss.org/browse/AGPUSH-535 >>>>>>> >>>>>>> -- >>>>>>> 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 >>>> >>>> _______________________________________________ >>>> 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/20140217/9ab42618/attachment.html From matzew at apache.org Mon Feb 17 04:31:19 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 17 Feb 2014 10:31:19 +0100 Subject: [aerogear-dev] [aerogear-issues] Update In-Reply-To: References: Message-ID: Got a reply from Miguel: Hi Matthias, I tried the https and I managed to connect! Geat. The funny part of the whole thing is that I always used the https:// but with the simplepush string... Yes, I'll join the mailing list. based on that (and the earlier provided stack trace), I filed this ticket: https://issues.jboss.org/browse/AGDROID-214 On Mon, Feb 17, 2014 at 7:27 AM, Matthias Wessendorf wrote: > Miguel, note the redirect to https is only on OpenShift - on you local > machine, all stays http > > -M > > > On Mon, Feb 17, 2014 at 7:23 AM, Matthias Wessendorf wrote: > >> Hello Miguel, >> >> forwarding this to our developer list (see [1]). Feel free to subscribe >> to it. >> >> >> Looking at your stacktrace, I think the problem here is that you are not >> using the https scheme >> (02-16 15:51:30.899: E/HttpRestProvider(21213): Error on POST of >> http://aerogear-metalpush.rhcloud.com/rest/registry/device) >> >> when posting to http, the server does a redirect (302) to the https >> scheme, looks like this is not understood by our Android library. >> >> Can you try the same registration process, but instead using https ( >> https://aerogear-metalpush.rhcloud.com ) ? >> >> Greetings, >> Matthias >> >> >> >> [1] https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> On Sun, Feb 16, 2014 at 5:25 PM, Miguel Lemos wrote: >> >>> Dear all, >>> >>> I made an update to your last library version and I get the same >>> errors. >>> My app uses Cordova 3.3 and the device where I test the plugin runs >>> Android 4.1. >>> >>> I attach a small logcat file where is summarized what makes the app not >>> register (?) to the service. >>> >>> The errorHandler function, as I said before, throws this error: >>> >>> java.io.IOException:BufferedinputStream is closed >>> >>> The app itself keeps running, though... >>> I appreciate any help because I don't know what else I can do. >>> >>> A thing I noticed: >>> >>> Inside the Aerogear Console, where is the Android Variant with all data, >>> the table that describes the Token, Device, etc, is empty. I presume it's >>> only filled the first time the device manages to register, or else...? >>> >>> I think your solution is very promising and makes the right approach to >>> a real problem, but i must manage to make it work :-( >>> >>> Thanks again >>> >>> Miguel >>> >>> _______________________________________________ >>> aerogear-issues mailing list >>> aerogear-issues at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-issues >>> >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > -- 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/20140217/a9987d7d/attachment-0001.html From matzew at apache.org Mon Feb 17 04:32:29 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 17 Feb 2014 10:32:29 +0100 Subject: [aerogear-dev] Team meeting agenda for today Message-ID: http://oksoclap.com/p/aerogear-team-mgt-20140217 -M -- 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/20140217/2ac3f0aa/attachment.html From daniel.bevenius at gmail.com Mon Feb 17 06:36:47 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Mon, 17 Feb 2014 12:36:47 +0100 Subject: [aerogear-dev] Team meeting agenda for today In-Reply-To: References: Message-ID: Now this could be just me and my luck with computers the last couple of days, but I can't access the url. Am I the only one? /Dan On 17 February 2014 10:32, Matthias Wessendorf wrote: > http://oksoclap.com/p/aerogear-team-mgt-20140217 > > -M > > -- > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140217/00c31b54/attachment.html From daniel.bevenius at gmail.com Mon Feb 17 06:37:13 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Mon, 17 Feb 2014 12:37:13 +0100 Subject: [aerogear-dev] Team meeting agenda for today In-Reply-To: References: Message-ID: Sorry, worked now. On 17 February 2014 12:36, Daniel Bevenius wrote: > Now this could be just me and my luck with computers the last couple of > days, but I can't access the url. Am I the only one? > > /Dan > > > On 17 February 2014 10:32, Matthias Wessendorf wrote: > >> http://oksoclap.com/p/aerogear-team-mgt-20140217 >> >> -M >> >> -- >> 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 >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140217/fdd752a7/attachment.html From kpiwko at redhat.com Mon Feb 17 07:20:16 2014 From: kpiwko at redhat.com (Karel Piwko) Date: Mon, 17 Feb 2014 13:20:16 +0100 Subject: [aerogear-dev] Second try (was: Re: staging of UnifiedPush Server 0.10.0) In-Reply-To: References: Message-ID: <20140217132016.55245687@kapy-ntb-x220> Hey, there were quite a big API changes in between 0.9.0 and 0.10.0. I hope that we can finish testing Tue evening. The other question is: what is the plan to OpenShift cart? Would there be an update to OpenShift branch? Thanks, Karel On Sat, 15 Feb 2014 12:00:44 +0100 Matthias Wessendorf wrote: > Alright, I have included the UI related updates and staged the new WAR file > on my private webspace: > > > http://people.apache.org/~matzew/aerogear-staging/org/jboss/aerogear/unifiedpush/unifiedpush-server/0.10.0/ > > > Please give it a shot! > > If they aren't any objections or major issues, the release to Bintray will > happen on Tuesday. > > PS: this time we have a 0.10.x branch - just in case; after releasing, I > will tag that branch ;-) > https://github.com/aerogear/aerogear-unifiedpush-server/tree/0.10.x > > > -Matthias > > > On Fri, Feb 14, 2014 at 8:01 PM, Sebastien Blanc wrote: > > > Yeah I made sure to do pull on the admin master before doing the release > > > > > > On Fri, Feb 14, 2014 at 7:52 PM, Lucas Holmquist wrote: > > > >> > >> On Feb 14, 2014, at 1:50 PM, Matthias Wessendorf > >> wrote: > >> > >> > >> > >> > >> On Fri, Feb 14, 2014 at 7:42 PM, Lucas Holmquist > >> wrote: > >> > >>> > >>> On Feb 14, 2014, at 12:28 PM, Sebastien Blanc > >>> wrote: > >>> > >>> Hi, > >>> I just give it a test , it deploys well and works but ... > >>> Looking at the Admin UI, it stills mention 0.10.0-SNAPSHOT in the title, > >>> that should be fixed. > >>> > >>> The latest UI update on UPS is from 14/01, would not hurt to make > >>> another UI release to be integrated in UPS to be sure we miss no UI fixes > >>> in the release. > >>> > >>> I can do the PR if you are okay ? > >>> > >>> good idea since ember just released a security fix > >>> > >>> > >> is that included here ? > >> > >> https://github.com/aerogear/aerogear-unifiedpush-server/pull/132/files > >> > >> > >> sho is > >> > >> > >> -M > >> > >> > >> > >>> > >>> Seb > >>> > >>> > >>> > >>> On Thu, Feb 13, 2014 at 8:13 PM, Matthias Wessendorf > >>> wrote: > >>> > >>>> Hello, > >>>> > >>>> for the upcoming release we fixed several tickets: > >>>> https://issues.jboss.org/browse/AGPUSH/fixforversion/12321876 > >>>> > >>>> Before finishing the release, let's see if there are issues w/ the > >>>> server, hence I have staged the WAR file on my private webspace: > >>>> > >>>> > >>>> > >>>> http://people.apache.org/~matzew/aerogear-staging/org/jboss/aerogear/unifiedpush/unifiedpush-server/0.10.0/ > >>>> > >>>> > >>>> If they aren't any objections or remarks I will release the bits to > >>>> maven central on Monday morning > >>>> > >>>> -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 > >>> > >>> > >>>https://github.com/junit-team/junit/blob/master/src/main/java/org/junit/runners/Parameterized.java > >>> _______________________________________________ > >>> 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 > >> > > > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > From kpiwko at redhat.com Mon Feb 17 07:24:07 2014 From: kpiwko at redhat.com (Karel Piwko) Date: Mon, 17 Feb 2014 13:24:07 +0100 Subject: [aerogear-dev] Xcode Template - version updates In-Reply-To: References: Message-ID: <20140217132407.42e30968@kapy-ntb-x220> On Sat, 15 Feb 2014 14:24:53 +0100 Matthias Wessendorf wrote: > Hello, > > since some iOS releases are coming up, I started a branch ([1]) to bump up > all the affected versions! > > The update for the iOS Push registration SDK is already available on that > branch. > Awesome! Tadeas, can you please make sure that your feedback on the template is included in new version as well? > -Matthias > > [1] > https://github.com/aerogear/aerogear-ios-xcode-template/tree/BumpDependenciesToNext > From matzew at apache.org Mon Feb 17 07:24:37 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 17 Feb 2014 13:24:37 +0100 Subject: [aerogear-dev] Second try (was: Re: staging of UnifiedPush Server 0.10.0) In-Reply-To: <20140217132016.55245687@kapy-ntb-x220> References: <20140217132016.55245687@kapy-ntb-x220> Message-ID: On Mon, Feb 17, 2014 at 1:20 PM, Karel Piwko wrote: > Hey, > > there were quite a big API changes in between 0.9.0 and 0.10.0. I hope > that we > can finish testing Tue evening. > the public api (REST) did not change; Internal code did change, that's right > The other question is: what is the plan to OpenShift cart? Would there be > an > update to OpenShift branch? > Once we have this release up, the next step is around OpenShift > > Thanks, > > Karel > > On Sat, 15 Feb 2014 12:00:44 +0100 > Matthias Wessendorf wrote: > > > Alright, I have included the UI related updates and staged the new WAR > file > > on my private webspace: > > > > > > > http://people.apache.org/~matzew/aerogear-staging/org/jboss/aerogear/unifiedpush/unifiedpush-server/0.10.0/ > > > > > > Please give it a shot! > > > > If they aren't any objections or major issues, the release to Bintray > will > > happen on Tuesday. > > > > PS: this time we have a 0.10.x branch - just in case; after releasing, I > > will tag that branch ;-) > > https://github.com/aerogear/aerogear-unifiedpush-server/tree/0.10.x > > > > > > -Matthias > > > > > > On Fri, Feb 14, 2014 at 8:01 PM, Sebastien Blanc >wrote: > > > > > Yeah I made sure to do pull on the admin master before doing the > release > > > > > > > > > On Fri, Feb 14, 2014 at 7:52 PM, Lucas Holmquist >wrote: > > > > > >> > > >> On Feb 14, 2014, at 1:50 PM, Matthias Wessendorf > > >> wrote: > > >> > > >> > > >> > > >> > > >> On Fri, Feb 14, 2014 at 7:42 PM, Lucas Holmquist > > >> wrote: > > >> > > >>> > > >>> On Feb 14, 2014, at 12:28 PM, Sebastien Blanc > > >>> wrote: > > >>> > > >>> Hi, > > >>> I just give it a test , it deploys well and works but ... > > >>> Looking at the Admin UI, it stills mention 0.10.0-SNAPSHOT in the > title, > > >>> that should be fixed. > > >>> > > >>> The latest UI update on UPS is from 14/01, would not hurt to make > > >>> another UI release to be integrated in UPS to be sure we miss no UI > fixes > > >>> in the release. > > >>> > > >>> I can do the PR if you are okay ? > > >>> > > >>> good idea since ember just released a security fix > > >>> > > >>> > > >> is that included here ? > > >> > > >> > https://github.com/aerogear/aerogear-unifiedpush-server/pull/132/files > > >> > > >> > > >> sho is > > >> > > >> > > >> -M > > >> > > >> > > >> > > >>> > > >>> Seb > > >>> > > >>> > > >>> > > >>> On Thu, Feb 13, 2014 at 8:13 PM, Matthias Wessendorf > > >>> wrote: > > >>> > > >>>> Hello, > > >>>> > > >>>> for the upcoming release we fixed several tickets: > > >>>> https://issues.jboss.org/browse/AGPUSH/fixforversion/12321876 > > >>>> > > >>>> Before finishing the release, let's see if there are issues w/ the > > >>>> server, hence I have staged the WAR file on my private webspace: > > >>>> > > >>>> > > >>>> > > >>>> > http://people.apache.org/~matzew/aerogear-staging/org/jboss/aerogear/unifiedpush/unifiedpush-server/0.10.0/ > > >>>> > > >>>> > > >>>> If they aren't any objections or remarks I will release the bits to > > >>>> maven central on Monday morning > > >>>> > > >>>> -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 > > >>> > > >>> > > >>> > https://github.com/junit-team/junit/blob/master/src/main/java/org/junit/runners/Parameterized.java > > >>> _______________________________________________ > > >>> 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 > > >> > > > > > > > > > _______________________________________________ > > > 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/20140217/11fa4930/attachment-0001.html From matzew at apache.org Mon Feb 17 07:26:53 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 17 Feb 2014 13:26:53 +0100 Subject: [aerogear-dev] Xcode Template - version updates In-Reply-To: <20140217132407.42e30968@kapy-ntb-x220> References: <20140217132407.42e30968@kapy-ntb-x220> Message-ID: On Mon, Feb 17, 2014 at 1:24 PM, Karel Piwko wrote: > On Sat, 15 Feb 2014 14:24:53 +0100 > Matthias Wessendorf wrote: > > > Hello, > > > > since some iOS releases are coming up, I started a branch ([1]) to bump > up > > all the affected versions! > > > > The update for the iOS Push registration SDK is already available on that > > branch. > > > > Awesome! Tadeas, can you please make sure that your feedback on the > template is > included in new version as well? > Please use a separate thread for any feedback (on the template) > > > -Matthias > > > > [1] > > > https://github.com/aerogear/aerogear-ios-xcode-template/tree/BumpDependenciesToNext > > > > _______________________________________________ > 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/20140217/176b8046/attachment.html From cvasilak at gmail.com Mon Feb 17 07:27:49 2014 From: cvasilak at gmail.com (Christos Vasilakis) Date: Mon, 17 Feb 2014 14:27:49 +0200 Subject: [aerogear-dev] Bump up version of aerogear-push-ios-registration In-Reply-To: References: <4401DB10-0C2C-4DE1-9F5F-E9B0C51AE500@gmail.com> Message-ID: <46E46968-34DF-418C-8A29-A9DB2941E56E@gmail.com> fyi, the aerogear-push-ios-registration v0.8.1 small version update has been released to cocoapods to include the AFNetworking update. -, Christos On Feb 14, 2014, at 3:38 PM, Matthias Wessendorf wrote: > +1 > > > On Fri, Feb 14, 2014 at 2:35 PM, Christos Vasilakis wrote: > Hi team, > > since the last 0.8 release of the aerogear-push-ios-registration lib, we have upgraded it to use AFNetworking lib to 1.3.3. Since the release of aerogear-ios has been upgraded too 1.3.3 also, and can depend on push lib, in order to not have problems with the dependency what to you think of bumping up the version of aerogear-push-ios-registration to 0.8.1 and releasing to cocoapods. > > Thoughts? > > Thanks, > Christos > > > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140217/e5f81f80/attachment.html From tkriz at redhat.com Mon Feb 17 07:29:18 2014 From: tkriz at redhat.com (Tadeas Kriz) Date: Mon, 17 Feb 2014 13:29:18 +0100 Subject: [aerogear-dev] Xcode Template - version updates In-Reply-To: References: <20140217132407.42e30968@kapy-ntb-x220> Message-ID: <57CFD7FF-C17A-441F-913C-8135D1A19D84@redhat.com> ? Tadeas Kriz tkriz at redhat.com On 17 Feb 2014, at 13:26, Matthias Wessendorf wrote: > > > > On Mon, Feb 17, 2014 at 1:24 PM, Karel Piwko wrote: > On Sat, 15 Feb 2014 14:24:53 +0100 > Matthias Wessendorf wrote: > > > Hello, > > > > since some iOS releases are coming up, I started a branch ([1]) to bump up > > all the affected versions! > > > > The update for the iOS Push registration SDK is already available on that > > branch. > > > > Awesome! Tadeas, can you please make sure that your feedback on the template is > included in new version as well? > > Please use a separate thread for any feedback (on the template) > My feedback was that it was completely broken, but I didn?t have time to get it properly tested and reported, sorry about that. > > > -Matthias > > > > [1] > > https://github.com/aerogear/aerogear-ios-xcode-template/tree/BumpDependenciesToNext > > > > _______________________________________________ > 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/20140217/78436e0d/attachment.html From matzew at apache.org Mon Feb 17 07:35:19 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 17 Feb 2014 13:35:19 +0100 Subject: [aerogear-dev] Xcode Template - version updates In-Reply-To: <57CFD7FF-C17A-441F-913C-8135D1A19D84@redhat.com> References: <20140217132407.42e30968@kapy-ntb-x220> <57CFD7FF-C17A-441F-913C-8135D1A19D84@redhat.com> Message-ID: On Mon, Feb 17, 2014 at 1:29 PM, Tadeas Kriz wrote: > > -- > Tadeas Kriz > tkriz at redhat.com > > On 17 Feb 2014, at 13:26, Matthias Wessendorf wrote: > > > > > On Mon, Feb 17, 2014 at 1:24 PM, Karel Piwko wrote: > >> On Sat, 15 Feb 2014 14:24:53 +0100 >> Matthias Wessendorf wrote: >> >> > Hello, >> > >> > since some iOS releases are coming up, I started a branch ([1]) to bump >> up >> > all the affected versions! >> > >> > The update for the iOS Push registration SDK is already available on >> that >> > branch. >> > >> >> Awesome! Tadeas, can you please make sure that your feedback on the >> template is >> included in new version as well? >> > > Please use a separate thread for any feedback (on the template) > > > My feedback was that it was completely broken, but I didn't have time to > get it properly tested and reported, sorry about that. > Works here :-) > > >> > -Matthias >> > >> > [1] >> > >> https://github.com/aerogear/aerogear-ios-xcode-template/tree/BumpDependenciesToNext >> > >> >> _______________________________________________ >> 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 > > > -- 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/20140217/481c3331/attachment.html From kpiwko at redhat.com Mon Feb 17 07:50:37 2014 From: kpiwko at redhat.com (Karel Piwko) Date: Mon, 17 Feb 2014 13:50:37 +0100 Subject: [aerogear-dev] Second try (was: Re: staging of UnifiedPush Server 0.10.0) In-Reply-To: References: <20140217132016.55245687@kapy-ntb-x220> Message-ID: <20140217135037.0859170a@kapy-ntb-x220> On Mon, 17 Feb 2014 13:24:37 +0100 Matthias Wessendorf wrote: > On Mon, Feb 17, 2014 at 1:20 PM, Karel Piwko wrote: > > > Hey, > > > > there were quite a big API changes in between 0.9.0 and 0.10.0. I hope > > that we > > can finish testing Tue evening. > > > > the public api (REST) did not change; Internal code did change, that's right Right. We still have a bunch of APIs in integration tests. > > > > The other question is: what is the plan to OpenShift cart? Would there be > > an > > update to OpenShift branch? > > Another question, which version of SimplePush Server should I use? Latest commit in master? Or 0.9.0 will do? > > Once we have this release up, the next step is around OpenShift I see. Let me try to upgrade the cart, as we find handy having cart for isolated UI testing. > > > > > > > Thanks, > > > > Karel > > > > On Sat, 15 Feb 2014 12:00:44 +0100 > > Matthias Wessendorf wrote: > > > > > Alright, I have included the UI related updates and staged the new WAR > > file > > > on my private webspace: > > > > > > > > > > > http://people.apache.org/~matzew/aerogear-staging/org/jboss/aerogear/unifiedpush/unifiedpush-server/0.10.0/ > > > > > > > > > Please give it a shot! > > > > > > If they aren't any objections or major issues, the release to Bintray > > will > > > happen on Tuesday. > > > > > > PS: this time we have a 0.10.x branch - just in case; after releasing, I > > > will tag that branch ;-) > > > https://github.com/aerogear/aerogear-unifiedpush-server/tree/0.10.x > > > > > > > > > -Matthias > > > > > > > > > On Fri, Feb 14, 2014 at 8:01 PM, Sebastien Blanc > >wrote: > > > > > > > Yeah I made sure to do pull on the admin master before doing the > > release > > > > > > > > > > > > On Fri, Feb 14, 2014 at 7:52 PM, Lucas Holmquist > >wrote: > > > > > > > >> > > > >> On Feb 14, 2014, at 1:50 PM, Matthias Wessendorf > > > >> wrote: > > > >> > > > >> > > > >> > > > >> > > > >> On Fri, Feb 14, 2014 at 7:42 PM, Lucas Holmquist > > > >> wrote: > > > >> > > > >>> > > > >>> On Feb 14, 2014, at 12:28 PM, Sebastien Blanc > > > >>> wrote: > > > >>> > > > >>> Hi, > > > >>> I just give it a test , it deploys well and works but ... > > > >>> Looking at the Admin UI, it stills mention 0.10.0-SNAPSHOT in the > > title, > > > >>> that should be fixed. > > > >>> > > > >>> The latest UI update on UPS is from 14/01, would not hurt to make > > > >>> another UI release to be integrated in UPS to be sure we miss no UI > > fixes > > > >>> in the release. > > > >>> > > > >>> I can do the PR if you are okay ? > > > >>> > > > >>> good idea since ember just released a security fix > > > >>> > > > >>> > > > >> is that included here ? > > > >> > > > >> > > https://github.com/aerogear/aerogear-unifiedpush-server/pull/132/files > > > >> > > > >> > > > >> sho is > > > >> > > > >> > > > >> -M > > > >> > > > >> > > > >> > > > >>> > > > >>> Seb > > > >>> > > > >>> > > > >>> > > > >>> On Thu, Feb 13, 2014 at 8:13 PM, Matthias Wessendorf > > > >>> wrote: > > > >>> > > > >>>> Hello, > > > >>>> > > > >>>> for the upcoming release we fixed several tickets: > > > >>>> https://issues.jboss.org/browse/AGPUSH/fixforversion/12321876 > > > >>>> > > > >>>> Before finishing the release, let's see if there are issues w/ the > > > >>>> server, hence I have staged the WAR file on my private webspace: > > > >>>> > > > >>>> > > > >>>> > > > >>>> > > http://people.apache.org/~matzew/aerogear-staging/org/jboss/aerogear/unifiedpush/unifiedpush-server/0.10.0/ > > > >>>> > > > >>>> > > > >>>> If they aren't any objections or remarks I will release the bits to > > > >>>> maven central on Monday morning > > > >>>> > > > >>>> -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 > > > >>> > > > >>> > > > >>> > > https://github.com/junit-team/junit/blob/master/src/main/java/org/junit/runners/Parameterized.java > > > >>> _______________________________________________ > > > >>> 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 > > > >> > > > > > > > > > > > > _______________________________________________ > > > > 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 > > > > > From cvasilak at gmail.com Mon Feb 17 07:56:36 2014 From: cvasilak at gmail.com (Christos Vasilakis) Date: Mon, 17 Feb 2014 14:56:36 +0200 Subject: [aerogear-dev] Xcode Template - version updates In-Reply-To: <57CFD7FF-C17A-441F-913C-8135D1A19D84@redhat.com> References: <20140217132407.42e30968@kapy-ntb-x220> <57CFD7FF-C17A-441F-913C-8135D1A19D84@redhat.com> Message-ID: Hi Tadeas, On Feb 17, 2014, at 2:29 PM, Tadeas Kriz wrote: > > ? > Tadeas Kriz > tkriz at redhat.com > > On 17 Feb 2014, at 13:26, Matthias Wessendorf wrote: > >> >> >> >> On Mon, Feb 17, 2014 at 1:24 PM, Karel Piwko wrote: >> On Sat, 15 Feb 2014 14:24:53 +0100 >> Matthias Wessendorf wrote: >> >> > Hello, >> > >> > since some iOS releases are coming up, I started a branch ([1]) to bump up >> > all the affected versions! >> > >> > The update for the iOS Push registration SDK is already available on that >> > branch. >> > >> >> Awesome! Tadeas, can you please make sure that your feedback on the template is >> included in new version as well? >> >> Please use a separate thread for any feedback (on the template) >> > My feedback was that it was completely broken, but I didn?t have time to get it properly tested and reported, sorry about that. as Matthias said, would you mind opening a separate thread with the issues you discovered, not sure what do u mean? from my tests generation does work here too, bit puzzled.. Thanks, Christos >> >> > -Matthias >> > >> > [1] >> > https://github.com/aerogear/aerogear-ios-xcode-template/tree/BumpDependenciesToNext >> > >> >> _______________________________________________ >> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140217/cbc26938/attachment.html From matzew at apache.org Mon Feb 17 07:58:14 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 17 Feb 2014 13:58:14 +0100 Subject: [aerogear-dev] Second try (was: Re: staging of UnifiedPush Server 0.10.0) In-Reply-To: <20140217135037.0859170a@kapy-ntb-x220> References: <20140217132016.55245687@kapy-ntb-x220> <20140217135037.0859170a@kapy-ntb-x220> Message-ID: On Mon, Feb 17, 2014 at 1:50 PM, Karel Piwko wrote: > On Mon, 17 Feb 2014 13:24:37 +0100 > Matthias Wessendorf wrote: > > > On Mon, Feb 17, 2014 at 1:20 PM, Karel Piwko wrote: > > > > > Hey, > > > > > > there were quite a big API changes in between 0.9.0 and 0.10.0. I hope > > > that we > > > can finish testing Tue evening. > > > > > > > the public api (REST) did not change; Internal code did change, that's > right > > Right. We still have a bunch of APIs in integration tests. > > > > > > > The other question is: what is the plan to OpenShift cart? Would there > be > > > an > > > update to OpenShift branch? > > > > > Another question, which version of SimplePush Server should I use? Latest > commit in master? Or 0.9.0 will do? > should not matter; > > > > > Once we have this release up, the next step is around OpenShift > > I see. Let me try to upgrade the cart, as we find handy having cart for > isolated UI testing. > On IRC Daniel reported that he plans to release the SPS early March; once that happened, that's get the 0.10.0 version of the cartridge out (which uses 0.10.0 version of both: UPS and SPS) -M > > > > > > > > > > > > > Thanks, > > > > > > Karel > > > > > > On Sat, 15 Feb 2014 12:00:44 +0100 > > > Matthias Wessendorf wrote: > > > > > > > Alright, I have included the UI related updates and staged the new > WAR > > > file > > > > on my private webspace: > > > > > > > > > > > > > > > > http://people.apache.org/~matzew/aerogear-staging/org/jboss/aerogear/unifiedpush/unifiedpush-server/0.10.0/ > > > > > > > > > > > > Please give it a shot! > > > > > > > > If they aren't any objections or major issues, the release to Bintray > > > will > > > > happen on Tuesday. > > > > > > > > PS: this time we have a 0.10.x branch - just in case; after > releasing, I > > > > will tag that branch ;-) > > > > https://github.com/aerogear/aerogear-unifiedpush-server/tree/0.10.x > > > > > > > > > > > > -Matthias > > > > > > > > > > > > On Fri, Feb 14, 2014 at 8:01 PM, Sebastien Blanc < > scm.blanc at gmail.com > > > >wrote: > > > > > > > > > Yeah I made sure to do pull on the admin master before doing the > > > release > > > > > > > > > > > > > > > On Fri, Feb 14, 2014 at 7:52 PM, Lucas Holmquist < > lholmqui at redhat.com > > > >wrote: > > > > > > > > > >> > > > > >> On Feb 14, 2014, at 1:50 PM, Matthias Wessendorf < > matzew at apache.org> > > > > >> wrote: > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> On Fri, Feb 14, 2014 at 7:42 PM, Lucas Holmquist > > > > >> wrote: > > > > >> > > > > >>> > > > > >>> On Feb 14, 2014, at 12:28 PM, Sebastien Blanc < > scm.blanc at gmail.com> > > > > >>> wrote: > > > > >>> > > > > >>> Hi, > > > > >>> I just give it a test , it deploys well and works but ... > > > > >>> Looking at the Admin UI, it stills mention 0.10.0-SNAPSHOT in the > > > title, > > > > >>> that should be fixed. > > > > >>> > > > > >>> The latest UI update on UPS is from 14/01, would not hurt to make > > > > >>> another UI release to be integrated in UPS to be sure we miss no > UI > > > fixes > > > > >>> in the release. > > > > >>> > > > > >>> I can do the PR if you are okay ? > > > > >>> > > > > >>> good idea since ember just released a security fix > > > > >>> > > > > >>> > > > > >> is that included here ? > > > > >> > > > > >> > > > https://github.com/aerogear/aerogear-unifiedpush-server/pull/132/files > > > > >> > > > > >> > > > > >> sho is > > > > >> > > > > >> > > > > >> -M > > > > >> > > > > >> > > > > >> > > > > >>> > > > > >>> Seb > > > > >>> > > > > >>> > > > > >>> > > > > >>> On Thu, Feb 13, 2014 at 8:13 PM, Matthias Wessendorf > > > > >>> wrote: > > > > >>> > > > > >>>> Hello, > > > > >>>> > > > > >>>> for the upcoming release we fixed several tickets: > > > > >>>> https://issues.jboss.org/browse/AGPUSH/fixforversion/12321876 > > > > >>>> > > > > >>>> Before finishing the release, let's see if there are issues w/ > the > > > > >>>> server, hence I have staged the WAR file on my private webspace: > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>> > > > > http://people.apache.org/~matzew/aerogear-staging/org/jboss/aerogear/unifiedpush/unifiedpush-server/0.10.0/ > > > > >>>> > > > > >>>> > > > > >>>> If they aren't any objections or remarks I will release the > bits to > > > > >>>> maven central on Monday morning > > > > >>>> > > > > >>>> -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 > > > > >>> > > > > >>> > > > > >>> > > > > https://github.com/junit-team/junit/blob/master/src/main/java/org/junit/runners/Parameterized.java > > > > >>> _______________________________________________ > > > > >>> 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 > > > > >> > > > > > > > > > > > > > > > _______________________________________________ > > > > > 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 > > > > > > > > > > > _______________________________________________ > 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/20140217/bfe797b8/attachment-0001.html From kpiwko at redhat.com Mon Feb 17 08:02:19 2014 From: kpiwko at redhat.com (Karel Piwko) Date: Mon, 17 Feb 2014 14:02:19 +0100 Subject: [aerogear-dev] AeroDoc: Show/Send leads - Geo map not showing agents near-by ? In-Reply-To: References: Message-ID: <20140217140219.754b2d3b@kapy-ntb-x220> As @Secure is "here will be dragons" kind of thing, I've filled documentation request at - https://issues.jboss.org/browse/AGSEC-176. Karel On Mon, 17 Feb 2014 09:12:25 +0100 Matthias Wessendorf wrote: > On Mon, Feb 17, 2014 at 9:07 AM, Sebastien Blanc wrote: > > > > > > > > > On Mon, Feb 17, 2014 at 9:00 AM, Matthias Wessendorf > > wrote: > > > >> > >> > >> > >> On Mon, Feb 17, 2014 at 8:57 AM, Sebastien Blanc > >> wrote: > >> > >>> > >>> > >>> > >>> On Mon, Feb 17, 2014 at 8:53 AM, Matthias Wessendorf > >>> wrote: > >>> > >>>> > >>>> > >>>> > >>>> On Mon, Feb 17, 2014 at 8:47 AM, Sebastien Blanc > >>>> wrote: > >>>> > >>>>> > >>>>> > >>>>> > >>>>> On Mon, Feb 17, 2014 at 8:42 AM, Matthias Wessendorf < > >>>>> matzew at apache.org> wrote: > >>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> On Mon, Feb 17, 2014 at 8:20 AM, Erik Jan de Wit > >>>>>> wrote: > >>>>>> > >>>>>>> > >>>>>>> On 16 Feb,2014, at 19:06 , Matthias Wessendorf > >>>>>>> wrote: > >>>>>>> > >>>>>>> Hi, > >>>>>>> > >>>>>>> I tried to play w/ the Geo support on AeroDoc, but there are some > >>>>>>> issues. > >>>>>>> > >>>>>>> After I noticed that only 'john' (the admin) (see [1]) is able to > >>>>>>> update the log/lat data, I was wondering about the next thing: Does > >>>>>>> the map show where 'agents' are? (by lat/long?) > >>>>>>> > >>>>>>> > >>>>>>> Didn't change the security setting, guess it was always the case > >>>>>>> that only admins can update. If that is wrong we should change that. > >>>>>>> > >>>>>> > >>>>>> Hrm, ok - perhaps Sebi knows more > >>>>>> > >>>>> Yeah, that is because of this > >>>>> https://github.com/aerogear/aerogear-aerodoc-backend/blob/master/src/main/java/org/jboss/aerogear/aerodoc/rest/SaleAgentEndpoint.java#L59 > >>>>> We should just override the update method with @Secure("simple") > >>>>> > >>>> > >>>> You might wanna see here: > >>>> > >>>> https://github.com/aerogear/aerogear-aerodoc-backend/blob/master/src/main/java/org/jboss/aerogear/aerodoc/rest/SaleAgentEndpoint.java#L115 > >>>> > >>> > >>> Doh ! I'm probably not enough wake up :) > >>> Ok but then we should maybe flip the coin and protect the class with > >>> "simple" and override the "admin" ones with "admin". > >>> > >> > >> well, shouldn't it just work, w/ the override ? Let's first investigate > >> if the source is really a bug, versus a wrong usage > >> > > > > Abstractj should confirm, but the override is not working this way, > > looking at > > https://github.com/aerogear/aerogear-security/blob/master/src/main/java/org/jboss/aerogear/security/interceptor/SecurityInterceptor.java#L54 > > it first validates on class level before looking at the method and an > > Exception will be thrown before it looks at the method annotation. > > > > I see - sounds like incorrect usage on our demo application, in that case > > > > > > > >> > >> -< > >> > >> > >>> > >>> > >>>> > >>>> > >>>> > >>>>> > >>>>>>> > >>>>>>> > >>>>>>> I am not seeing an agent on my map: > >>>>>>> http://people.apache.org/~matzew/geo-map.png > >>>>>>> > >>>>>>> That is not supported at the moment. > >>>>>>> > >>>>>> > >>>>>> Too bad ;-) Would be a nice feature :-) > >>>>>> > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> My long/lat values are OUTSIDE of that given radius (how can I > >>>>>>> change the radius), but my location is INSIDE of the visible map. > >>>>>>> > >>>>>>> > >>>>>>> You click the radius and drag the handle (little circle on the > >>>>>>> bottom right) to increase the radius. > >>>>>>> > >>>>>> > >>>>>> Ahhh!!!!! :-) I noticed that yesterday night :-) Almost an easter egg > >>>>>> :-) pretty good hidden :) But I guess that's due to the map we use, > >>>>>> right ? > >>>>>> > >>>>> > >>>>> Yeah, the handle is not very visible in the first place, Erik, could > >>>>> we change the style of this handle (more contrast, other color?) > >>>>> > >>>>>> > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Since a map is shown on that 'send leads' page, I was hoping to > >>>>>>> actually see a mark for my location. Or is this just not supported, > >>>>>>> atm ? > >>>>>>> > >>>>>>> > >>>>>>> right not supported, the idea is that you search sales agents that > >>>>>>> are within the radius and send them the lead. > >>>>>>> > >>>>>> > >>>>>> Not sure that works :-) > >>>>>> > >>>>>> I added a lead in San Francisco, and had my agent use my coordinates. > >>>>>> I updated the radius (increased by a few meters), than I think the > >>>>>> search results updated, but john (location data: Germany, Emsdetten) > >>>>>> was showing up :-) > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Greetings, > >>>>>>> Matthias > >>>>>>> > >>>>>>> > >>>>>>> [1] https://issues.jboss.org/browse/AGPUSH-535 > >>>>>>> > >>>>>>> -- > >>>>>>> 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 > >>>> > >>>> _______________________________________________ > >>>> 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 > > > > > From bruno at abstractj.org Mon Feb 17 08:23:35 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Mon, 17 Feb 2014 10:23:35 -0300 Subject: [aerogear-dev] AeroDoc: Show/Send leads - Geo map not showing agents near-by ? In-Reply-To: <20140217140219.754b2d3b@kapy-ntb-x220> References: <20140217140219.754b2d3b@kapy-ntb-x220> Message-ID: If you want to provide a better alternative, I?m all for it. -- abstractj On February 17, 2014 at 10:02:31 AM, Karel Piwko (kpiwko at redhat.com) wrote: > > As @Secure is "here will be dragons" kind of thing, I've filled > documentation > request at - https://issues.jboss.org/browse/AGSEC-176. > > Karel From hbons at redhat.com Mon Feb 17 10:07:29 2014 From: hbons at redhat.com (Hylke Bons) Date: Mon, 17 Feb 2014 15:07:29 +0000 Subject: [aerogear-dev] aerogear.org revamp: where to fit in platform example page? In-Reply-To: References: Message-ID: <530225B1.6070009@redhat.com> Hey Corinne, I've updated the mockup with a "platform specific example" page (on the far right): https://github.com/hbons/aerogear-design/blob/master/website-restructure/aerogear-project.png Played with a lot of ideas for the transition, but your original idea in as implemented in the proof of concept seems to work best, so I just tweaked the style and wording of the links a little bit. These should go at the end of a section that talks a bout a high level concept, so people will read the secion first before getting into the language details. Let me know if that works. Hylke On 11/02/2014 12:55, Corinne Krych wrote: > > Hello Hylke, > > We already discussed it in this thread [1], but I rather have the > question in its own dedicated thread. > > Atm, the mockup defines 3 pages/layers: HOME, GET IT, and EXMAPLE > page. I think we're missing a PLATFORM EXAMPLE page. This page wil > explain in more details with the user prefered platform how to deal > with AG Core Pipe etc... Idally this page will have a github cookbook > repo assiciated to it. We have cookbook for the 3 plaforms: android, > iOS, JS so far and we also have demo repo. A crossrefence table like > this one [2] could also be useful. > > An example page with high level concept and definition illustrated > with code snippet is good. But not enough. Besides, atm we have an > extensive documentation that goes in much more details and i really > think we should keep this level of details. > > My question is: How do me transition from EXAMPLE to PALTFORM EXAMPLE? > Does it make sense to you? wdyt? > > Last time I did a hackengarten on AeroGear, people told me: Woah, > you've got such a great documentation, explaining step by step. And I > told them wait until we've got our killer revamp ;) > > ++ > > Corinne > > [1] > http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Fwd-Website-restructure-td5837.html > > [2] > https://github.com/aerogear/aerogear-ios-cookbook/blob/master/README.md > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140217/993b4987/attachment.html From qmx at qmx.me Mon Feb 17 10:18:50 2014 From: qmx at qmx.me (Douglas Campos) Date: Mon, 17 Feb 2014 12:18:50 -0300 Subject: [aerogear-dev] Team meeting agenda for today In-Reply-To: References: Message-ID: <20140217151850.GL45949@rohan.local> Here are the minutes: [12:18:04] Meeting ended Mon Feb 17 15:06:58 2014 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) [12:18:05] Minutes: http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-02-17-14.49.html [12:18:05] Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-02-17-14.49.txt [12:18:05] Log: http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-02-17-14.49.log.html -- qmx From matzew at apache.org Mon Feb 17 10:21:35 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 17 Feb 2014 16:21:35 +0100 Subject: [aerogear-dev] Passphrase protection proposal and UPS In-Reply-To: References: Message-ID: On Wed, Feb 12, 2014 at 3:15 PM, Bruno Oliveira wrote: > Good morning, over the weekend I was thinking about how to protect the way > how the passphrases are provided in UPS ( > https://issues.jboss.org/browse/AGPUSH-358) and would like to propose > some changes, but before moving forward let's validate if what I am saying > makes sense. > > **Note**: Matthias already started some thread about it ( > http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Question-around-encryption-for-iOS-push-certificate-passphrase-td6174.html). > But I didn't get the chance to look UPS and have a decent answer. > > I would like to hear what do you think to start to file Jiras or change > the proposal. > > URL: https://gist.github.com/abstractj/4c6cd242584f4ab406aa > > # Passphrase protection and friends > > ## Current scenario > > - At the moment passphrases and certificates are protected with *HTTPS*, > but we also have *CRIME*, *BEAST* and friends. > - From the *UPS* dictionary ( > http://aerogear.org/docs/specs/aerogear-server-push/) I understand a > Variant as an application (Android, iPhone....) > - From the usage scenarios, I understand that's possible to send messages > to a group of devices. *Ex*: Bruno sends "ahoy" to 3 different variants. > - Currently the passphrase is stored in plaintext > > Reading the sources from *UPS* and the whole documentation I could clearly > understand that what do we need might be the same thing being developed for > offline, a key management server. I think this must be a separated project > to everyone benefit of it. > > ## What is the whole idea? > > The idea is kinda of simple, but must be validated to check how it meet > your needs, each developer with access on the server side will have her own > key pair generated and encoded in binary format. > > ![]( > http://photon.abstractj.org/keymgmt_20140212_113030_20140212_113032.jpg) > > ### Some considerations > > - The key pair will be generated in a separated project, not on UPS > - For the key store I'm considering to support the same data stores > provided by SPS. What Dan did is a nice a idea ( > https://github.com/aerogear/aerogear-simplepush-server/tree/master/datastores > ) > You mean the new "key server" supports multiple databases, right ? > - For each key pair will be generated a self signed certificated encoded > in DER format and stored into the database ( > http://en.wikipedia.org/wiki/X.509) > - The key pair will be unique per user, like GPG does. > - We only provide a public key for encryption after successful > authentication into the system > > ## Changes suggested on UPS server > > 1. Login endpoint > > - Current login endpoint: > > POST /rest/auth/login > > - Suggested change: > > I'm not sure if we really need **POST** for login, unless > we are changing the state of some resource > > GET /rest/auth/login > Changing from POST to GET (for UPS login) is fine we me. The Login is really only relevant to the Admin UI. Historically: I picked POST because that's what all of our client libraries use as the default HTTP method for login (JS, iOS and Android) > Response: > > {public-key: string>} > > 2. Register push app > > - Our push clients will need to change to accept the public key > provided by the server and encrypt the passphrase. We can make use of *AG > Crypto* for it > - The basic workflow for our clients would be: > What clients do you mean? The only thing that really does a login against the server is the Admin UI (or a direct curl, using the same 'management' rest-endpoints which are accessed by the AdminUI). > - Send a login request > - Get the public key > - Encrypt the passphrase > - Send a request like we do at the moment > - For non *AG UPS* clients like *cURL*, the steps with *OpenSSL* > will be provided. I also consider the possibility of use GPG as > alternative, but something to be tested and evaluated. > > ## Future > > - Generate a key pair on the client side to sign our HTTP requests > - Generate the keys per session ( > http://en.wikipedia.org/wiki/Ephemeral_key) > > > > > > -- > abstractj > > _______________________________________________ > 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/20140217/b1d17137/attachment-0001.html From bruno at abstractj.org Mon Feb 17 10:37:25 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Mon, 17 Feb 2014 12:37:25 -0300 Subject: [aerogear-dev] Passphrase protection proposal and UPS In-Reply-To: References: Message-ID: -- abstractj On February 17, 2014 at 12:21:45 PM, Matthias Wessendorf (matzew at apache.org) wrote: > > On Wed, Feb 12, 2014 at 3:15 PM, Bruno Oliveira > wrote: > > ### Some considerations > > > > - The key pair will be generated in a separated project, not on > UPS > > - For the key store I'm considering to support the same data stores > > provided by SPS. What Dan did is a nice a idea ( > > https://github.com/aerogear/aerogear-simplepush-server/tree/master/datastores > > ) > > > > You mean the new "key server" supports multiple databases, right > ? Basically the possibility to store those key pairs in whatever storage mechanism you want: memory, Redis? TBH not very critical atm. > > ## Changes suggested on UPS server > > > > 1. Login endpoint > > > > - Current login endpoint: > > > > POST /rest/auth/login > > > > - Suggested change: > > > > I'm not sure if we really need **POST** for login, unless > > we are changing the state of some resource > > > > GET /rest/auth/login > > > > > Changing from POST to GET (for UPS login) is fine we me. The Login > is > really only relevant to the Admin UI. > Historically: I picked POST because that's what all of our client > libraries > use as the default HTTP method for login (JS, iOS and Android) >? That?s more a suggestion than a deal breaker.? > > 2. Register push app > > > > - Our push clients will need to change to accept the public key > > provided by the server and encrypt the passphrase. We can make > use of *AG > > Crypto* for it > > - The basic workflow for our clients would be: > > > > > What clients do you mean? The only thing that really does a login > against > the server is the Admin UI (or a direct curl, using the same 'management' > rest-endpoints which are accessed by the AdminUI). > > By clients I mean: cURL, aerogear-unifiedpush-java-client, node version?etc. If I got it right, you must provide the master secret. The suggestion is not only protect our passphrases, but also do not expose that masterSecret, because someone in possession of this could start to send push messages to the server. Am I wrong on it? From matzew at apache.org Mon Feb 17 11:28:53 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 17 Feb 2014 17:28:53 +0100 Subject: [aerogear-dev] Passphrase protection proposal and UPS In-Reply-To: References: Message-ID: On Mon, Feb 17, 2014 at 4:37 PM, Bruno Oliveira wrote: > > > -- > abstractj > > On February 17, 2014 at 12:21:45 PM, Matthias Wessendorf ( > matzew at apache.org) wrote: > > > > On Wed, Feb 12, 2014 at 3:15 PM, Bruno Oliveira > > wrote: > > > ### Some considerations > > > > > > - The key pair will be generated in a separated project, not on > > UPS > > > - For the key store I'm considering to support the same data stores > > > provided by SPS. What Dan did is a nice a idea ( > > > > https://github.com/aerogear/aerogear-simplepush-server/tree/master/datastores > > > ) > > > > > > > You mean the new "key server" supports multiple databases, right > > ? > > Basically the possibility to store those key pairs in whatever storage > mechanism you want: memory, Redis... > > TBH not very critical atm. > yup > > > > ## Changes suggested on UPS server > > > > > > 1. Login endpoint > > > > > > - Current login endpoint: > > > > > > POST /rest/auth/login > > > > > > - Suggested change: > > > > > > I'm not sure if we really need **POST** for login, unless > > > we are changing the state of some resource > > > > > > GET /rest/auth/login > > > > > > > > > Changing from POST to GET (for UPS login) is fine we me. The Login > > is > > really only relevant to the Admin UI. > > Historically: I picked POST because that's what all of our client > > libraries > > use as the default HTTP method for login (JS, iOS and Android) > > > > That's more a suggestion than a deal breaker. > yeah, I am pretty flexible here :-) > > > > 2. Register push app > > > > > > - Our push clients will need to change to accept the public key > > > provided by the server and encrypt the passphrase. We can make > > use of *AG > > > Crypto* for it > > > - The basic workflow for our clients would be: > > > > > > > > > What clients do you mean? The only thing that really does a login > > against > > the server is the Admin UI (or a direct curl, using the same 'management' > > rest-endpoints which are accessed by the AdminUI). > > > > > > By clients I mean: cURL, aerogear-unifiedpush-java-client, node > version...etc. If I got it right, you must provide the master secret. Right! for sending these 'sender clients' need to know the (umbrella) push applicationID and its masterSecret: http://aerogear.org/docs/specs/aerogear-push-rest/Sender/ > The suggestion is not only protect our passphrases, the passphrase is really something specific to iOS > but also do not expose that masterSecret, because someone in possession of > this could start to send push messages to the server. Am I wrong on it? > correct someone could to that. In the past we already at least chatted about having some sort of key/certificate for that + access-keys (e.g. per application). -Matthias -- 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/20140217/0eed5e50/attachment.html From bruno at abstractj.org Mon Feb 17 11:31:09 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Mon, 17 Feb 2014 13:31:09 -0300 Subject: [aerogear-dev] Passphrase protection proposal and UPS In-Reply-To: References: Message-ID: I will PR something this week to protect passphrase, master secrets and put pants on to our HTTP requests. Initially all the changes will be inside AGPUSH for the sake of simplicity. -- abstractj On February 17, 2014 at 1:28:55 PM, Matthias Wessendorf (matzew at apache.org) wrote: > > correct someone could to that. In the past we already at least > chatted about having some sort of key/certificate for that + > access-keys (e.g. per application). From matzew at apache.org Mon Feb 17 11:33:14 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 17 Feb 2014 17:33:14 +0100 Subject: [aerogear-dev] Passphrase protection proposal and UPS In-Reply-To: References: Message-ID: On Mon, Feb 17, 2014 at 5:31 PM, Bruno Oliveira wrote: > I will PR something this week to protect passphrase, master secrets and > put pants on to our HTTP requests. > looking forward to it > > Initially all the changes will be inside AGPUSH for the sake of simplicity. > that makes perfectly sense! > > -- > abstractj > > On February 17, 2014 at 1:28:55 PM, Matthias Wessendorf (matzew at apache.org) > wrote: > > > correct someone could to that. In the past we already at least > > chatted about having some sort of key/certificate for that + > > access-keys (e.g. per application). > > -- 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/20140217/cf51e6a5/attachment.html From matzew at apache.org Mon Feb 17 11:51:33 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 17 Feb 2014 17:51:33 +0100 Subject: [aerogear-dev] Google summer of code Message-ID: Hi, wondering about GSoC for 2014. Do we want to be part of it? Reviewing the GSoC-2014 list from JBoss, I see a few left-overs from last year are in here: https://community.jboss.org/wiki/GSOC14Ideas * Implement a Mobile Document Collaboration App * Demo: Implementing native features in mobile applications I am not sure if folks are still interested in these ? Aside for these 'older' items, there are some ideas (mostly around push) I put together in a gist: https://gist.github.com/matzew/bb9e3a0da6aca939b523 Especially #1 on that list is a huge interest of mine. Any thought ? -Matthias -- 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/20140217/e13473ed/attachment.html From kpiwko at redhat.com Mon Feb 17 11:58:51 2014 From: kpiwko at redhat.com (Karel Piwko) Date: Mon, 17 Feb 2014 17:58:51 +0100 Subject: [aerogear-dev] Team meeting agenda for today In-Reply-To: <20140217151850.GL45949@rohan.local> References: <20140217151850.GL45949@rohan.local> Message-ID: <20140217175851.3c7e1e44@kapy-ntb-x220> Just for future reference, Arquillian GSoC ideas are incubating here: https://community.jboss.org/wiki/ArquillianGSOC2014ProposalCleanup Karel On Mon, 17 Feb 2014 12:18:50 -0300 Douglas Campos wrote: > Here are the minutes: > > [12:18:04] Meeting ended Mon Feb 17 15:06:58 2014 UTC. > Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) > [12:18:05] Minutes: > http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-02-17-14.49.html > [12:18:05] Minutes (text): > http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-02-17-14.49.txt > [12:18:05] Log: > http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-02-17-14.49.log.html > > From bruno at abstractj.org Mon Feb 17 13:13:39 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Mon, 17 Feb 2014 15:13:39 -0300 Subject: [aerogear-dev] Google summer of code In-Reply-To: References: Message-ID: The first idea is great but the scope might require full time commitment. I would vote on #2 depending on which kind of application do you have in mind. -- abstractj On February 17, 2014 at 1:51:46 PM, Matthias Wessendorf (matzew at apache.org) wrote: > > Hi, > > wondering about GSoC for 2014. Do we want to be part of it? Reviewing > the > GSoC-2014 list from JBoss, I see a few left-overs from last year > are in > here: > > https://community.jboss.org/wiki/GSOC14Ideas > > * Implement a Mobile Document Collaboration App > * Demo: Implementing native features in mobile applications > > I am not sure if folks are still interested in these ? > > Aside for these 'older' items, there are some ideas (mostly around > push) I > put together in a gist: > https://gist.github.com/matzew/bb9e3a0da6aca939b523 > > Especially #1 on that list is a huge interest of mine. > > > Any thought ? > -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 From kpiwko at redhat.com Tue Feb 18 06:11:30 2014 From: kpiwko at redhat.com (Karel Piwko) Date: Tue, 18 Feb 2014 12:11:30 +0100 Subject: [aerogear-dev] Second try (was: Re: staging of UnifiedPush Server 0.10.0) In-Reply-To: References: <20140217132016.55245687@kapy-ntb-x220> <20140217135037.0859170a@kapy-ntb-x220> Message-ID: <20140218121130.7b4bc0f0@kapy-ntb-x220> Unit tests: Passed Integration tests: Updated & Passed Admin UI functional tests: Updated & Passed Integration with SP on OpenShift cartridge: Passed (Firefox 2.24.3, based on simplepush-unifiedpush quickstart) https://github.com/kpiwko/aerogear-unifiedpush-server/tree/openshift-0.10.0 https://github.com/kpiwko/openshift-origin-cartridge-aerogear-push/tree/ups-0.10.0 I guess there is nothing that should block the release. Great work indeed. Karel On Mon, 17 Feb 2014 13:58:14 +0100 Matthias Wessendorf wrote: > On Mon, Feb 17, 2014 at 1:50 PM, Karel Piwko wrote: > > > On Mon, 17 Feb 2014 13:24:37 +0100 > > Matthias Wessendorf wrote: > > > > > On Mon, Feb 17, 2014 at 1:20 PM, Karel Piwko wrote: > > > > > > > Hey, > > > > > > > > there were quite a big API changes in between 0.9.0 and 0.10.0. I hope > > > > that we > > > > can finish testing Tue evening. > > > > > > > > > > the public api (REST) did not change; Internal code did change, that's > > right > > > > Right. We still have a bunch of APIs in integration tests. > > > > > > > > > > The other question is: what is the plan to OpenShift cart? Would there > > be > > > > an > > > > update to OpenShift branch? > > > > > > > > Another question, which version of SimplePush Server should I use? Latest > > commit in master? Or 0.9.0 will do? > > > > should not matter; > > > > > > > > > > Once we have this release up, the next step is around OpenShift > > > > I see. Let me try to upgrade the cart, as we find handy having cart for > > isolated UI testing. > > > > On IRC Daniel reported that he plans to release the SPS early March; once > that happened, that's get the 0.10.0 version of the cartridge out (which > uses 0.10.0 version of both: UPS and SPS) > > -M > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > Karel > > > > > > > > On Sat, 15 Feb 2014 12:00:44 +0100 > > > > Matthias Wessendorf wrote: > > > > > > > > > Alright, I have included the UI related updates and staged the new > > WAR > > > > file > > > > > on my private webspace: > > > > > > > > > > > > > > > > > > > > > http://people.apache.org/~matzew/aerogear-staging/org/jboss/aerogear/unifiedpush/unifiedpush-server/0.10.0/ > > > > > > > > > > > > > > > Please give it a shot! > > > > > > > > > > If they aren't any objections or major issues, the release to Bintray > > > > will > > > > > happen on Tuesday. > > > > > > > > > > PS: this time we have a 0.10.x branch - just in case; after > > releasing, I > > > > > will tag that branch ;-) > > > > > https://github.com/aerogear/aerogear-unifiedpush-server/tree/0.10.x > > > > > > > > > > > > > > > -Matthias > > > > > > > > > > > > > > > On Fri, Feb 14, 2014 at 8:01 PM, Sebastien Blanc < > > scm.blanc at gmail.com > > > > >wrote: > > > > > > > > > > > Yeah I made sure to do pull on the admin master before doing the > > > > release > > > > > > > > > > > > > > > > > > On Fri, Feb 14, 2014 at 7:52 PM, Lucas Holmquist < > > lholmqui at redhat.com > > > > >wrote: > > > > > > > > > > > >> > > > > > >> On Feb 14, 2014, at 1:50 PM, Matthias Wessendorf < > > matzew at apache.org> > > > > > >> wrote: > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> On Fri, Feb 14, 2014 at 7:42 PM, Lucas Holmquist > > > > > >> wrote: > > > > > >> > > > > > >>> > > > > > >>> On Feb 14, 2014, at 12:28 PM, Sebastien Blanc < > > scm.blanc at gmail.com> > > > > > >>> wrote: > > > > > >>> > > > > > >>> Hi, > > > > > >>> I just give it a test , it deploys well and works but ... > > > > > >>> Looking at the Admin UI, it stills mention 0.10.0-SNAPSHOT in the > > > > title, > > > > > >>> that should be fixed. > > > > > >>> > > > > > >>> The latest UI update on UPS is from 14/01, would not hurt to make > > > > > >>> another UI release to be integrated in UPS to be sure we miss no > > UI > > > > fixes > > > > > >>> in the release. > > > > > >>> > > > > > >>> I can do the PR if you are okay ? > > > > > >>> > > > > > >>> good idea since ember just released a security fix > > > > > >>> > > > > > >>> > > > > > >> is that included here ? > > > > > >> > > > > > >> > > > > https://github.com/aerogear/aerogear-unifiedpush-server/pull/132/files > > > > > >> > > > > > >> > > > > > >> sho is > > > > > >> > > > > > >> > > > > > >> -M > > > > > >> > > > > > >> > > > > > >> > > > > > >>> > > > > > >>> Seb > > > > > >>> > > > > > >>> > > > > > >>> > > > > > >>> On Thu, Feb 13, 2014 at 8:13 PM, Matthias Wessendorf > > > > > >>> wrote: > > > > > >>> > > > > > >>>> Hello, > > > > > >>>> > > > > > >>>> for the upcoming release we fixed several tickets: > > > > > >>>> https://issues.jboss.org/browse/AGPUSH/fixforversion/12321876 > > > > > >>>> > > > > > >>>> Before finishing the release, let's see if there are issues w/ > > the > > > > > >>>> server, hence I have staged the WAR file on my private webspace: > > > > > >>>> > > > > > >>>> > > > > > >>>> > > > > > >>>> > > > > > > http://people.apache.org/~matzew/aerogear-staging/org/jboss/aerogear/unifiedpush/unifiedpush-server/0.10.0/ > > > > > >>>> > > > > > >>>> > > > > > >>>> If they aren't any objections or remarks I will release the > > bits to > > > > > >>>> maven central on Monday morning > > > > > >>>> > > > > > >>>> -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 > > > > > >>> > > > > > >>> > > > > > >>> > > > > > > https://github.com/junit-team/junit/blob/master/src/main/java/org/junit/runners/Parameterized.java > > > > > >>> _______________________________________________ > > > > > >>> 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 > > > > > >> > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > 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 > > > > > > > > > > > > > > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > From cvasilak at gmail.com Tue Feb 18 11:06:46 2014 From: cvasilak at gmail.com (Christos Vasilakis) Date: Tue, 18 Feb 2014 18:06:46 +0200 Subject: [aerogear-dev] Announcing AeroGear iOS 1.4.0 Release Message-ID: Hi everyone, I am pleased to announce the release of AeroGear iOS library v1.4.0. More details for this release, can be found on the release blogpost. Congratulations to the team, and to our community contributors and users! Have fun! - Christos -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140218/b9710905/attachment.html From bruno at abstractj.org Tue Feb 18 11:08:55 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Tue, 18 Feb 2014 08:08:55 -0800 (PST) Subject: [aerogear-dev] Announcing AeroGear iOS 1.4.0 Release In-Reply-To: References: Message-ID: <1392739734983.7eb8e9a@Nodemailer> Huzzah! Congratulations!? abstractj On Tue, Feb 18, 2014 at 1:07 PM, Christos Vasilakis wrote: > Hi everyone, > I am pleased to announce the release of AeroGear iOS library v1.4.0. More details for this release, can be found on the release blogpost. > Congratulations to the team, and to our community contributors and users! > Have fun! > - > Christos -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140218/2ca06fca/attachment.html From matzew at apache.org Tue Feb 18 11:19:36 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 18 Feb 2014 17:19:36 +0100 Subject: [aerogear-dev] Announcing AeroGear iOS 1.4.0 Release In-Reply-To: <1392739734983.7eb8e9a@Nodemailer> References: <1392739734983.7eb8e9a@Nodemailer> Message-ID: great work, guys! Congratulations!!! On Tue, Feb 18, 2014 at 5:08 PM, Bruno Oliveira wrote: > Huzzah! Congratulations! > -- > abstractj > > > On Tue, Feb 18, 2014 at 1:07 PM, Christos Vasilakis wrote: > >> Hi everyone, >> >> I am pleased to announce the release of AeroGear iOS library v1.4.0. More >> details for this release, can be found on the release blogpost >> . >> >> Congratulations to the team, and to our community contributors and users! >> >> Have fun! >> >> - >> Christos >> > > > _______________________________________________ > 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/20140218/b60aad16/attachment.html From daniel.bevenius at gmail.com Tue Feb 18 11:21:00 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Tue, 18 Feb 2014 17:21:00 +0100 Subject: [aerogear-dev] Announcing AeroGear iOS 1.4.0 Release In-Reply-To: References: <1392739734983.7eb8e9a@Nodemailer> Message-ID: Very nice, great job! tisdagen den 18:e februari 2014 skrev Matthias Wessendorf : > great work, guys! > > Congratulations!!! > > > On Tue, Feb 18, 2014 at 5:08 PM, Bruno Oliveira > > wrote: > >> Huzzah! Congratulations! >> -- >> abstractj >> >> >> On Tue, Feb 18, 2014 at 1:07 PM, Christos Vasilakis >> > wrote: >> >>> Hi everyone, >>> >>> I am pleased to announce the release of AeroGear iOS library v1.4.0. >>> More details for this release, can be found on the release blogpost >>> . >>> >>> Congratulations to the team, and to our community contributors and users! >>> >>> Have fun! >>> >>> - >>> Christos >>> >> >> >> _______________________________________________ >> 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/20140218/25ad126e/attachment-0001.html From scm.blanc at gmail.com Tue Feb 18 12:05:56 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Tue, 18 Feb 2014 18:05:56 +0100 Subject: [aerogear-dev] iOS Scaffolding Message-ID: Hi Folks ! While I was watching Matzew's screencast[1] about using the AeroGear iOS Template (which bootstrap/help to create a new iOS project) I was thinking about pushing the concept even further. Wouldn't it be nice to be able to scaffold a complete CRUD Native iOS app ? And of course by using the bullets we already have : Forge. The idea would be to have the same stuff as the HTML5 Scaffolding plugin/addon but instead of generating JS and html files we generate *.h and *.m files (and of course a complete iOS app structure). The general workflow would stay the same : create a JEE project, generate entities, generate REST endpoints and scaffold the client. So basically all we would have to do is to write those templates (+ some code to write to the correct location / create the skeleton). I will be glad to start on this but I would need some help from the iOS gurus for one thing : having a clean iOS CRUD App from which I could reverse engineer/extract the templates. This app, while staying simple, should contain all the possible use cases : String, numbers, boolean, Date but also some relation between entities (1-to-1, 1-to-many) : I started with this simple idea : Team { name : String hasMany : Player hasMany: Tournamenent // many-to-many } Player { name : String dateOfBirth: Date injured: boolean hasOne : Team } Tournament { name: String price : number hasMany: Team } The gist is here https://gist.github.com/sebastienblanc/9074932 So, if anyone would like to create this app, I could start from there with a first draft. I will also try on my side but my objective-c skills are not really good enough right now ;) I think that could be a very cool feature. A last very important remark : you can reread this message and replace iOS with Android because once we got it shaped for iOS we could do exactly the same for Android. Sebi [1] https://vimeo.com/86978742 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140218/98219a3d/attachment.html From corinnekrych at gmail.com Wed Feb 19 03:11:36 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Wed, 19 Feb 2014 09:11:36 +0100 Subject: [aerogear-dev] iOS Scaffolding In-Reply-To: References: Message-ID: <96636ABC-EE3E-461D-A5F0-0BFBB4B79694@gmail.com> On 18 Feb 2014, at 18:05, Sebastien Blanc wrote: > Hi Folks ! > > While I was watching Matzew's screencast[1] about using the AeroGear iOS Template (which bootstrap/help to create a new iOS project) I was thinking about pushing the concept even further. > > Wouldn't it be nice to be able to scaffold a complete CRUD Native iOS app ? And of course by using the bullets we already have : Forge. You would generate server and client side at once? > > The idea would be to have the same stuff as the HTML5 Scaffolding plugin/addon but instead of generating JS and html files we generate *.h and *.m files (and of course a complete iOS app structure). The general workflow would stay the same : create a JEE project, generate entities, generate REST endpoints and scaffold the client. > > So basically all we would have to do is to write those templates (+ some code to write to the correct location / create the skeleton). > I would start with an app generated with iOS template for simple Pipe, and then add to it. See my questions below. > I will be glad to start on this but I would need some help from the iOS gurus for one thing : having a clean iOS CRUD App from which I could reverse engineer/extract the templates. This app, while staying simple, should contain all the possible use cases : String, numbers, boolean, Date but also some relation between entities (1-to-1, 1-to-many) : With Pipes and Stores, we use more a Key/Value approach. Not sure what you have in mind to represent relation. In term of UI what do you want to see? first screen: Team TableView with static table cell, Players and Tournaments cell link to second screen TableView second screen: Player TableView with a list of player displaying only name, selecting a player will go to third screen Player details third screen: Player Details static table view with date display etc? Then we might need a descriptive/configurable way of saying to forge this is my main screen, on that list display ?player name? etc? What?s your view on that? > > I started with this simple idea : > Team { > name : String > hasMany : Player > hasMany: Tournamenent // many-to-many > } > > Player { > name : String > dateOfBirth: Date > injured: boolean > hasOne : Team > } > > Tournament { > name: String > price : number > hasMany: Team > } > > > > The gist is here https://gist.github.com/sebastienblanc/9074932 > > So, if anyone would like to create this app, I could start from there with a first draft. I will also try on my side but my objective-c skills are not really good enough right now ;) team work :) > > I think that could be a very cool feature. > > A last very important remark : you can reread this message and replace iOS with Android because once we got it shaped for iOS we could do exactly the same for Android. make sense > > Sebi > > > [1] https://vimeo.com/86978742 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From scm.blanc at gmail.com Wed Feb 19 03:47:52 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Wed, 19 Feb 2014 09:47:52 +0100 Subject: [aerogear-dev] iOS Scaffolding In-Reply-To: <96636ABC-EE3E-461D-A5F0-0BFBB4B79694@gmail.com> References: <96636ABC-EE3E-461D-A5F0-0BFBB4B79694@gmail.com> Message-ID: On Wed, Feb 19, 2014 at 9:11 AM, Corinne Krych wrote: > > On 18 Feb 2014, at 18:05, Sebastien Blanc wrote: > > > Hi Folks ! > > > > While I was watching Matzew's screencast[1] about using the AeroGear iOS > Template (which bootstrap/help to create a new iOS project) I was thinking > about pushing the concept even further. > > > > Wouldn't it be nice to be able to scaffold a complete CRUD Native iOS > app ? And of course by using the bullets we already have : Forge. > > You would generate server and client side at once? > Well, the iOS generation will be just one specific forge command, the rest are just "existing/vanilla" forge commands (entiies creation, REST endpoints creation) > > > > The idea would be to have the same stuff as the HTML5 Scaffolding > plugin/addon but instead of generating JS and html files we generate *.h > and *.m files (and of course a complete iOS app structure). The general > workflow would stay the same : create a JEE project, generate entities, > generate REST endpoints and scaffold the client. > > > > So basically all we would have to do is to write those templates (+ some > code to write to the correct location / create the skeleton). > > > > I would start with an app generated with iOS template for simple Pipe, and > then add to it. See my questions below. > > > I will be glad to start on this but I would need some help from the iOS > gurus for one thing : having a clean iOS CRUD App from which I could > reverse engineer/extract the templates. This app, while staying simple, > should contain all the possible use cases : String, numbers, boolean, Date > but also some relation between entities (1-to-1, 1-to-many) : > > With Pipes and Stores, we use more a Key/Value approach. Not sure what you > have in mind to represent relation. > Well, not sure how it is implemented in iOS but for instance when you choose a team, a list of players should also be retrieved. > > In term of UI what do you want to see? > first screen: Team TableView with static table cell, Players and > Tournaments cell link to second screen TableView > second screen: Player TableView with a list of player displaying only > name, selecting a player will go to third screen Player details > third screen: Player Details static table view with date display etc... > > Then we might need a descriptive/configurable way of saying to forge this > is my main screen, on that list display 'player name' etc... > What's your view on that? > We could do like the grails html5 scaffold plugin : the main screen contains a list of the entities, when you select an entity by default you go to the list view and in the bottom bar you have a button to create a new one. When a entity entry is selected in the bottom bar you can : edit or delete > > > > > I started with this simple idea : > > Team { > > name : String > > hasMany : Player > > hasMany: Tournamenent // many-to-many > > } > > > > Player { > > name : String > > dateOfBirth: Date > > injured: boolean > > hasOne : Team > > } > > > > Tournament { > > name: String > > price : number > > hasMany: Team > > } > > > > > > > > The gist is here https://gist.github.com/sebastienblanc/9074932 > > > > So, if anyone would like to create this app, I could start from there > with a first draft. I will also try on my side but my objective-c skills > are not really good enough right now ;) > > team work :) > > > > > I think that could be a very cool feature. > > > > A last very important remark : you can reread this message and replace > iOS with Android because once we got it shaped for iOS we could do exactly > the same for Android. > > make sense > > > > > Sebi > > > > > > [1] https://vimeo.com/86978742 > > _______________________________________________ > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140219/6fc84771/attachment.html From miguel21op at gmail.com Wed Feb 19 03:58:30 2014 From: miguel21op at gmail.com (Miguel Lemos) Date: Wed, 19 Feb 2014 08:58:30 +0000 Subject: [aerogear-dev] Issues with Aerogear on Cordova Message-ID: Hello, I'm still struggling, for saying the least, with Aerogear documentation in order to make a Cordova / Android app receive push notifications. Amazingly one of the most unexpected issues has been with the correct string to use on URLs to register or sending the notifications. Examples given by documentation: Openshift: curl -u "{PushApplicationID}:{MasterSecret}" -v -H "Accept: application/json" -H "Content-type: application/json" -X POST -d '{ "someKey":"someValue", "alert":"HELLO!", "sound":"default", "badge":7, "simple-push":"version=123" }' http://SERVER:PORT/CONTEXT/rest/sender/broadcast Aerogear: curl -3 -u "{pushApplicationID}:{masterSecret}" -v -H "Accept: application/json" -H "Content-type: application/json" -X POST -d '{"message": {"alert":"AeroGear UnifiedPush and Apache Cordova 3.0.6", "badge":1}}' https://SERVER:PORT/CONTEXT/rest/sender How the above examples, apparently mean that, in my case, I must use something like: https://aerogear-metalpush.rhcloud.com/rest/sender maybe is very obvious for someone inside Aerogear lingo, but not at all for me... Anyway, after I managed to overcome this, the answer I get from the server is this one (stripped from more irrelevant parts): > POST /rest/sender HTTP/1.1 > Authorization: Basic MDBhMjFjZTMtYTdkOS00YzhjLWI1ODMtOWYwMjEwYTYzNGU1Ojk0MTE4NmIzLWVjNmEtNGY0OC1iMjZiLTJkMDYxZWIyM2Q5Yg== > User-Agent: curl/7.30.0 > Host: aerogear-metalpush.rhcloud.com > Accept: application/json > Content-type: application/json > Content-Length: 50 > } [data not shown] * upload completely sent off: 50 out of 50 bytes < HTTP/1.1 200 OK < Date: Tue, 18 Feb 2014 20:58:18 GMT * Server Apache-Coyote/1.1 is not blacklisted < Server: Apache-Coyote/1.1 < Content-Type: application/json < Content-Length: 13 < Vary: Accept-Encoding < { [data not shown] 100 63 100 13 100 50 11 44 0:00:01 0:00:01 --:--:-- 44Job submitted * Connection #0 to host aerogear-metalpush.rhcloud.com left intact As far as I can guess, this means that the request was accepted. Nevertheless, I receive nothing on the client's side. On my phone the successHandler function throws a success message, meaning that the equipment has managed to register at the service. And my code to receive the notifications is the same given in some examples: function onNotification(e) { alert(e.alert); ) But nothing happens, tough. Thanks for giving me some clues to solve this. Miguel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140219/1038d171/attachment-0001.html From scm.blanc at gmail.com Wed Feb 19 04:11:40 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Wed, 19 Feb 2014 10:11:40 +0100 Subject: [aerogear-dev] Issues with Aerogear on Cordova In-Reply-To: References: Message-ID: Hi, Some questions and remarks inline On Wed, Feb 19, 2014 at 9:58 AM, Miguel Lemos wrote: > Hello, > > I'm still struggling, for saying the least, with Aerogear documentation in > order to make a Cordova / Android app receive push notifications. > Amazingly one of the most unexpected issues has been with the correct > string to use on URLs to register or sending the notifications. > > Examples given by documentation: > > Openshift: > > curl -u "{PushApplicationID}:{MasterSecret}" > -v -H "Accept: application/json" -H "Content-type: application/json" > -X POST > -d '{ > "someKey":"someValue", > "alert":"HELLO!", > "sound":"default", > "badge":7, > "simple-push":"version=123" > }' > http://SERVER:PORT/CONTEXT/rest/sender/broadcast > Can you post the link where you found this example , the "/broadcast" is outdated and should not appear in our doc > > Aerogear: > > curl -3 -u "{pushApplicationID}:{masterSecret}" > -v -H "Accept: application/json" -H "Content-type: application/json" > -X POST -d '{"message": {"alert":"AeroGear UnifiedPush and Apache > Cordova 3.0.6", "badge":1}}' > https://SERVER:PORT/CONTEXT/rest/sender > > > How the above examples, apparently mean that, in my case, I must use > something like: https://aerogear-metalpush.rhcloud.com/rest/sender > maybe is very obvious for someone inside Aerogear lingo, but not at all > for me... > > Ok, it's specified here http://aerogear.org/docs/specs/aerogear-push-rest/Sender/ but maybe we should make it more obvious, thanks for pointing that out. > Anyway, after I managed to overcome this, the answer I get from the server > is this one (stripped from more irrelevant parts): > > > POST /rest/sender HTTP/1.1 > > Authorization: Basic > MDBhMjFjZTMtYTdkOS00YzhjLWI1ODMtOWYwMjEwYTYzNGU1Ojk0MTE4NmIzLWVjNmEtNGY0OC1iMjZiLTJkMDYxZWIyM2Q5Yg== > > User-Agent: curl/7.30.0 > > Host: aerogear-metalpush.rhcloud.com > > Accept: application/json > > Content-type: application/json > > Content-Length: 50 > > > } [data not shown] > * upload completely sent off: 50 out of 50 bytes > < HTTP/1.1 200 OK > < Date: Tue, 18 Feb 2014 20:58:18 GMT > * Server Apache-Coyote/1.1 is not blacklisted > < Server: Apache-Coyote/1.1 > < Content-Type: application/json > < Content-Length: 13 > < Vary: Accept-Encoding > < > { [data not shown] > 100 63 100 13 100 50 11 44 0:00:01 0:00:01 > --:--:-- 44Job submitted > * Connection #0 to host aerogear-metalpush.rhcloud.com left intact > > > As far as I can guess, this means that the request was accepted. > Nevertheless, I receive nothing on the client's side. > On my phone the successHandler function throws a success message, meaning > that the equipment has managed to register at the service. > > And my code to receive the notifications is the same given in some > examples: > > function onNotification(e) { > alert(e.alert); > ) > > But nothing happens, tough. Thanks for giving me some clues to solve this. > All of this looks correct, which version of Android are you using ? Is it also possible to have the source of the cordova app you have built ? For the issue itself the team is looking at this. Thanks again for your interest. Seb > > > Miguel > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140219/92be52c9/attachment.html From matzew at apache.org Wed Feb 19 04:15:13 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 19 Feb 2014 10:15:13 +0100 Subject: [aerogear-dev] Issues with Aerogear on Cordova In-Reply-To: References: Message-ID: Hello Miguel, thanks for reaching out. One thing on the OpenShift documentation, what the URL you are referencing ? A few things on OpenShift versus local deployment: * http vs. https: For the OpenShift cartridges we have enabled https, If you run locally (e.g. inside of your JBoss/WildFly container) https is a pain, hence http might be referenced somewhere * CONTEXT: On Openshift the UnifiedPush Server is deployed as root (/) context. If you locally deploy the war file, the context is /nameOfYourWarFile Regarding not receving messages on the Android device: * what is the Android OS on the device * is there an (active) Google account on the device One more question: The registration works, right ? var pushConfig = { // senderID is only used in the Android/GCM case senderID: "SomeSenderID", pushServerURL: "someULR", variantID: "someID", variantSecret: "someSecret", alias: "someAlias" } Question: Do you see the device listed as the installation, on the OpenShift hosted Push Server ? Thanks, Matthias On Wed, Feb 19, 2014 at 9:58 AM, Miguel Lemos wrote: > Hello, > > I'm still struggling, for saying the least, with Aerogear documentation in > order to make a Cordova / Android app receive push notifications. > Amazingly one of the most unexpected issues has been with the correct > string to use on URLs to register or sending the notifications. > > Examples given by documentation: > > Openshift: > > curl -u "{PushApplicationID}:{MasterSecret}" > -v -H "Accept: application/json" -H "Content-type: application/json" > -X POST > -d '{ > "someKey":"someValue", > "alert":"HELLO!", > "sound":"default", > "badge":7, > "simple-push":"version=123" > }' > http://SERVER:PORT/CONTEXT/rest/sender/broadcast > > Aerogear: > > curl -3 -u "{pushApplicationID}:{masterSecret}" > -v -H "Accept: application/json" -H "Content-type: application/json" > -X POST -d '{"message": {"alert":"AeroGear UnifiedPush and Apache > Cordova 3.0.6", "badge":1}}' > https://SERVER:PORT/CONTEXT/rest/sender > > > How the above examples, apparently mean that, in my case, I must use > something like: https://aerogear-metalpush.rhcloud.com/rest/sender > maybe is very obvious for someone inside Aerogear lingo, but not at all > for me... > > Anyway, after I managed to overcome this, the answer I get from the server > is this one (stripped from more irrelevant parts): > > > POST /rest/sender HTTP/1.1 > > Authorization: Basic > MDBhMjFjZTMtYTdkOS00YzhjLWI1ODMtOWYwMjEwYTYzNGU1Ojk0MTE4NmIzLWVjNmEtNGY0OC1iMjZiLTJkMDYxZWIyM2Q5Yg== > > User-Agent: curl/7.30.0 > > Host: aerogear-metalpush.rhcloud.com > > Accept: application/json > > Content-type: application/json > > Content-Length: 50 > > > } [data not shown] > * upload completely sent off: 50 out of 50 bytes > < HTTP/1.1 200 OK > < Date: Tue, 18 Feb 2014 20:58:18 GMT > * Server Apache-Coyote/1.1 is not blacklisted > < Server: Apache-Coyote/1.1 > < Content-Type: application/json > < Content-Length: 13 > < Vary: Accept-Encoding > < > { [data not shown] > 100 63 100 13 100 50 11 44 0:00:01 0:00:01 > --:--:-- 44Job submitted > * Connection #0 to host aerogear-metalpush.rhcloud.com left intact > > > As far as I can guess, this means that the request was accepted. > Nevertheless, I receive nothing on the client's side. > On my phone the successHandler function throws a success message, meaning > that the equipment has managed to register at the service. > > And my code to receive the notifications is the same given in some > examples: > > function onNotification(e) { > alert(e.alert); > ) > > But nothing happens, tough. Thanks for giving me some clues to solve this. > > Miguel > > > _______________________________________________ > 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/20140219/f6ecfc8d/attachment.html From miguel21op at gmail.com Wed Feb 19 04:53:14 2014 From: miguel21op at gmail.com (Miguel Lemos) Date: Wed, 19 Feb 2014 09:53:14 +0000 Subject: [aerogear-dev] Issues with Aerogear on Cordova In-Reply-To: References: Message-ID: Hello, 1 > The Openshift explanation: https://www.openshift.com/blogs/mobile-push-simplified-with-the-aerogear-push-server-on-openshift 2 > I insist: the documentation / examples you give about the correct URLs to use is incoherent and not enough clear (sorry, this is my opinion); 3 > The Android version I use on the testing device: 4.2.1 and Cordova 3.3 4 > As I told you in my previous post the device registers correctly, meaning there is a token, etc of it on the server. See picture attached; 5> Yes there is an account, etc on Google service, where the Google cloud Messaging for Android is set to on (if you want I can send to you the credentials; later on I'll generate new ones); 6 > Please see attached the libraries I'm using on my Android app; 7 > The Javascript code inside my app: document.addEventListener('deviceready', function(){ var pushConfig = { // credentials not real; I thing this goes live... senderID: "278695548260", pushServerURL: "https://aerogear-metalpush.rhcloud.com", variantID: "821460c5-ez9f-41d8-903a-61e7bd132038", variantSecret: "43b0e5e4-f217-4f29-b15b-85f8f5748ee6" } try { push.register(successHandler, errorHandler, {"badge": "true", "sound": "true", "alert": "true", "ecb": "onNotification", pushConfig: pushConfig}); } catch (err) { txt = "Erro encontrado.\n\n"; txt += "Descri??o do erro: " + err.message + "\n\n"; alert(txt); } function successHandler(result) { var respush = document.getElementById("pushst"); respush.innerHTML = "Notifica??es: registo efetuado"; } function errorHandler(error) { var respush = document.getElementById("pushst"); respush.innerHTML = "Notific??es: registo falhado"; } function onNotification(e) { alert(e.alert); } }, false); I think I'm answering to all your questions. Any help appreciated. Feel free to ask whatever you need to enlighten this situation. Miguel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140219/df94c735/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: token.jpg Type: image/jpeg Size: 17661 bytes Desc: not available Url : http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140219/df94c735/attachment-0002.jpg -------------- next part -------------- A non-text attachment was scrubbed... Name: libraries.jpg Type: image/jpeg Size: 12802 bytes Desc: not available Url : http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140219/df94c735/attachment-0003.jpg From matzew at apache.org Wed Feb 19 05:08:38 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 19 Feb 2014 11:08:38 +0100 Subject: [aerogear-dev] Issues with Aerogear on Cordova In-Reply-To: References: Message-ID: On Wed, Feb 19, 2014 at 10:53 AM, Miguel Lemos wrote: > Hello, > > 1 > The Openshift explanation: > > > https://www.openshift.com/blogs/mobile-push-simplified-with-the-aerogear-push-server-on-openshift > > 2 > I insist: the documentation / examples you give about the correct > URLs to use is incoherent and not enough clear (sorry, this is my opinion); > ah, ok - yeah, that's an outdated blog of our first release (0.8.0); We will see if we can update that, as APIs have changed > > 3 > The Android version I use on the testing device: 4.2.1 and Cordova 3.3 > > 4 > As I told you in my previous post the device registers correctly, > meaning there is a token, etc of it on the server. See picture attached; > Great - the device is registered, that's good news > > 5> Yes there is an account, etc on Google service, where the Google cloud > Messaging for Android is set to on (if you want I can send to you the > credentials; later on I'll generate new ones); > > 6 > Please see attached the libraries I'm using on my Android app; > > 7 > The Javascript code inside my app: > > document.addEventListener('deviceready', function(){ > > var pushConfig = { // credentials not real; I > thing this goes live... > senderID: "278695548260", > pushServerURL: "https://aerogear-metalpush.rhcloud.com", > variantID: "821460c5-ez9f-41d8-903a-61e7bd132038", > variantSecret: "43b0e5e4-f217-4f29-b15b-85f8f5748ee6" > } > > try { > push.register(successHandler, errorHandler, {"badge": "true", > "sound": "true", > "alert": "true", "ecb": "onNotification", pushConfig: pushConfig}); > > } catch (err) { > txt = "Erro encontrado.\n\n"; > txt += "Descri??o do erro: " + err.message + "\n\n"; > alert(txt); > } > > function successHandler(result) { > var respush = document.getElementById("pushst"); > respush.innerHTML = "Notifica??es: registo efetuado"; > } > > function errorHandler(error) { > var respush = document.getElementById("pushst"); > respush.innerHTML = "Notific??es: registo falhado"; > } > > function onNotification(e) { > alert(e.alert); > } > Oh, just a thought - the scope of the 'onNotification' I always used it as a globla function, like: https://gist.github.com/matzew/ea739b09b3fbef487edd > > }, false); > > > I think I'm answering to all your questions. Any help appreciated. > Feel free to ask whatever you need to enlighten this situation. > > Miguel > > > > -- 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/20140219/2b605a16/attachment.html From scm.blanc at gmail.com Wed Feb 19 05:27:57 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Wed, 19 Feb 2014 11:27:57 +0100 Subject: [aerogear-dev] Issues with Aerogear on Cordova In-Reply-To: References: Message-ID: On Wed, Feb 19, 2014 at 11:08 AM, Matthias Wessendorf wrote: > > > > On Wed, Feb 19, 2014 at 10:53 AM, Miguel Lemos wrote: > >> Hello, >> >> 1 > The Openshift explanation: >> >> >> https://www.openshift.com/blogs/mobile-push-simplified-with-the-aerogear-push-server-on-openshift >> >> 2 > I insist: the documentation / examples you give about the correct >> URLs to use is incoherent and not enough clear (sorry, this is my opinion); >> > > ah, ok - yeah, that's an outdated blog of our first release (0.8.0); We > will see if we can update that, as APIs have changed > > > >> >> 3 > The Android version I use on the testing device: 4.2.1 and Cordova 3.3 >> >> 4 > As I told you in my previous post the device registers correctly, >> meaning there is a token, etc of it on the server. See picture attached; >> > > > Great - the device is registered, that's good news > > > > >> >> 5> Yes there is an account, etc on Google service, where the Google cloud >> Messaging for Android is set to on (if you want I can send to you the >> credentials; later on I'll generate new ones); >> >> 6 > Please see attached the libraries I'm using on my Android app; >> >> 7 > The Javascript code inside my app: >> >> document.addEventListener('deviceready', function(){ >> >> var pushConfig = { // credentials not real; I >> thing this goes live... >> senderID: "278695548260", >> pushServerURL: "https://aerogear-metalpush.rhcloud.com", >> variantID: "821460c5-ez9f-41d8-903a-61e7bd132038", >> variantSecret: "43b0e5e4-f217-4f29-b15b-85f8f5748ee6" >> } >> >> try { >> push.register(successHandler, errorHandler, {"badge": "true", >> "sound": "true", >> "alert": "true", "ecb": "onNotification", pushConfig: >> pushConfig}); >> >> } catch (err) { >> txt = "Erro encontrado.\n\n"; >> txt += "Descri??o do erro: " + err.message + "\n\n"; >> alert(txt); >> } >> >> function successHandler(result) { >> var respush = document.getElementById("pushst"); >> respush.innerHTML = "Notifica??es: registo efetuado"; >> } >> >> function errorHandler(error) { >> var respush = document.getElementById("pushst"); >> respush.innerHTML = "Notific??es: registo falhado"; >> } >> >> function onNotification(e) { >> alert(e.alert); >> } >> > > > Oh, just a thought - the scope of the 'onNotification' > > I always used it as a globla function, like: > > https://gist.github.com/matzew/ea739b09b3fbef487edd > You spotted the issue ! Miguel I just tried your code and indeed since the onNotif is not global it isn't called , try to get the same structure as in https://github.com/aerogear/aerogear-pushplugin-cordova/tree/master/example and it should work. > > >> >> }, false); >> >> >> I think I'm answering to all your questions. Any help appreciated. >> Feel free to ask whatever you need to enlighten this situation. >> >> Miguel >> >> >> >> > > > -- > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140219/35024a15/attachment.html From vivek.pandey at pinelabs.com Wed Feb 19 05:34:28 2014 From: vivek.pandey at pinelabs.com (Vivek Pandey) Date: Wed, 19 Feb 2014 16:04:28 +0530 Subject: [aerogear-dev] Sending Pushnotification by deviceId Message-ID: <02c501cf2d5e$2b757f10$82607d30$@pinelabs.com> Hello, While going through the aerogear-server-push documentation , I could not find an example where we can send a push message using "id" returned by adding a new device token at /rest/registry/device. Is there a plan to add such a support ? Is relying on unique "alias" a good option to implement the requirement of identifying a device uniquely ? Thanks Vivek This message may contain privileged and confidential information and is solely for the use of intended recipient. The views expressed in this email are those of the sender and not of Pine Labs. The recipient should check this email and attachments for the presence of viruses / malwares etc. Pine Labs accepts no liability for any damage caused by any virus transmitted by this email. Pine Labs may monitor and record all emails. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140219/25986feb/attachment-0001.html From matzew at apache.org Wed Feb 19 05:41:55 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 19 Feb 2014 11:41:55 +0100 Subject: [aerogear-dev] Sending Pushnotification by deviceId In-Reply-To: <02c501cf2d5e$2b757f10$82607d30$@pinelabs.com> References: <02c501cf2d5e$2b757f10$82607d30$@pinelabs.com> Message-ID: Hello Vivek, thanks for the interest in our project On Wed, Feb 19, 2014 at 11:34 AM, Vivek Pandey wrote: > Hello, > > > > While going through the aerogear-server-push documentation , I could not > find an example where we can send a push message using "id" returned by > adding a new device token at /rest/registry/device. > > > > Is there a plan to add such a support ? > We have a ticket for that: https://issues.jboss.org/browse/AGPUSH-420 but we did not do it, ATM, as this is hard to do for the supported SimplePush bits (e.g. for FirefoxOS). We thought about using the device token (e.g. from APNs or the registrationID from GCM), but w/ SimplePush / Mozilla's FirefoxOS this is really an URI. However, you raised a great point, each installation gets an ID in our database - perhaps we could use that. But that means "your application" needs to store our ID somewhere (in addition to GCM/APNs IDs and Mozilla's Push URI). But I do like the ideas > Is relying on unique "alias" a good option to implement the requirement of > identifying a device uniquely ? > > > > Thanks > > Vivek > > ------------------------------ > This message may contain privileged and confidential information and is > solely for the use of intended recipient. The views expressed in this email > are those of the sender and not of Pine Labs. The recipient should check > this email and attachments for the presence of viruses / malwares etc. Pine > Labs accepts no liability for any damage caused by any virus transmitted by > this email. Pine Labs may monitor and record all emails. > ------------------------------ > > > _______________________________________________ > 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/20140219/7dff7ff0/attachment.html From matzew at apache.org Wed Feb 19 05:43:33 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 19 Feb 2014 11:43:33 +0100 Subject: [aerogear-dev] Sending Pushnotification by deviceId In-Reply-To: References: <02c501cf2d5e$2b757f10$82607d30$@pinelabs.com> Message-ID: On Wed, Feb 19, 2014 at 11:41 AM, Matthias Wessendorf wrote: > Hello Vivek, > > thanks for the interest in our project > > > On Wed, Feb 19, 2014 at 11:34 AM, Vivek Pandey wrote: > >> Hello, >> >> >> >> While going through the aerogear-server-push documentation , I could not >> find an example where we can send a push message using "id" returned by >> adding a new device token at /rest/registry/device. >> >> >> >> Is there a plan to add such a support ? >> > > We have a ticket for that: > https://issues.jboss.org/browse/AGPUSH-420 > > but we did not do it, ATM, as this is hard to do for the supported > SimplePush bits (e.g. for FirefoxOS). > We thought about using the device token (e.g. from APNs or the > registrationID from GCM), but w/ SimplePush / Mozilla's FirefoxOS this is > really an URI. > > However, you raised a great point, each installation gets an ID in our > database - perhaps we could use that. But that means "your application" > needs to store our ID somewhere (in addition to GCM/APNs IDs and Mozilla's > Push URI). But I do like the ideas > > >> Is relying on unique "alias" a good option to implement the requirement >> of identifying a device uniquely ? >> > The benefit of an alias is, that all the devices of a user (e.g. mrFoo at company.com). So, for instance if someone wants to do a google hangout, all of your devices get that message But, it's for sure of a matter of the actual use-case > >> >> Thanks >> >> Vivek >> >> ------------------------------ >> This message may contain privileged and confidential information and is >> solely for the use of intended recipient. The views expressed in this email >> are those of the sender and not of Pine Labs. The recipient should check >> this email and attachments for the presence of viruses / malwares etc. Pine >> Labs accepts no liability for any damage caused by any virus transmitted by >> this email. Pine Labs may monitor and record all emails. >> ------------------------------ >> >> >> _______________________________________________ >> 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 > -- 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/20140219/3c52ce5f/attachment.html From matzew at apache.org Wed Feb 19 06:16:20 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 19 Feb 2014 12:16:20 +0100 Subject: [aerogear-dev] UnifiedPush release Message-ID: Hello, I am happy to announce two new releases: * UnifiedPush Server 0.10.0 * unifiedpush-java-client 0.5.0 The entire change log of the server can be found here: https://issues.jboss.org/browse/AGPUSH/fixforversion/12321876 A few highlights: * iOS7 silent/background message support * GCM support for Chrome browser * Admin UI updates and tweaks * Postgresql support I have submitted a PR against our project homepage to reflect the recent version updates: https://github.com/aerogear/aerogear.org/pull/256 Our OpenShift offering: Early March we will update the OpenShift cartridge, after the 0.10.0 version of our SimplePush Server has been released. If you have any questions or feedback - let us know! Greetings, Matthias -- 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/20140219/a1e2c30f/attachment.html From corinnekrych at gmail.com Wed Feb 19 07:03:04 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Wed, 19 Feb 2014 13:03:04 +0100 Subject: [aerogear-dev] Issues with Aerogear on Cordova In-Reply-To: References: Message-ID: Yep well spotted. That was my issue too when testing: https://github.com/aerogear/aerogear-pushplugin-cordova/pull/14 I think it would worth a Note warning in the readme ;) ++ Corinne On 19 February 2014 11:27, Sebastien Blanc wrote: > > > > On Wed, Feb 19, 2014 at 11:08 AM, Matthias Wessendorf wrote: > >> >> >> >> On Wed, Feb 19, 2014 at 10:53 AM, Miguel Lemos wrote: >> >>> Hello, >>> >>> 1 > The Openshift explanation: >>> >>> >>> https://www.openshift.com/blogs/mobile-push-simplified-with-the-aerogear-push-server-on-openshift >>> >>> 2 > I insist: the documentation / examples you give about the correct >>> URLs to use is incoherent and not enough clear (sorry, this is my opinion); >>> >> >> ah, ok - yeah, that's an outdated blog of our first release (0.8.0); We >> will see if we can update that, as APIs have changed >> >> >> >>> >>> 3 > The Android version I use on the testing device: 4.2.1 and Cordova >>> 3.3 >>> >>> 4 > As I told you in my previous post the device registers correctly, >>> meaning there is a token, etc of it on the server. See picture attached; >>> >> >> >> Great - the device is registered, that's good news >> >> >> >> >>> >>> 5> Yes there is an account, etc on Google service, where the Google >>> cloud Messaging for Android is set to on (if you want I can send to you the >>> credentials; later on I'll generate new ones); >>> >>> 6 > Please see attached the libraries I'm using on my Android app; >>> >>> 7 > The Javascript code inside my app: >>> >>> document.addEventListener('deviceready', function(){ >>> >>> var pushConfig = { // credentials not real; I >>> thing this goes live... >>> senderID: "278695548260", >>> pushServerURL: "https://aerogear-metalpush.rhcloud.com", >>> variantID: "821460c5-ez9f-41d8-903a-61e7bd132038", >>> variantSecret: "43b0e5e4-f217-4f29-b15b-85f8f5748ee6" >>> } >>> >>> try { >>> push.register(successHandler, errorHandler, {"badge": "true", >>> "sound": "true", >>> "alert": "true", "ecb": "onNotification", pushConfig: >>> pushConfig}); >>> >>> } catch (err) { >>> txt = "Erro encontrado.\n\n"; >>> txt += "Descri??o do erro: " + err.message + "\n\n"; >>> alert(txt); >>> } >>> >>> function successHandler(result) { >>> var respush = document.getElementById("pushst"); >>> respush.innerHTML = "Notifica??es: registo efetuado"; >>> } >>> >>> function errorHandler(error) { >>> var respush = document.getElementById("pushst"); >>> respush.innerHTML = "Notific??es: registo falhado"; >>> } >>> >>> function onNotification(e) { >>> alert(e.alert); >>> } >>> >> >> >> Oh, just a thought - the scope of the 'onNotification' >> >> I always used it as a globla function, like: >> >> https://gist.github.com/matzew/ea739b09b3fbef487edd >> > > You spotted the issue ! > Miguel I just tried your code and indeed since the onNotif is not global > it isn't called , try to get the same structure as in > https://github.com/aerogear/aerogear-pushplugin-cordova/tree/master/example and > it should work. > > >> >> >>> >>> }, false); >>> >>> >>> I think I'm answering to all your questions. Any help appreciated. >>> Feel free to ask whatever you need to enlighten this situation. >>> >>> Miguel >>> >>> >>> >>> >> >> >> -- >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140219/80cee288/attachment-0001.html From bruno at abstractj.org Wed Feb 19 07:16:59 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Wed, 19 Feb 2014 09:16:59 -0300 Subject: [aerogear-dev] UnifiedPush release In-Reply-To: References: Message-ID: Congratulations slackers. -- abstractj On February 19, 2014 at 8:16:29 AM, Matthias Wessendorf (matzew at apache.org) wrote: > > Hello, > > I am happy to announce two new releases: > > * UnifiedPush Server 0.10.0 > * unifiedpush-java-client 0.5.0 > > The entire change log of the server can be found here: > https://issues.jboss.org/browse/AGPUSH/fixforversion/12321876 > > A few highlights: > > * iOS7 silent/background message support > * GCM support for Chrome browser > * Admin UI updates and tweaks > * Postgresql support > > I have submitted a PR against our project homepage to reflect > the recent > version updates: > https://github.com/aerogear/aerogear.org/pull/256 > > Our OpenShift offering: > Early March we will update the OpenShift cartridge, after the > 0.10.0 > version of our SimplePush Server has been released. > > If you have any questions or feedback - let us know! > > Greetings, > 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 From miguel21op at gmail.com Wed Feb 19 07:20:02 2014 From: miguel21op at gmail.com (Miguel Lemos) Date: Wed, 19 Feb 2014 12:20:02 +0000 Subject: [aerogear-dev] Issues with Aerogear on Cordova In-Reply-To: References: Message-ID: Hi all, I tested and now it works, thanks. When I tried for the first time, I tried with the function global, reflecting the Github example. But as it didn't work (because of the "damn" URL issue...) I tried several things, one of them being put the alert function inside the deviceready event. Of course, when I solved the URL thing I never more remembered to put it outside again... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140219/6b4b205b/attachment.html From matzew at apache.org Wed Feb 19 08:04:02 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 19 Feb 2014 14:04:02 +0100 Subject: [aerogear-dev] Issues with Aerogear on Cordova In-Reply-To: References: Message-ID: On Wed, Feb 19, 2014 at 1:20 PM, Miguel Lemos wrote: > Hi all, > > I tested and now it works, thanks. > glad it all worked out > > When I tried for the first time, I tried with the function global, > reflecting the Github example. But as it didn't work (because of the "damn" > URL issue...) I tried several things, one of them being put the alert > function inside the deviceready event. Of course, when I solved the URL > thing I never more remembered to put it outside again... > Things like that might happen. Regarding the URL, we will try to update the OpenShift blog post. I just checkout project documentation, and it looks like they are already 'right'. Wondering: Are you building Cordova clients for Android only, or do you plan to use the iOS platform as well ? Greetings, Matthias > > > _______________________________________________ > 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/20140219/8c27b07f/attachment.html From miguel21op at gmail.com Wed Feb 19 08:18:21 2014 From: miguel21op at gmail.com (Miguel Lemos) Date: Wed, 19 Feb 2014 13:18:21 +0000 Subject: [aerogear-dev] Issues with Aerogear on Cordova In-Reply-To: References: Message-ID: Hi Matthias, One of the biggest reasons I'm testing this solutions is because iOS! Once we already developed a full native Android push (considering geofencing) notification service. The issue is to port our solution to iOS (not only the notifications, but everything). That's why I'm personally testing Cordova on Android and already partially on IOS. So far so good.. I'm starting with Android because it's easier to me. But next week I want to test your solution with iOS. Why? Is there any problem? Thanks Miguel On Wed, Feb 19, 2014 at 1:04 PM, Matthias Wessendorf wrote: > > > > On Wed, Feb 19, 2014 at 1:20 PM, Miguel Lemos wrote: > >> Hi all, >> >> I tested and now it works, thanks. >> > > glad it all worked out > > >> >> When I tried for the first time, I tried with the function global, >> reflecting the Github example. But as it didn't work (because of the "damn" >> URL issue...) I tried several things, one of them being put the alert >> function inside the deviceready event. Of course, when I solved the URL >> thing I never more remembered to put it outside again... >> > > Things like that might happen. > > Regarding the URL, we will try to update the OpenShift blog post. > > I just checkout project documentation, and it looks like they are already > 'right'. > > > > Wondering: Are you building Cordova clients for Android only, or do you > plan to use the iOS platform as well ? > > Greetings, > Matthias > > >> >> >> _______________________________________________ >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140219/0a18d06a/attachment.html From matzew at apache.org Wed Feb 19 08:25:44 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 19 Feb 2014 14:25:44 +0100 Subject: [aerogear-dev] Issues with Aerogear on Cordova In-Reply-To: References: Message-ID: On Wed, Feb 19, 2014 at 2:18 PM, Miguel Lemos wrote: > Hi Matthias, > > One of the biggest reasons I'm testing this solutions is because iOS! > > Once we already developed a full native Android push (considering > geofencing) notification service. The issue is to port our solution to iOS > (not only the notifications, but everything). That's why I'm personally > testing Cordova on Android and already partially on IOS. So far so good.. > Sounds very interesting. If you are interested, let us know how it goes. > > I'm starting with Android because it's easier to me. But next week I want > to test your solution with iOS. Why? Is there any problem? > No problem there at all :-) I was just curious if you target Android first/only. Greetings, Matthias > > Thanks > > Miguel > > > > On Wed, Feb 19, 2014 at 1:04 PM, Matthias Wessendorf wrote: > >> >> >> >> On Wed, Feb 19, 2014 at 1:20 PM, Miguel Lemos wrote: >> >>> Hi all, >>> >>> I tested and now it works, thanks. >>> >> >> glad it all worked out >> >> >>> >>> When I tried for the first time, I tried with the function global, >>> reflecting the Github example. But as it didn't work (because of the "damn" >>> URL issue...) I tried several things, one of them being put the alert >>> function inside the deviceready event. Of course, when I solved the URL >>> thing I never more remembered to put it outside again... >>> >> >> Things like that might happen. >> >> Regarding the URL, we will try to update the OpenShift blog post. >> >> I just checkout project documentation, and it looks like they are already >> 'right'. >> >> >> >> Wondering: Are you building Cordova clients for Android only, or do you >> plan to use the iOS platform as well ? >> >> Greetings, >> Matthias >> >> >>> >>> >>> _______________________________________________ >>> 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/20140219/d79e4f01/attachment-0001.html From miguel21op at gmail.com Wed Feb 19 08:29:31 2014 From: miguel21op at gmail.com (Miguel Lemos) Date: Wed, 19 Feb 2014 13:29:31 +0000 Subject: [aerogear-dev] Issues with Aerogear on Cordova In-Reply-To: References: Message-ID: Thanks. Of course I'll give you my feedback ;-) I've some questions about the service as a whole, but I'll make some more testing and then I'll let you know. Thank you very much again for your attention. All the best, Miguel On Wed, Feb 19, 2014 at 1:25 PM, Matthias Wessendorf wrote: > > > > On Wed, Feb 19, 2014 at 2:18 PM, Miguel Lemos wrote: > >> Hi Matthias, >> >> One of the biggest reasons I'm testing this solutions is because iOS! >> >> Once we already developed a full native Android push (considering >> geofencing) notification service. The issue is to port our solution to iOS >> (not only the notifications, but everything). That's why I'm personally >> testing Cordova on Android and already partially on IOS. So far so good.. >> > > Sounds very interesting. If you are interested, let us know how it goes. > > >> >> I'm starting with Android because it's easier to me. But next week I want >> to test your solution with iOS. Why? Is there any problem? >> > > No problem there at all :-) I was just curious if you target Android > first/only. > > Greetings, > Matthias > > >> >> Thanks >> >> Miguel >> >> >> >> On Wed, Feb 19, 2014 at 1:04 PM, Matthias Wessendorf wrote: >> >>> >>> >>> >>> On Wed, Feb 19, 2014 at 1:20 PM, Miguel Lemos wrote: >>> >>>> Hi all, >>>> >>>> I tested and now it works, thanks. >>>> >>> >>> glad it all worked out >>> >>> >>>> >>>> When I tried for the first time, I tried with the function global, >>>> reflecting the Github example. But as it didn't work (because of the "damn" >>>> URL issue...) I tried several things, one of them being put the alert >>>> function inside the deviceready event. Of course, when I solved the URL >>>> thing I never more remembered to put it outside again... >>>> >>> >>> Things like that might happen. >>> >>> Regarding the URL, we will try to update the OpenShift blog post. >>> >>> I just checkout project documentation, and it looks like they are >>> already 'right'. >>> >>> >>> >>> Wondering: Are you building Cordova clients for Android only, or do you >>> plan to use the iOS platform as well ? >>> >>> Greetings, >>> Matthias >>> >>> >>>> >>>> >>>> _______________________________________________ >>>> 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 > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140219/13d53caa/attachment.html From matzew at apache.org Wed Feb 19 08:34:31 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 19 Feb 2014 14:34:31 +0100 Subject: [aerogear-dev] Issues with Aerogear on Cordova In-Reply-To: References: Message-ID: Awesome, we are interested in hearing your feedback. Good luck w/ the development process! -Matthias On Wed, Feb 19, 2014 at 2:29 PM, Miguel Lemos wrote: > Thanks. Of course I'll give you my feedback ;-) > > I've some questions about the service as a whole, but I'll make some more > testing and then I'll let you know. > > Thank you very much again for your attention. > > All the best, > > Miguel > > > On Wed, Feb 19, 2014 at 1:25 PM, Matthias Wessendorf wrote: > >> >> >> >> On Wed, Feb 19, 2014 at 2:18 PM, Miguel Lemos wrote: >> >>> Hi Matthias, >>> >>> One of the biggest reasons I'm testing this solutions is because iOS! >>> >>> Once we already developed a full native Android push (considering >>> geofencing) notification service. The issue is to port our solution to iOS >>> (not only the notifications, but everything). That's why I'm personally >>> testing Cordova on Android and already partially on IOS. So far so good.. >>> >> >> Sounds very interesting. If you are interested, let us know how it goes. >> >> >>> >>> I'm starting with Android because it's easier to me. But next week I >>> want to test your solution with iOS. Why? Is there any problem? >>> >> >> No problem there at all :-) I was just curious if you target Android >> first/only. >> >> Greetings, >> Matthias >> >> >>> >>> Thanks >>> >>> Miguel >>> >>> >>> >>> On Wed, Feb 19, 2014 at 1:04 PM, Matthias Wessendorf wrote: >>> >>>> >>>> >>>> >>>> On Wed, Feb 19, 2014 at 1:20 PM, Miguel Lemos wrote: >>>> >>>>> Hi all, >>>>> >>>>> I tested and now it works, thanks. >>>>> >>>> >>>> glad it all worked out >>>> >>>> >>>>> >>>>> When I tried for the first time, I tried with the function global, >>>>> reflecting the Github example. But as it didn't work (because of the "damn" >>>>> URL issue...) I tried several things, one of them being put the alert >>>>> function inside the deviceready event. Of course, when I solved the URL >>>>> thing I never more remembered to put it outside again... >>>>> >>>> >>>> Things like that might happen. >>>> >>>> Regarding the URL, we will try to update the OpenShift blog post. >>>> >>>> I just checkout project documentation, and it looks like they are >>>> already 'right'. >>>> >>>> >>>> >>>> Wondering: Are you building Cordova clients for Android only, or do you >>>> plan to use the iOS platform as well ? >>>> >>>> Greetings, >>>> Matthias >>>> >>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >> >> _______________________________________________ >> 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/20140219/4abb2e1f/attachment.html From miguel21op at gmail.com Wed Feb 19 09:43:40 2014 From: miguel21op at gmail.com (Miguel Lemos) Date: Wed, 19 Feb 2014 14:43:40 +0000 Subject: [aerogear-dev] Issues with Aerogear on Cordova In-Reply-To: References: Message-ID: Dear Matthias, According to the information posted in the url below, I can send (and read) several parameters / keys in the scope of the notification service (as it should be...): http://aerogear.org/docs/specs/aerogear-push-messages/ According to the values on it, the receiver should have the capacity to decide what to do next. First, and the easiest thing: don't show the "Alert" text, but any other part of content received and / or change "Alert" to another language, for instance. Second, if I create (for instance) a lat, lon and rad parameters, I can decide if I show the notification immediately, or only when the user reaches a matchable location, within a given radius. This is just an example of the freedom that must be available to decide what to do according to a given parameter that the software on the client's side can interpret. The message itself may not be the most important part of the whole thing... So, the question is: how can I read those parameters / keys before deciding to do with the notification? Through a "regular" object keys iterator? Thank you very much again. If there's some place in the documentation where I can understand that, please let me know. Miguel On Wed, Feb 19, 2014 at 1:34 PM, Matthias Wessendorf wrote: > Awesome, > > we are interested in hearing your feedback. > > Good luck w/ the development process! > > -Matthias > > > On Wed, Feb 19, 2014 at 2:29 PM, Miguel Lemos wrote: > >> Thanks. Of course I'll give you my feedback ;-) >> >> I've some questions about the service as a whole, but I'll make some more >> testing and then I'll let you know. >> >> Thank you very much again for your attention. >> >> All the best, >> >> Miguel >> >> >> On Wed, Feb 19, 2014 at 1:25 PM, Matthias Wessendorf wrote: >> >>> >>> >>> >>> On Wed, Feb 19, 2014 at 2:18 PM, Miguel Lemos wrote: >>> >>>> Hi Matthias, >>>> >>>> One of the biggest reasons I'm testing this solutions is because iOS! >>>> >>>> Once we already developed a full native Android push (considering >>>> geofencing) notification service. The issue is to port our solution to iOS >>>> (not only the notifications, but everything). That's why I'm personally >>>> testing Cordova on Android and already partially on IOS. So far so good.. >>>> >>> >>> Sounds very interesting. If you are interested, let us know how it goes. >>> >>> >>>> >>>> I'm starting with Android because it's easier to me. But next week I >>>> want to test your solution with iOS. Why? Is there any problem? >>>> >>> >>> No problem there at all :-) I was just curious if you target Android >>> first/only. >>> >>> Greetings, >>> Matthias >>> >>> >>>> >>>> Thanks >>>> >>>> Miguel >>>> >>>> >>>> >>>> On Wed, Feb 19, 2014 at 1:04 PM, Matthias Wessendorf >>> > wrote: >>>> >>>>> >>>>> >>>>> >>>>> On Wed, Feb 19, 2014 at 1:20 PM, Miguel Lemos wrote: >>>>> >>>>>> Hi all, >>>>>> >>>>>> I tested and now it works, thanks. >>>>>> >>>>> >>>>> glad it all worked out >>>>> >>>>> >>>>>> >>>>>> When I tried for the first time, I tried with the function global, >>>>>> reflecting the Github example. But as it didn't work (because of the "damn" >>>>>> URL issue...) I tried several things, one of them being put the alert >>>>>> function inside the deviceready event. Of course, when I solved the URL >>>>>> thing I never more remembered to put it outside again... >>>>>> >>>>> >>>>> Things like that might happen. >>>>> >>>>> Regarding the URL, we will try to update the OpenShift blog post. >>>>> >>>>> I just checkout project documentation, and it looks like they are >>>>> already 'right'. >>>>> >>>>> >>>>> >>>>> Wondering: Are you building Cordova clients for Android only, or do >>>>> you plan to use the iOS platform as well ? >>>>> >>>>> Greetings, >>>>> Matthias >>>>> >>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>> >>> _______________________________________________ >>> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140219/1fb0cc53/attachment-0001.html From matzew at apache.org Wed Feb 19 10:05:57 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 19 Feb 2014 16:05:57 +0100 Subject: [aerogear-dev] Issues with Aerogear on Cordova In-Reply-To: References: Message-ID: On Wed, Feb 19, 2014 at 3:43 PM, Miguel Lemos wrote: > Dear Matthias, > > According to the information posted in the url below, I can send (and > read) several parameters / keys in the scope of the notification service > (as it should be...): > > http://aerogear.org/docs/specs/aerogear-push-messages/ > > According to the values on it, the receiver should have the capacity to > decide what to do next. > > First, and the easiest thing: don't show the "Alert" text, but any other > part of content received and / or change "Alert" to another language, for > instance. > Not sure I follow. The 'alert' is a keyword on iOS, which our server (and our Cordova Libs) do recognize. What do you want to change there ? For the completion of our spec, we are showing all of the keywords, that are supported. > > Second, if I create (for instance) a lat, lon and rad parameters, I can > decide if I show the notification immediately, or only when the user > reaches a matchable location, within a given radius. > This is just an example of the freedom that must be available to decide > what to do according to a given parameter that the software on the client's > side can interpret. The message itself may not be the most important part > of the whole thing... > If you don't want or need that alert, simply leave it our of the payload. It's just part of the demo/docs as that is quite handy to get going. > > So, the question is: how can I read those parameters / keys before > deciding to do with the notification? Through a "regular" object keys > iterator? Thank you very much again. If there's some place in the > documentation where I can understand that, please let me know. > yes, like here (using alert just as an example): function onNotification(e) { alert(e.payload.foo); alert(e.payload.key); } And the curl for that would be something _like_ this: curl -3 -u "ID:secrect" -v -H "Accept: application/json" -H "Content-type: application/json" -X POST -d '{"message": {"foo":"bar value", "key":"HELLO"}}' https://something-doamin.rhcloud.com/rest/sender -Matthias > > > Miguel > > > > On Wed, Feb 19, 2014 at 1:34 PM, Matthias Wessendorf wrote: > >> Awesome, >> >> we are interested in hearing your feedback. >> >> Good luck w/ the development process! >> >> -Matthias >> >> >> On Wed, Feb 19, 2014 at 2:29 PM, Miguel Lemos wrote: >> >>> Thanks. Of course I'll give you my feedback ;-) >>> >>> I've some questions about the service as a whole, but I'll make some >>> more testing and then I'll let you know. >>> >>> Thank you very much again for your attention. >>> >>> All the best, >>> >>> Miguel >>> >>> >>> On Wed, Feb 19, 2014 at 1:25 PM, Matthias Wessendorf wrote: >>> >>>> >>>> >>>> >>>> On Wed, Feb 19, 2014 at 2:18 PM, Miguel Lemos wrote: >>>> >>>>> Hi Matthias, >>>>> >>>>> One of the biggest reasons I'm testing this solutions is because iOS! >>>>> >>>>> Once we already developed a full native Android push (considering >>>>> geofencing) notification service. The issue is to port our solution to iOS >>>>> (not only the notifications, but everything). That's why I'm personally >>>>> testing Cordova on Android and already partially on IOS. So far so good.. >>>>> >>>> >>>> Sounds very interesting. If you are interested, let us know how it >>>> goes. >>>> >>>> >>>>> >>>>> I'm starting with Android because it's easier to me. But next week I >>>>> want to test your solution with iOS. Why? Is there any problem? >>>>> >>>> >>>> No problem there at all :-) I was just curious if you target Android >>>> first/only. >>>> >>>> Greetings, >>>> Matthias >>>> >>>> >>>>> >>>>> Thanks >>>>> >>>>> Miguel >>>>> >>>>> >>>>> >>>>> On Wed, Feb 19, 2014 at 1:04 PM, Matthias Wessendorf < >>>>> matzew at apache.org> wrote: >>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Wed, Feb 19, 2014 at 1:20 PM, Miguel Lemos wrote: >>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> I tested and now it works, thanks. >>>>>>> >>>>>> >>>>>> glad it all worked out >>>>>> >>>>>> >>>>>>> >>>>>>> When I tried for the first time, I tried with the function global, >>>>>>> reflecting the Github example. But as it didn't work (because of the "damn" >>>>>>> URL issue...) I tried several things, one of them being put the alert >>>>>>> function inside the deviceready event. Of course, when I solved the URL >>>>>>> thing I never more remembered to put it outside again... >>>>>>> >>>>>> >>>>>> Things like that might happen. >>>>>> >>>>>> Regarding the URL, we will try to update the OpenShift blog post. >>>>>> >>>>>> I just checkout project documentation, and it looks like they are >>>>>> already 'right'. >>>>>> >>>>>> >>>>>> >>>>>> Wondering: Are you building Cordova clients for Android only, or do >>>>>> you plan to use the iOS platform as well ? >>>>>> >>>>>> Greetings, >>>>>> Matthias >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>> >>>> _______________________________________________ >>>> 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/20140219/a5b01c97/attachment.html From miguel21op at gmail.com Wed Feb 19 10:20:36 2014 From: miguel21op at gmail.com (Miguel Lemos) Date: Wed, 19 Feb 2014 15:20:36 +0000 Subject: [aerogear-dev] Issues with Aerogear on Cordova In-Reply-To: References: Message-ID: Hi Matthias, Maybe I didn't make myself clear, but your answer was clear enough to respond to my post :-) Thanks again. Carry on! M On Wed, Feb 19, 2014 at 3:05 PM, Matthias Wessendorf wrote: > > > > On Wed, Feb 19, 2014 at 3:43 PM, Miguel Lemos wrote: > >> Dear Matthias, >> >> According to the information posted in the url below, I can send (and >> read) several parameters / keys in the scope of the notification service >> (as it should be...): >> >> http://aerogear.org/docs/specs/aerogear-push-messages/ >> >> According to the values on it, the receiver should have the capacity to >> decide what to do next. >> >> First, and the easiest thing: don't show the "Alert" text, but any other >> part of content received and / or change "Alert" to another language, for >> instance. >> > > Not sure I follow. > > The 'alert' is a keyword on iOS, which our server (and our Cordova Libs) > do recognize. What do you want to change there ? > For the completion of our spec, we are showing all of the keywords, that > are supported. > > > >> >> Second, if I create (for instance) a lat, lon and rad parameters, I can >> decide if I show the notification immediately, or only when the user >> reaches a matchable location, within a given radius. >> This is just an example of the freedom that must be available to decide >> what to do according to a given parameter that the software on the client's >> side can interpret. The message itself may not be the most important part >> of the whole thing... >> > > If you don't want or need that alert, simply leave it our of the payload. > It's just part of the demo/docs as that is quite handy to get going. > > >> >> So, the question is: how can I read those parameters / keys before >> deciding to do with the notification? Through a "regular" object keys >> iterator? Thank you very much again. If there's some place in the >> documentation where I can understand that, please let me know. >> > > yes, like here (using alert just as an example): > > > function onNotification(e) { > alert(e.payload.foo); > alert(e.payload.key); > } > > And the curl for that would be something _like_ this: > curl -3 -u "ID:secrect" -v -H "Accept: application/json" -H "Content-type: > application/json" -X POST -d '{"message": {"foo":"bar value", > "key":"HELLO"}}' https://something-doamin.rhcloud.com/rest/sender > > > -Matthias > > > > >> >> >> Miguel >> >> >> >> On Wed, Feb 19, 2014 at 1:34 PM, Matthias Wessendorf wrote: >> >>> Awesome, >>> >>> we are interested in hearing your feedback. >>> >>> Good luck w/ the development process! >>> >>> -Matthias >>> >>> >>> On Wed, Feb 19, 2014 at 2:29 PM, Miguel Lemos wrote: >>> >>>> Thanks. Of course I'll give you my feedback ;-) >>>> >>>> I've some questions about the service as a whole, but I'll make some >>>> more testing and then I'll let you know. >>>> >>>> Thank you very much again for your attention. >>>> >>>> All the best, >>>> >>>> Miguel >>>> >>>> >>>> On Wed, Feb 19, 2014 at 1:25 PM, Matthias Wessendorf >>> > wrote: >>>> >>>>> >>>>> >>>>> >>>>> On Wed, Feb 19, 2014 at 2:18 PM, Miguel Lemos wrote: >>>>> >>>>>> Hi Matthias, >>>>>> >>>>>> One of the biggest reasons I'm testing this solutions is because iOS! >>>>>> >>>>>> Once we already developed a full native Android push (considering >>>>>> geofencing) notification service. The issue is to port our solution to iOS >>>>>> (not only the notifications, but everything). That's why I'm personally >>>>>> testing Cordova on Android and already partially on IOS. So far so good.. >>>>>> >>>>> >>>>> Sounds very interesting. If you are interested, let us know how it >>>>> goes. >>>>> >>>>> >>>>>> >>>>>> I'm starting with Android because it's easier to me. But next week I >>>>>> want to test your solution with iOS. Why? Is there any problem? >>>>>> >>>>> >>>>> No problem there at all :-) I was just curious if you target Android >>>>> first/only. >>>>> >>>>> Greetings, >>>>> Matthias >>>>> >>>>> >>>>>> >>>>>> Thanks >>>>>> >>>>>> Miguel >>>>>> >>>>>> >>>>>> >>>>>> On Wed, Feb 19, 2014 at 1:04 PM, Matthias Wessendorf < >>>>>> matzew at apache.org> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Wed, Feb 19, 2014 at 1:20 PM, Miguel Lemos wrote: >>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> I tested and now it works, thanks. >>>>>>>> >>>>>>> >>>>>>> glad it all worked out >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> When I tried for the first time, I tried with the function global, >>>>>>>> reflecting the Github example. But as it didn't work (because of the "damn" >>>>>>>> URL issue...) I tried several things, one of them being put the alert >>>>>>>> function inside the deviceready event. Of course, when I solved the URL >>>>>>>> thing I never more remembered to put it outside again... >>>>>>>> >>>>>>> >>>>>>> Things like that might happen. >>>>>>> >>>>>>> Regarding the URL, we will try to update the OpenShift blog post. >>>>>>> >>>>>>> I just checkout project documentation, and it looks like they are >>>>>>> already 'right'. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Wondering: Are you building Cordova clients for Android only, or do >>>>>>> you plan to use the iOS platform as well ? >>>>>>> >>>>>>> Greetings, >>>>>>> Matthias >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>> >>>>> _______________________________________________ >>>>> 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 > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140219/2fbfe0ef/attachment-0001.html From miguel21op at gmail.com Wed Feb 19 10:38:53 2014 From: miguel21op at gmail.com (Miguel Lemos) Date: Wed, 19 Feb 2014 15:38:53 +0000 Subject: [aerogear-dev] Issues with Aerogear on Cordova In-Reply-To: References: Message-ID: A small souvenir ;-) Thanks again On Wed, Feb 19, 2014 at 3:20 PM, Miguel Lemos wrote: > Hi Matthias, > > Maybe I didn't make myself clear, but your answer was clear enough to > respond to my post :-) > > Thanks again. > > Carry on! > > M > > > > On Wed, Feb 19, 2014 at 3:05 PM, Matthias Wessendorf wrote: > >> >> >> >> On Wed, Feb 19, 2014 at 3:43 PM, Miguel Lemos wrote: >> >>> Dear Matthias, >>> >>> According to the information posted in the url below, I can send (and >>> read) several parameters / keys in the scope of the notification service >>> (as it should be...): >>> >>> http://aerogear.org/docs/specs/aerogear-push-messages/ >>> >>> According to the values on it, the receiver should have the capacity to >>> decide what to do next. >>> >>> First, and the easiest thing: don't show the "Alert" text, but any >>> other part of content received and / or change "Alert" to another >>> language, for instance. >>> >> >> Not sure I follow. >> >> The 'alert' is a keyword on iOS, which our server (and our Cordova Libs) >> do recognize. What do you want to change there ? >> For the completion of our spec, we are showing all of the keywords, that >> are supported. >> >> >> >>> >>> Second, if I create (for instance) a lat, lon and rad parameters, I can >>> decide if I show the notification immediately, or only when the user >>> reaches a matchable location, within a given radius. >>> This is just an example of the freedom that must be available to decide >>> what to do according to a given parameter that the software on the client's >>> side can interpret. The message itself may not be the most important part >>> of the whole thing... >>> >> >> If you don't want or need that alert, simply leave it our of the payload. >> It's just part of the demo/docs as that is quite handy to get going. >> >> >>> >>> So, the question is: how can I read those parameters / keys before >>> deciding to do with the notification? Through a "regular" object keys >>> iterator? Thank you very much again. If there's some place in the >>> documentation where I can understand that, please let me know. >>> >> >> yes, like here (using alert just as an example): >> >> >> function onNotification(e) { >> alert(e.payload.foo); >> alert(e.payload.key); >> } >> >> And the curl for that would be something _like_ this: >> curl -3 -u "ID:secrect" -v -H "Accept: application/json" -H >> "Content-type: application/json" -X POST -d '{"message": {"foo":"bar >> value", "key":"HELLO"}}' https://something-doamin.rhcloud.com/rest/sender >> >> >> -Matthias >> >> >> >> >>> >>> >>> Miguel >>> >>> >>> >>> On Wed, Feb 19, 2014 at 1:34 PM, Matthias Wessendorf wrote: >>> >>>> Awesome, >>>> >>>> we are interested in hearing your feedback. >>>> >>>> Good luck w/ the development process! >>>> >>>> -Matthias >>>> >>>> >>>> On Wed, Feb 19, 2014 at 2:29 PM, Miguel Lemos wrote: >>>> >>>>> Thanks. Of course I'll give you my feedback ;-) >>>>> >>>>> I've some questions about the service as a whole, but I'll make some >>>>> more testing and then I'll let you know. >>>>> >>>>> Thank you very much again for your attention. >>>>> >>>>> All the best, >>>>> >>>>> Miguel >>>>> >>>>> >>>>> On Wed, Feb 19, 2014 at 1:25 PM, Matthias Wessendorf < >>>>> matzew at apache.org> wrote: >>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Wed, Feb 19, 2014 at 2:18 PM, Miguel Lemos wrote: >>>>>> >>>>>>> Hi Matthias, >>>>>>> >>>>>>> One of the biggest reasons I'm testing this solutions is because iOS! >>>>>>> >>>>>>> Once we already developed a full native Android push (considering >>>>>>> geofencing) notification service. The issue is to port our solution to iOS >>>>>>> (not only the notifications, but everything). That's why I'm personally >>>>>>> testing Cordova on Android and already partially on IOS. So far so good.. >>>>>>> >>>>>> >>>>>> Sounds very interesting. If you are interested, let us know how it >>>>>> goes. >>>>>> >>>>>> >>>>>>> >>>>>>> I'm starting with Android because it's easier to me. But next week I >>>>>>> want to test your solution with iOS. Why? Is there any problem? >>>>>>> >>>>>> >>>>>> No problem there at all :-) I was just curious if you target Android >>>>>> first/only. >>>>>> >>>>>> Greetings, >>>>>> Matthias >>>>>> >>>>>> >>>>>>> >>>>>>> Thanks >>>>>>> >>>>>>> Miguel >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Wed, Feb 19, 2014 at 1:04 PM, Matthias Wessendorf < >>>>>>> matzew at apache.org> wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Feb 19, 2014 at 1:20 PM, Miguel Lemos >>>>>>> > wrote: >>>>>>>> >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> I tested and now it works, thanks. >>>>>>>>> >>>>>>>> >>>>>>>> glad it all worked out >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> When I tried for the first time, I tried with the function >>>>>>>>> global, reflecting the Github example. But as it didn't work (because of >>>>>>>>> the "damn" URL issue...) I tried several things, one of them being put the >>>>>>>>> alert function inside the deviceready event. Of course, when I solved the >>>>>>>>> URL thing I never more remembered to put it outside again... >>>>>>>>> >>>>>>>> >>>>>>>> Things like that might happen. >>>>>>>> >>>>>>>> Regarding the URL, we will try to update the OpenShift blog post. >>>>>>>> >>>>>>>> I just checkout project documentation, and it looks like they are >>>>>>>> already 'right'. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Wondering: Are you building Cordova clients for Android only, or do >>>>>>>> you plan to use the iOS platform as well ? >>>>>>>> >>>>>>>> Greetings, >>>>>>>> Matthias >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> 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 >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140219/4d7db25f/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: shot.png Type: image/png Size: 232862 bytes Desc: not available Url : http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140219/4d7db25f/attachment-0001.png From matzew at apache.org Wed Feb 19 16:20:29 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 19 Feb 2014 22:20:29 +0100 Subject: [aerogear-dev] Issues with Aerogear on Cordova In-Reply-To: References: Message-ID: Nice! Glad you are all set! -Matthias On Wed, Feb 19, 2014 at 4:38 PM, Miguel Lemos wrote: > A small souvenir ;-) > > Thanks again > > > > > On Wed, Feb 19, 2014 at 3:20 PM, Miguel Lemos wrote: > >> Hi Matthias, >> >> Maybe I didn't make myself clear, but your answer was clear enough to >> respond to my post :-) >> >> Thanks again. >> >> Carry on! >> >> M >> >> >> >> On Wed, Feb 19, 2014 at 3:05 PM, Matthias Wessendorf wrote: >> >>> >>> >>> >>> On Wed, Feb 19, 2014 at 3:43 PM, Miguel Lemos wrote: >>> >>>> Dear Matthias, >>>> >>>> According to the information posted in the url below, I can send (and >>>> read) several parameters / keys in the scope of the notification service >>>> (as it should be...): >>>> >>>> http://aerogear.org/docs/specs/aerogear-push-messages/ >>>> >>>> According to the values on it, the receiver should have the capacity to >>>> decide what to do next. >>>> >>>> First, and the easiest thing: don't show the "Alert" text, but any >>>> other part of content received and / or change "Alert" to another >>>> language, for instance. >>>> >>> >>> Not sure I follow. >>> >>> The 'alert' is a keyword on iOS, which our server (and our Cordova Libs) >>> do recognize. What do you want to change there ? >>> For the completion of our spec, we are showing all of the keywords, that >>> are supported. >>> >>> >>> >>>> >>>> Second, if I create (for instance) a lat, lon and rad parameters, I can >>>> decide if I show the notification immediately, or only when the user >>>> reaches a matchable location, within a given radius. >>>> This is just an example of the freedom that must be available to decide >>>> what to do according to a given parameter that the software on the client's >>>> side can interpret. The message itself may not be the most important part >>>> of the whole thing... >>>> >>> >>> If you don't want or need that alert, simply leave it our of the >>> payload. It's just part of the demo/docs as that is quite handy to get >>> going. >>> >>> >>>> >>>> So, the question is: how can I read those parameters / keys before >>>> deciding to do with the notification? Through a "regular" object keys >>>> iterator? Thank you very much again. If there's some place in the >>>> documentation where I can understand that, please let me know. >>>> >>> >>> yes, like here (using alert just as an example): >>> >>> >>> function onNotification(e) { >>> alert(e.payload.foo); >>> alert(e.payload.key); >>> } >>> >>> And the curl for that would be something _like_ this: >>> curl -3 -u "ID:secrect" -v -H "Accept: application/json" -H >>> "Content-type: application/json" -X POST -d '{"message": {"foo":"bar >>> value", "key":"HELLO"}}' >>> https://something-doamin.rhcloud.com/rest/sender >>> >>> >>> -Matthias >>> >>> >>> >>> >>>> >>>> >>>> Miguel >>>> >>>> >>>> >>>> On Wed, Feb 19, 2014 at 1:34 PM, Matthias Wessendorf >>> > wrote: >>>> >>>>> Awesome, >>>>> >>>>> we are interested in hearing your feedback. >>>>> >>>>> Good luck w/ the development process! >>>>> >>>>> -Matthias >>>>> >>>>> >>>>> On Wed, Feb 19, 2014 at 2:29 PM, Miguel Lemos wrote: >>>>> >>>>>> Thanks. Of course I'll give you my feedback ;-) >>>>>> >>>>>> I've some questions about the service as a whole, but I'll make some >>>>>> more testing and then I'll let you know. >>>>>> >>>>>> Thank you very much again for your attention. >>>>>> >>>>>> All the best, >>>>>> >>>>>> Miguel >>>>>> >>>>>> >>>>>> On Wed, Feb 19, 2014 at 1:25 PM, Matthias Wessendorf < >>>>>> matzew at apache.org> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Wed, Feb 19, 2014 at 2:18 PM, Miguel Lemos wrote: >>>>>>> >>>>>>>> Hi Matthias, >>>>>>>> >>>>>>>> One of the biggest reasons I'm testing this solutions is because >>>>>>>> iOS! >>>>>>>> >>>>>>>> Once we already developed a full native Android push (considering >>>>>>>> geofencing) notification service. The issue is to port our solution to iOS >>>>>>>> (not only the notifications, but everything). That's why I'm personally >>>>>>>> testing Cordova on Android and already partially on IOS. So far so good.. >>>>>>>> >>>>>>> >>>>>>> Sounds very interesting. If you are interested, let us know how it >>>>>>> goes. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> I'm starting with Android because it's easier to me. But next week >>>>>>>> I want to test your solution with iOS. Why? Is there any problem? >>>>>>>> >>>>>>> >>>>>>> No problem there at all :-) I was just curious if you target Android >>>>>>> first/only. >>>>>>> >>>>>>> Greetings, >>>>>>> Matthias >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Thanks >>>>>>>> >>>>>>>> Miguel >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Feb 19, 2014 at 1:04 PM, Matthias Wessendorf < >>>>>>>> matzew at apache.org> wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, Feb 19, 2014 at 1:20 PM, Miguel Lemos < >>>>>>>>> miguel21op at gmail.com> wrote: >>>>>>>>> >>>>>>>>>> Hi all, >>>>>>>>>> >>>>>>>>>> I tested and now it works, thanks. >>>>>>>>>> >>>>>>>>> >>>>>>>>> glad it all worked out >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> When I tried for the first time, I tried with the function >>>>>>>>>> global, reflecting the Github example. But as it didn't work (because of >>>>>>>>>> the "damn" URL issue...) I tried several things, one of them being put the >>>>>>>>>> alert function inside the deviceready event. Of course, when I solved the >>>>>>>>>> URL thing I never more remembered to put it outside again... >>>>>>>>>> >>>>>>>>> >>>>>>>>> Things like that might happen. >>>>>>>>> >>>>>>>>> Regarding the URL, we will try to update the OpenShift blog post. >>>>>>>>> >>>>>>>>> I just checkout project documentation, and it looks like they are >>>>>>>>> already 'right'. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Wondering: Are you building Cordova clients for Android only, or >>>>>>>>> do you plan to use the iOS platform as well ? >>>>>>>>> >>>>>>>>> Greetings, >>>>>>>>> Matthias >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> 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 >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>> >>> _______________________________________________ >>> 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/20140219/6119895a/attachment.html From miguel21op at gmail.com Thu Feb 20 03:43:05 2014 From: miguel21op at gmail.com (Miiguel Lemos) Date: Thu, 20 Feb 2014 08:43:05 +0000 Subject: [aerogear-dev] Issues with Aerogear on Cordova In-Reply-To: References: Message-ID: Not all, but a couple of steps on the right direction, I hope ;-) Enviado do meu iPad No dia 19/02/2014, ?s 21:20, Matthias Wessendorf escreveu: > Nice! > > Glad you are all set! > > -Matthias > > >> On Wed, Feb 19, 2014 at 4:38 PM, Miguel Lemos wrote: >> A small souvenir ;-) >> >> Thanks again >> >> >> >> >>> On Wed, Feb 19, 2014 at 3:20 PM, Miguel Lemos wrote: >>> Hi Matthias, >>> >>> Maybe I didn't make myself clear, but your answer was clear enough to respond to my post :-) >>> >>> Thanks again. >>> >>> Carry on! >>> >>> M >>> >>> >>> >>>> On Wed, Feb 19, 2014 at 3:05 PM, Matthias Wessendorf wrote: >>>> >>>> >>>> >>>>> On Wed, Feb 19, 2014 at 3:43 PM, Miguel Lemos wrote: >>>>> Dear Matthias, >>>>> >>>>> According to the information posted in the url below, I can send (and read) several parameters / keys in the scope of the notification service (as it should be...): >>>>> >>>>> http://aerogear.org/docs/specs/aerogear-push-messages/ >>>>> >>>>> According to the values on it, the receiver should have the capacity to decide what to do next. >>>>> >>>>> First, and the easiest thing: don't show the "Alert" text, but any other part of content received and / or change "Alert" to another language, for instance. >>>> >>>> Not sure I follow. >>>> >>>> The 'alert' is a keyword on iOS, which our server (and our Cordova Libs) do recognize. What do you want to change there ? >>>> For the completion of our spec, we are showing all of the keywords, that are supported. >>>> >>>> >>>>> >>>>> Second, if I create (for instance) a lat, lon and rad parameters, I can decide if I show the notification immediately, or only when the user reaches a matchable location, within a given radius. >>>>> This is just an example of the freedom that must be available to decide what to do according to a given parameter that the software on the client's side can interpret. The message itself may not be the most important part of the whole thing... >>>> >>>> If you don't want or need that alert, simply leave it our of the payload. It's just part of the demo/docs as that is quite handy to get going. >>>> >>>>> >>>>> So, the question is: how can I read those parameters / keys before deciding to do with the notification? Through a "regular" object keys iterator? Thank you very much again. If there's some place in the documentation where I can understand that, please let me know. >>>> >>>> yes, like here (using alert just as an example): >>>> >>>> >>>> function onNotification(e) { >>>> alert(e.payload.foo); >>>> alert(e.payload.key); >>>> } >>>> >>>> And the curl for that would be something _like_ this: >>>> curl -3 -u "ID:secrect" -v -H "Accept: application/json" -H "Content-type: application/json" -X POST -d '{"message": {"foo":"bar value", "key":"HELLO"}}' https://something-doamin.rhcloud.com/rest/sender >>>> >>>> >>>> -Matthias >>>> >>>> >>>> >>>>> >>>>> >>>>> Miguel >>>>> >>>>> >>>>> >>>>>> On Wed, Feb 19, 2014 at 1:34 PM, Matthias Wessendorf wrote: >>>>>> Awesome, >>>>>> >>>>>> we are interested in hearing your feedback. >>>>>> >>>>>> Good luck w/ the development process! >>>>>> >>>>>> -Matthias >>>>>> >>>>>> >>>>>>> On Wed, Feb 19, 2014 at 2:29 PM, Miguel Lemos wrote: >>>>>>> Thanks. Of course I'll give you my feedback ;-) >>>>>>> >>>>>>> I've some questions about the service as a whole, but I'll make some more testing and then I'll let you know. >>>>>>> >>>>>>> Thank you very much again for your attention. >>>>>>> >>>>>>> All the best, >>>>>>> >>>>>>> Miguel >>>>>>> >>>>>>> >>>>>>>> On Wed, Feb 19, 2014 at 1:25 PM, Matthias Wessendorf wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> On Wed, Feb 19, 2014 at 2:18 PM, Miguel Lemos wrote: >>>>>>>>> Hi Matthias, >>>>>>>>> >>>>>>>>> One of the biggest reasons I'm testing this solutions is because iOS! >>>>>>>>> >>>>>>>>> Once we already developed a full native Android push (considering geofencing) notification service. The issue is to port our solution to iOS (not only the notifications, but everything). That's why I'm personally testing Cordova on Android and already partially on IOS. So far so good.. >>>>>>>> >>>>>>>> Sounds very interesting. If you are interested, let us know how it goes. >>>>>>>> >>>>>>>>> >>>>>>>>> I'm starting with Android because it's easier to me. But next week I want to test your solution with iOS. Why? Is there any problem? >>>>>>>> >>>>>>>> No problem there at all :-) I was just curious if you target Android first/only. >>>>>>>> >>>>>>>> Greetings, >>>>>>>> Matthias >>>>>>>> >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> >>>>>>>>> Miguel >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> On Wed, Feb 19, 2014 at 1:04 PM, Matthias Wessendorf wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> On Wed, Feb 19, 2014 at 1:20 PM, Miguel Lemos wrote: >>>>>>>>>>> Hi all, >>>>>>>>>>> >>>>>>>>>>> I tested and now it works, thanks. >>>>>>>>>> >>>>>>>>>> glad it all worked out >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> When I tried for the first time, I tried with the function global, reflecting the Github example. But as it didn't work (because of the "damn" URL issue...) I tried several things, one of them being put the alert function inside the deviceready event. Of course, when I solved the URL thing I never more remembered to put it outside again... >>>>>>>>>> >>>>>>>>>> Things like that might happen. >>>>>>>>>> >>>>>>>>>> Regarding the URL, we will try to update the OpenShift blog post. >>>>>>>>>> >>>>>>>>>> I just checkout project documentation, and it looks like they are already 'right'. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Wondering: Are you building Cordova clients for Android only, or do you plan to use the iOS platform as well ? >>>>>>>>>> >>>>>>>>>> Greetings, >>>>>>>>>> Matthias >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> 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 >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>> >>>> _______________________________________________ >>>> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140220/7659e769/attachment-0001.html From scm.blanc at gmail.com Thu Feb 20 03:48:36 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Thu, 20 Feb 2014 09:48:36 +0100 Subject: [aerogear-dev] Issues with Aerogear on Cordova In-Reply-To: References: Message-ID: This is really cool Miguel ! Don't hesitate to ask us other questions and also , like you did with your screenshot, give us feedback ! Thanks again for your interest in the project. Sebi On Thu, Feb 20, 2014 at 9:43 AM, Miiguel Lemos wrote: > Not all, but a couple of steps on the right direction, I hope ;-) > > Enviado do meu iPad > > No dia 19/02/2014, ?s 21:20, Matthias Wessendorf > escreveu: > > Nice! > > Glad you are all set! > > -Matthias > > > On Wed, Feb 19, 2014 at 4:38 PM, Miguel Lemos wrote: > >> A small souvenir ;-) >> >> Thanks again >> >> >> >> >> On Wed, Feb 19, 2014 at 3:20 PM, Miguel Lemos wrote: >> >>> Hi Matthias, >>> >>> Maybe I didn't make myself clear, but your answer was clear enough to >>> respond to my post :-) >>> >>> Thanks again. >>> >>> Carry on! >>> >>> M >>> >>> >>> >>> On Wed, Feb 19, 2014 at 3:05 PM, Matthias Wessendorf wrote: >>> >>>> >>>> >>>> >>>> On Wed, Feb 19, 2014 at 3:43 PM, Miguel Lemos wrote: >>>> >>>>> Dear Matthias, >>>>> >>>>> According to the information posted in the url below, I can send (and >>>>> read) several parameters / keys in the scope of the notification service >>>>> (as it should be...): >>>>> >>>>> http://aerogear.org/docs/specs/aerogear-push-messages/ >>>>> >>>>> According to the values on it, the receiver should have the capacity >>>>> to decide what to do next. >>>>> >>>>> First, and the easiest thing: don't show the "Alert" text, but any >>>>> other part of content received and / or change "Alert" to another >>>>> language, for instance. >>>>> >>>> >>>> Not sure I follow. >>>> >>>> The 'alert' is a keyword on iOS, which our server (and our Cordova >>>> Libs) do recognize. What do you want to change there ? >>>> For the completion of our spec, we are showing all of the keywords, >>>> that are supported. >>>> >>>> >>>> >>>>> >>>>> Second, if I create (for instance) a lat, lon and rad parameters, I >>>>> can decide if I show the notification immediately, or only when the user >>>>> reaches a matchable location, within a given radius. >>>>> This is just an example of the freedom that must be available to >>>>> decide what to do according to a given parameter that the software on the >>>>> client's side can interpret. The message itself may not be the most >>>>> important part of the whole thing... >>>>> >>>> >>>> If you don't want or need that alert, simply leave it our of the >>>> payload. It's just part of the demo/docs as that is quite handy to get >>>> going. >>>> >>>> >>>>> >>>>> So, the question is: how can I read those parameters / keys before >>>>> deciding to do with the notification? Through a "regular" object keys >>>>> iterator? Thank you very much again. If there's some place in the >>>>> documentation where I can understand that, please let me know. >>>>> >>>> >>>> yes, like here (using alert just as an example): >>>> >>>> >>>> function onNotification(e) { >>>> alert(e.payload.foo); >>>> alert(e.payload.key); >>>> } >>>> >>>> And the curl for that would be something _like_ this: >>>> curl -3 -u "ID:secrect" -v -H "Accept: application/json" -H >>>> "Content-type: application/json" -X POST -d '{"message": {"foo":"bar >>>> value", "key":"HELLO"}}' >>>> https://something-doamin.rhcloud.com/rest/sender >>>> >>>> >>>> -Matthias >>>> >>>> >>>> >>>> >>>>> >>>>> >>>>> Miguel >>>>> >>>>> >>>>> >>>>> On Wed, Feb 19, 2014 at 1:34 PM, Matthias Wessendorf < >>>>> matzew at apache.org> wrote: >>>>> >>>>>> Awesome, >>>>>> >>>>>> we are interested in hearing your feedback. >>>>>> >>>>>> Good luck w/ the development process! >>>>>> >>>>>> -Matthias >>>>>> >>>>>> >>>>>> On Wed, Feb 19, 2014 at 2:29 PM, Miguel Lemos wrote: >>>>>> >>>>>>> Thanks. Of course I'll give you my feedback ;-) >>>>>>> >>>>>>> I've some questions about the service as a whole, but I'll make some >>>>>>> more testing and then I'll let you know. >>>>>>> >>>>>>> Thank you very much again for your attention. >>>>>>> >>>>>>> All the best, >>>>>>> >>>>>>> Miguel >>>>>>> >>>>>>> >>>>>>> On Wed, Feb 19, 2014 at 1:25 PM, Matthias Wessendorf < >>>>>>> matzew at apache.org> wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Feb 19, 2014 at 2:18 PM, Miguel Lemos >>>>>>> > wrote: >>>>>>>> >>>>>>>>> Hi Matthias, >>>>>>>>> >>>>>>>>> One of the biggest reasons I'm testing this solutions is because >>>>>>>>> iOS! >>>>>>>>> >>>>>>>>> Once we already developed a full native Android push (considering >>>>>>>>> geofencing) notification service. The issue is to port our solution to iOS >>>>>>>>> (not only the notifications, but everything). That's why I'm personally >>>>>>>>> testing Cordova on Android and already partially on IOS. So far so good.. >>>>>>>>> >>>>>>>> >>>>>>>> Sounds very interesting. If you are interested, let us know how it >>>>>>>> goes. >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> I'm starting with Android because it's easier to me. But next week >>>>>>>>> I want to test your solution with iOS. Why? Is there any problem? >>>>>>>>> >>>>>>>> >>>>>>>> No problem there at all :-) I was just curious if you target >>>>>>>> Android first/only. >>>>>>>> >>>>>>>> Greetings, >>>>>>>> Matthias >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> >>>>>>>>> Miguel >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, Feb 19, 2014 at 1:04 PM, Matthias Wessendorf < >>>>>>>>> matzew at apache.org> wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Wed, Feb 19, 2014 at 1:20 PM, Miguel Lemos < >>>>>>>>>> miguel21op at gmail.com> wrote: >>>>>>>>>> >>>>>>>>>>> Hi all, >>>>>>>>>>> >>>>>>>>>>> I tested and now it works, thanks. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> glad it all worked out >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> When I tried for the first time, I tried with the function >>>>>>>>>>> global, reflecting the Github example. But as it didn't work (because of >>>>>>>>>>> the "damn" URL issue...) I tried several things, one of them being put the >>>>>>>>>>> alert function inside the deviceready event. Of course, when I solved the >>>>>>>>>>> URL thing I never more remembered to put it outside again... >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Things like that might happen. >>>>>>>>>> >>>>>>>>>> Regarding the URL, we will try to update the OpenShift blog post. >>>>>>>>>> >>>>>>>>>> I just checkout project documentation, and it looks like they are >>>>>>>>>> already 'right'. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Wondering: Are you building Cordova clients for Android only, or >>>>>>>>>> do you plan to use the iOS platform as well ? >>>>>>>>>> >>>>>>>>>> Greetings, >>>>>>>>>> Matthias >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> 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 >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>> >>>> _______________________________________________ >>>> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140220/5775f560/attachment-0001.html From matzew at apache.org Thu Feb 20 04:44:45 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 20 Feb 2014 10:44:45 +0100 Subject: [aerogear-dev] Google summer of code In-Reply-To: References: Message-ID: hello there, I added another idea: https://gist.github.com/matzew/bb9e3a0da6aca939b523#support-new-push-networks-on-the-unifiedpush-server On Mon, Feb 17, 2014 at 7:13 PM, Bruno Oliveira wrote: > The first idea is great but the scope might require full time commitment. > I would vote on #2 depending on which kind of application do you have in > mind. > > -- > abstractj > > On February 17, 2014 at 1:51:46 PM, Matthias Wessendorf (matzew at apache.org) > wrote: > > > > Hi, > > > > wondering about GSoC for 2014. Do we want to be part of it? Reviewing > > the > > GSoC-2014 list from JBoss, I see a few left-overs from last year > > are in > > here: > > > > https://community.jboss.org/wiki/GSOC14Ideas > > > > * Implement a Mobile Document Collaboration App > > * Demo: Implementing native features in mobile applications > > > > I am not sure if folks are still interested in these ? > > > > Aside for these 'older' items, there are some ideas (mostly around > > push) I > > put together in a gist: > > https://gist.github.com/matzew/bb9e3a0da6aca939b523 > > > > Especially #1 on that list is a huge interest of mine. > > > > > > Any thought ? > > -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 > > -- 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/20140220/0e70723d/attachment.html From cvasilak at gmail.com Thu Feb 20 04:58:51 2014 From: cvasilak at gmail.com (Christos Vasilakis) Date: Thu, 20 Feb 2014 11:58:51 +0200 Subject: [aerogear-dev] iOS Team Meeting Message-ID: <1911A638-4EBF-4C8C-8E33-1F08D6715BC3@gmail.com> Hi everyone, as the 1.4.0 release settles in, we are already going through our .next items for our next release[1] this week. We will hold our scheduled meeting next week on Thusday 2pm (CET time zone) to discuss more. Feel free to add in our agenda. Thanks, Christos [1] https://issues.jboss.org/issues/?filter=12320835 [2] http://oksoclap.com/p/iOS-meeting-25-02-2014 From corinnekrych at gmail.com Thu Feb 20 05:03:26 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Thu, 20 Feb 2014 11:03:26 +0100 Subject: [aerogear-dev] iOS Team Meeting In-Reply-To: <1911A638-4EBF-4C8C-8E33-1F08D6715BC3@gmail.com> References: <1911A638-4EBF-4C8C-8E33-1F08D6715BC3@gmail.com> Message-ID: Great, I'll go through the JIRAs too and update the agenda. I think you meant Tuesday 25th 2pm (usual time slot for iOS meeting) ++ Corinne On 20 February 2014 10:58, Christos Vasilakis wrote: > Hi everyone, > > as the 1.4.0 release settles in, we are already going through our .next > items for our next release[1] this week. We will hold our scheduled meeting > next week on Thusday 2pm (CET time zone) to discuss more. Feel free to add > in our agenda. > > Thanks, > Christos > > [1] https://issues.jboss.org/issues/?filter=12320835 > [2] http://oksoclap.com/p/iOS-meeting-25-02-2014 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140220/67d2a2b1/attachment.html From edewit at redhat.com Thu Feb 20 05:07:08 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Thu, 20 Feb 2014 11:07:08 +0100 Subject: [aerogear-dev] iOS Scaffolding In-Reply-To: References: <96636ABC-EE3E-461D-A5F0-0BFBB4B79694@gmail.com> Message-ID: <349C158E-D1DE-4C35-BC31-1CEAF4395491@redhat.com> Just wondering how would this work with the xib files? From scm.blanc at gmail.com Thu Feb 20 05:13:01 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Thu, 20 Feb 2014 11:13:01 +0100 Subject: [aerogear-dev] iOS Scaffolding In-Reply-To: <349C158E-D1DE-4C35-BC31-1CEAF4395491@redhat.com> References: <96636ABC-EE3E-461D-A5F0-0BFBB4B79694@gmail.com> <349C158E-D1DE-4C35-BC31-1CEAF4395491@redhat.com> Message-ID: Well if we decide to go for storyboards (which are XML based thus we can template them) , xib files won't be needed anymore but maybe I'm wrong. On Thu, Feb 20, 2014 at 11:07 AM, Erik Jan de Wit wrote: > Just wondering how would this work with the xib files? > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140220/97e241dc/attachment.html From cvasilak at gmail.com Thu Feb 20 05:12:55 2014 From: cvasilak at gmail.com (Christos Vasilakis) Date: Thu, 20 Feb 2014 12:12:55 +0200 Subject: [aerogear-dev] iOS Team Meeting In-Reply-To: References: <1911A638-4EBF-4C8C-8E33-1F08D6715BC3@gmail.com> Message-ID: <1B84AA5E-DAA5-4300-AE54-4FF5B8A17204@gmail.com> On Feb 20, 2014, at 12:03 PM, Corinne Krych wrote: > Great, I'll go through the JIRAs too and update the agenda. > I think you meant Tuesday 25th 2pm (usual time slot for iOS meeting) exactly sorry missed the letter there :( > > ++ > Corinne > > > On 20 February 2014 10:58, Christos Vasilakis wrote: > Hi everyone, > > as the 1.4.0 release settles in, we are already going through our .next items for our next release[1] this week. We will hold our scheduled meeting next week on Thusday 2pm (CET time zone) to discuss more. Feel free to add in our agenda. > > Thanks, > Christos > > [1] https://issues.jboss.org/issues/?filter=12320835 > [2] http://oksoclap.com/p/iOS-meeting-25-02-2014 > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140220/1ef02fd4/attachment.html From corinnekrych at gmail.com Thu Feb 20 05:13:04 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Thu, 20 Feb 2014 11:13:04 +0100 Subject: [aerogear-dev] iOS Scaffolding In-Reply-To: <349C158E-D1DE-4C35-BC31-1CEAF4395491@redhat.com> References: <96636ABC-EE3E-461D-A5F0-0BFBB4B79694@gmail.com> <349C158E-D1DE-4C35-BC31-1CEAF4395491@redhat.com> Message-ID: Storyboard being broadly used (in iOS7), I'd like to start with storyboard file. Storyboard and Xib file are xml files. ++ Corinne On 20 February 2014 11:07, Erik Jan de Wit wrote: > Just wondering how would this work with the xib files? > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140220/55ff6cf5/attachment.html From miguel21op at gmail.com Thu Feb 20 06:55:53 2014 From: miguel21op at gmail.com (Miguel Lemos) Date: Thu, 20 Feb 2014 11:55:53 +0000 Subject: [aerogear-dev] Issues with Aerogear on Cordova In-Reply-To: References: Message-ID: I'll be back ;-) Em 20/02/2014 08:48, "Sebastien Blanc" escreveu: > This is really cool Miguel ! > Don't hesitate to ask us other questions and also , like you did with your > screenshot, give us feedback ! > Thanks again for your interest in the project. > Sebi > > > > On Thu, Feb 20, 2014 at 9:43 AM, Miiguel Lemos wrote: > >> Not all, but a couple of steps on the right direction, I hope ;-) >> >> Enviado do meu iPad >> >> No dia 19/02/2014, ?s 21:20, Matthias Wessendorf >> escreveu: >> >> Nice! >> >> Glad you are all set! >> >> -Matthias >> >> >> On Wed, Feb 19, 2014 at 4:38 PM, Miguel Lemos wrote: >> >>> A small souvenir ;-) >>> >>> Thanks again >>> >>> >>> >>> >>> On Wed, Feb 19, 2014 at 3:20 PM, Miguel Lemos wrote: >>> >>>> Hi Matthias, >>>> >>>> Maybe I didn't make myself clear, but your answer was clear enough to >>>> respond to my post :-) >>>> >>>> Thanks again. >>>> >>>> Carry on! >>>> >>>> M >>>> >>>> >>>> >>>> On Wed, Feb 19, 2014 at 3:05 PM, Matthias Wessendorf >>> > wrote: >>>> >>>>> >>>>> >>>>> >>>>> On Wed, Feb 19, 2014 at 3:43 PM, Miguel Lemos wrote: >>>>> >>>>>> Dear Matthias, >>>>>> >>>>>> According to the information posted in the url below, I can send (and >>>>>> read) several parameters / keys in the scope of the notification service >>>>>> (as it should be...): >>>>>> >>>>>> http://aerogear.org/docs/specs/aerogear-push-messages/ >>>>>> >>>>>> According to the values on it, the receiver should have the capacity >>>>>> to decide what to do next. >>>>>> >>>>>> First, and the easiest thing: don't show the "Alert" text, but any >>>>>> other part of content received and / or change "Alert" to another >>>>>> language, for instance. >>>>>> >>>>> >>>>> Not sure I follow. >>>>> >>>>> The 'alert' is a keyword on iOS, which our server (and our Cordova >>>>> Libs) do recognize. What do you want to change there ? >>>>> For the completion of our spec, we are showing all of the keywords, >>>>> that are supported. >>>>> >>>>> >>>>> >>>>>> >>>>>> Second, if I create (for instance) a lat, lon and rad parameters, I >>>>>> can decide if I show the notification immediately, or only when the user >>>>>> reaches a matchable location, within a given radius. >>>>>> This is just an example of the freedom that must be available to >>>>>> decide what to do according to a given parameter that the software on the >>>>>> client's side can interpret. The message itself may not be the most >>>>>> important part of the whole thing... >>>>>> >>>>> >>>>> If you don't want or need that alert, simply leave it our of the >>>>> payload. It's just part of the demo/docs as that is quite handy to get >>>>> going. >>>>> >>>>> >>>>>> >>>>>> So, the question is: how can I read those parameters / keys before >>>>>> deciding to do with the notification? Through a "regular" object keys >>>>>> iterator? Thank you very much again. If there's some place in the >>>>>> documentation where I can understand that, please let me know. >>>>>> >>>>> >>>>> yes, like here (using alert just as an example): >>>>> >>>>> >>>>> function onNotification(e) { >>>>> alert(e.payload.foo); >>>>> alert(e.payload.key); >>>>> } >>>>> >>>>> And the curl for that would be something _like_ this: >>>>> curl -3 -u "ID:secrect" -v -H "Accept: application/json" -H >>>>> "Content-type: application/json" -X POST -d '{"message": {"foo":"bar >>>>> value", "key":"HELLO"}}' >>>>> https://something-doamin.rhcloud.com/rest/sender >>>>> >>>>> >>>>> -Matthias >>>>> >>>>> >>>>> >>>>> >>>>>> >>>>>> >>>>>> Miguel >>>>>> >>>>>> >>>>>> >>>>>> On Wed, Feb 19, 2014 at 1:34 PM, Matthias Wessendorf < >>>>>> matzew at apache.org> wrote: >>>>>> >>>>>>> Awesome, >>>>>>> >>>>>>> we are interested in hearing your feedback. >>>>>>> >>>>>>> Good luck w/ the development process! >>>>>>> >>>>>>> -Matthias >>>>>>> >>>>>>> >>>>>>> On Wed, Feb 19, 2014 at 2:29 PM, Miguel Lemos wrote: >>>>>>> >>>>>>>> Thanks. Of course I'll give you my feedback ;-) >>>>>>>> >>>>>>>> I've some questions about the service as a whole, but I'll make >>>>>>>> some more testing and then I'll let you know. >>>>>>>> >>>>>>>> Thank you very much again for your attention. >>>>>>>> >>>>>>>> All the best, >>>>>>>> >>>>>>>> Miguel >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Feb 19, 2014 at 1:25 PM, Matthias Wessendorf < >>>>>>>> matzew at apache.org> wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, Feb 19, 2014 at 2:18 PM, Miguel Lemos < >>>>>>>>> miguel21op at gmail.com> wrote: >>>>>>>>> >>>>>>>>>> Hi Matthias, >>>>>>>>>> >>>>>>>>>> One of the biggest reasons I'm testing this solutions is because >>>>>>>>>> iOS! >>>>>>>>>> >>>>>>>>>> Once we already developed a full native Android push (considering >>>>>>>>>> geofencing) notification service. The issue is to port our solution to iOS >>>>>>>>>> (not only the notifications, but everything). That's why I'm personally >>>>>>>>>> testing Cordova on Android and already partially on IOS. So far so good.. >>>>>>>>>> >>>>>>>>> >>>>>>>>> Sounds very interesting. If you are interested, let us know how it >>>>>>>>> goes. >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> I'm starting with Android because it's easier to me. But next >>>>>>>>>> week I want to test your solution with iOS. Why? Is there any problem? >>>>>>>>>> >>>>>>>>> >>>>>>>>> No problem there at all :-) I was just curious if you target >>>>>>>>> Android first/only. >>>>>>>>> >>>>>>>>> Greetings, >>>>>>>>> Matthias >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> >>>>>>>>>> Miguel >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Wed, Feb 19, 2014 at 1:04 PM, Matthias Wessendorf < >>>>>>>>>> matzew at apache.org> wrote: >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Wed, Feb 19, 2014 at 1:20 PM, Miguel Lemos < >>>>>>>>>>> miguel21op at gmail.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi all, >>>>>>>>>>>> >>>>>>>>>>>> I tested and now it works, thanks. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> glad it all worked out >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> When I tried for the first time, I tried with the function >>>>>>>>>>>> global, reflecting the Github example. But as it didn't work (because of >>>>>>>>>>>> the "damn" URL issue...) I tried several things, one of them being put the >>>>>>>>>>>> alert function inside the deviceready event. Of course, when I solved the >>>>>>>>>>>> URL thing I never more remembered to put it outside again... >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Things like that might happen. >>>>>>>>>>> >>>>>>>>>>> Regarding the URL, we will try to update the OpenShift blog post. >>>>>>>>>>> >>>>>>>>>>> I just checkout project documentation, and it looks like they >>>>>>>>>>> are already 'right'. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Wondering: Are you building Cordova clients for Android only, or >>>>>>>>>>> do you plan to use the iOS platform as well ? >>>>>>>>>>> >>>>>>>>>>> Greetings, >>>>>>>>>>> Matthias >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> 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 >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> 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 >>>>> >>>>> _______________________________________________ >>>>> 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 >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140220/36ce1ec8/attachment-0001.html From hbons at redhat.com Thu Feb 20 09:06:26 2014 From: hbons at redhat.com (Hylke Bons) Date: Thu, 20 Feb 2014 14:06:26 +0000 Subject: [aerogear-dev] AeroGear project structure and the website Message-ID: <53060BE2.6030803@redhat.com> Hey everyone, So we've been doing continuous improvements to the website. Corinne and Erik have been making some awesome progress shaping up the new documentation section (roadmap here: http://aerogear.org/docs/planning/roadmaps/AeroGearWebSite/) according to the mockups (https://raw2.github.com/hbons/aerogear-design/master/website-restructure/aerogear-project.png). We've split stuff up into "Setup Howtos", "Examples", "API Documentation" and "Guides". I don't think there was much controversy here and there's been made some headway already in unifying some of the documentation. The most important change in the website mockups was that instead of focusing on platform branding, the focus is on solving use cases that "we happen to support on these platforms". So Core/Push/Security are the main players over iOS/Android/JS, although these are still referenced everywhere and presented in a graphic on top of the home page. Before we can work on the project homepage sections and download areas of the website we should have a discussion about how the AeroGear project itself is structured. The project seems to have grown organically and new modules have been added here and there. There are some of these that make the structure of the project more complicated that it needs to be (in my opinion) to present it in a simple way to developers visiting the website. I've done some research on the project structure and have written down the findings, as well as points where there's room for improvement and possible solutions, here: http://oksoclap.com/p/AeroGearModuleUntangling TL;DR: The most important questions that we need to answer are these: - "If I download a library on one platform, what must I download to use the same features on an other platform?" -"Is this a part I use on the client, or on the server side?" -"What do we mean when talking about different AeroGear subprojects/modules?" One solution might be: https://raw2.github.com/hbons/aerogear-design/master/website-restructure/aerogear-modules.png I've made a lot of assumptions here, and it might not work, but I'd like to hear your thoughts on it. It would clarify a lot if we could harmonise the different downloads across platforms, either by providing single download solutions or splitting everything up and naming all the parts consistently. I'm interested in what the technical issues might be, as I wasn't around when most of these decisions were made, or I simply missed them. Thoughts or other ideas? :) Thanks, Hylke -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140220/1134e25d/attachment.html From bruno at abstractj.org Thu Feb 20 12:06:24 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Thu, 20 Feb 2014 14:06:24 -0300 Subject: [aerogear-dev] AeroGear project structure and the website In-Reply-To: <53060BE2.6030803@redhat.com> References: <53060BE2.6030803@redhat.com> Message-ID: Hylke amazing work, I can?t wait to see it in production. -- abstractj On February 20, 2014 at 11:06:34 AM, Hylke Bons (hbons at redhat.com) wrote: > > TL;DR: The most important questions that we need to answer are > these: > - "If I download a library on one platform, what must I download > to use > the same features on an other platform?" > -"Is this a part I use on the client, or on the server side?? Not sure if I understood your question correctly, but to get the full solution, you need to download both > -"What do we mean when talking about different AeroGear > subprojects/modules?? By subprojects I understand as exactly like you did at?https://raw2.github.com/hbons/aerogear-design/master/website-restructure/aerogear-modules.png. > > One solution might be: > https://raw2.github.com/hbons/aerogear-design/master/website-restructure/aerogear-modules.png > I've made a lot of assumptions here, and it might not work, but > I'd like > to hear your thoughts on it. > > It would clarify a lot if we could harmonise the different downloads > across platforms, either by providing single download solutions > or > splitting everything up and naming all the parts consistently. > I'm > interested in what the technical issues might be, as I wasn't > around > when most of these decisions were made, or I simply missed them. > > Thoughts or other ideas? :) I don?t have any idea, because I liked the way how it was organized. No disagreement here. > > Thanks, > > Hylke > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From hbons at redhat.com Thu Feb 20 12:15:25 2014 From: hbons at redhat.com (Hylke Bons) Date: Thu, 20 Feb 2014 17:15:25 +0000 Subject: [aerogear-dev] AeroGear people page Message-ID: <5306382D.5040306@redhat.com> Hello, I did a rough mockup for a people page like we talked about in the other thread: https://raw2.github.com/hbons/aerogear-design/master/website-restructure/people_page.png Fairly basic for now so that we can get something up fast and improve on it later. Github commits would be nice to have, but I guess we can leave it out for now, as it might be tricky. If everyone involved could fill in this small template we can get this up and running soon: http://oksoclap.com/p/AeroGearPeople Pass the word! :) Cheers, Hylke From lholmqui at redhat.com Thu Feb 20 12:19:27 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Thu, 20 Feb 2014 12:19:27 -0500 Subject: [aerogear-dev] AeroGear people page In-Reply-To: <5306382D.5040306@redhat.com> References: <5306382D.5040306@redhat.com> Message-ID: <421D8587-C2F4-4484-A8A9-F0DB3395031A@redhat.com> On Feb 20, 2014, at 12:15 PM, Hylke Bons wrote: > Hello, > > I did a rough mockup for a people page like we talked about in the other > thread: > https://raw2.github.com/hbons/aerogear-design/master/website-restructure/people_page.png i think we should keep the descriptions you put :) > > Fairly basic for now so that we can get something up fast and improve on > it later. > Github commits would be nice to have, but I guess we can leave it out > for now, as it might be tricky. > > If everyone involved could fill in this small template we can get this > up and running soon: > http://oksoclap.com/p/AeroGearPeople > > Pass the word! :) > > Cheers, > > Hylke > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From bruno at abstractj.org Thu Feb 20 12:34:05 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Thu, 20 Feb 2014 14:34:05 -0300 Subject: [aerogear-dev] AeroGear people page In-Reply-To: <421D8587-C2F4-4484-A8A9-F0DB3395031A@redhat.com> References: <5306382D.5040306@redhat.com> <421D8587-C2F4-4484-A8A9-F0DB3395031A@redhat.com> Message-ID: When you know nothing about me, just include ?This person loves bacon and beer?, that?s enough to describe myself. -- abstractj On February 20, 2014 at 2:19:46 PM, Lucas Holmquist (lholmqui at redhat.com) wrote: > > i think we should keep the descriptions you put :) From viktor.gamov at gmail.com Thu Feb 20 13:04:38 2014 From: viktor.gamov at gmail.com (Viktor Gamov) Date: Thu, 20 Feb 2014 13:04:38 -0500 Subject: [aerogear-dev] Running UPS on Tomcat Message-ID: Hello AeroGear team, Small question. Is there quick (and, maybe, dirty) way to run the unified push server on a simple container like Tomcat? Thanks -- With Best Regards, Vik Gamov -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140220/4fc35796/attachment.html From matzew at apache.org Thu Feb 20 13:29:21 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 20 Feb 2014 19:29:21 +0100 Subject: [aerogear-dev] Running UPS on Tomcat In-Reply-To: References: Message-ID: Hey Viktor! I *think* TomEE works, however you have to change the JPA impl to hibernate/eclipseLink I filed this ticket against one of our dependencies recently: https://issues.jboss.org/browse/PLINK-354 That said, I haven't tested TomEE w/ Hinernate/EclipseLink. Would that be an option for you? Otherwise I could recommend using it on OpenShift. (We have a cartidge there to run the push bits) Greetings, Matthias On Thursday, February 20, 2014, Viktor Gamov > wrote: > Hello AeroGear team, > > Small question. Is there quick (and, maybe, dirty) way to run the unified > push server on a simple container like Tomcat? > > Thanks > > -- > With Best Regards, > Vik Gamov > -- Sent from Gmail Mobile -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140220/47f494b4/attachment.html From lholmqui at redhat.com Thu Feb 20 13:39:55 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Thu, 20 Feb 2014 13:39:55 -0500 Subject: [aerogear-dev] Running UPS on Tomcat In-Reply-To: References: Message-ID: when you said small question, did you mean the text size? :) On Feb 20, 2014, at 1:04 PM, Viktor Gamov wrote: > Hello AeroGear team, > > Small question. Is there quick (and, maybe, dirty) way to run the unified push server on a simple container like Tomcat? > > Thanks > > -- > With Best Regards, > Vik Gamov > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140220/08d89040/attachment-0001.html From jbalunas at redhat.com Thu Feb 20 15:59:19 2014 From: jbalunas at redhat.com (Jay Balunas) Date: Thu, 20 Feb 2014 15:59:19 -0500 Subject: [aerogear-dev] Let's change the AeroGear Twitter account handle In-Reply-To: References: <52EA3687.2050601@redhat.com> <52EA39C6.8020607@redhat.com> <52EF9D46.6000306@redhat.com> <953401D5-1AA2-44BB-8240-859183299450@redhat.com> Message-ID: <79297C6E-D46C-468B-97E3-F3F8C3396F76@redhat.com> On Feb 3, 2014, at 8:56 AM, Matthias Wessendorf wrote: > > > > On Mon, Feb 3, 2014 at 2:52 PM, Lucas Holmquist wrote: > > On Feb 3, 2014, at 8:44 AM, Hylke Bons wrote: > >> I've compiled a list of handles that are less problematic and available. > > Seriously though, is this really problematic? > > Not sure if it is problematic, but since we use @AerogearS, 90% of the folks think that is the actual name of the project :-) I would tend to agree here as well. I've run into this myself with others not sure what the name is. If we went with @AeroGearTeam it is clear what the diffs are and its only 3 characters more. I'd like to close the loop on this discussion one way or another. My vote is that we change the twitter handle to "@AeroGearTeam" with a very close secondary choice of "@AeroGearOrg" > > > >> From short to long: >> >> @_AeroGear_ >> @AeroGearOrg >> @AeroGearTeam >> @AeroGearNews >> @JBossAeroGear >> @AeroGearMobile >> @AeroGearTweets >> >> Hylke >> >> >> >> On 30/01/2014 12:33, Matthias Wessendorf wrote: >>> >>> >>> >>> On Thu, Jan 30, 2014 at 12:38 PM, Hylke Bons wrote: >>> You are right that it may be a bit long for replies. >>> "@AGTeam" or "@AGProject" could work too (if they weren't already taken but something amongst those line :). >>> >>> not sure if AGTeam/Project is really 'cool' >>> >>> >>> Hylke >>> >>> >>> On 30/01/2014 11:29, Matthias Wessendorf wrote: >>>> >>>> >>>> >>>> On Thu, Jan 30, 2014 at 12:24 PM, Hylke Bons wrote: >>>> "@AeroGears" can cause confusion about what the project name really is. >>>> >>>> All the JUGs I presented at, and some conferences call the project already "AeroGears", due to the tiwtter handle :-) >>>> >>>> >>>> Options to fix: >>>> - Ask the owner of @AeroGear if he or she want to give up the handle >>>> >>>> are we also offering 50k ? :) >>>> >>>> - Change the handle to "@AeroGearTeam" or "@AeroGearProject", or >>>> something else >>>> >>>> I think the 'concern' was that the name is too long, but on the other hand, there is some sort of confusion w/ our actual name :-0 >>>> >>>> If I had to pick one out of those that you suggested it would be 'AeroGearTeam', that's exactly just three chars longer than the current :) >>>> >>>> -M >>>> >>>> >>>> >>>> >>>> >>>> Thoughts? >>>> >>>> Hylke >>>> _______________________________________________ >>>> 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 >>> >>> >>> _______________________________________________ >>> 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 > > > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140220/91dc1204/attachment.html From qmx at qmx.me Thu Feb 20 16:07:58 2014 From: qmx at qmx.me (Douglas Campos) Date: Thu, 20 Feb 2014 18:07:58 -0300 Subject: [aerogear-dev] Let's change the AeroGear Twitter account handle In-Reply-To: <79297C6E-D46C-468B-97E3-F3F8C3396F76@redhat.com> References: <52EA3687.2050601@redhat.com> <52EA39C6.8020607@redhat.com> <52EF9D46.6000306@redhat.com> <953401D5-1AA2-44BB-8240-859183299450@redhat.com> <79297C6E-D46C-468B-97E3-F3F8C3396F76@redhat.com> Message-ID: <20140220210758.GW51006@rohan.local> **If** we're really forced to change, I'd go with @aerogear_project -- qmx From matzew at apache.org Thu Feb 20 16:35:29 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 20 Feb 2014 22:35:29 +0100 Subject: [aerogear-dev] Let's change the AeroGear Twitter account handle In-Reply-To: <20140220210758.GW51006@rohan.local> References: <52EA3687.2050601@redhat.com> <52EA39C6.8020607@redhat.com> <52EF9D46.6000306@redhat.com> <953401D5-1AA2-44BB-8240-859183299450@redhat.com> <79297C6E-D46C-468B-97E3-F3F8C3396F76@redhat.com> <20140220210758.GW51006@rohan.local> Message-ID: @__aerogear or @_aerogear ? On Thu, Feb 20, 2014 at 10:07 PM, Douglas Campos wrote: > **If** we're really forced to change, I'd go with @aerogear_project > > -- > qmx > _______________________________________________ > 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/20140220/8a62707c/attachment.html From matzew at apache.org Thu Feb 20 16:54:02 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 20 Feb 2014 22:54:02 +0100 Subject: [aerogear-dev] Let's change the AeroGear Twitter account handle In-Reply-To: References: <52EA3687.2050601@redhat.com> <52EA39C6.8020607@redhat.com> <52EF9D46.6000306@redhat.com> <953401D5-1AA2-44BB-8240-859183299450@redhat.com> <79297C6E-D46C-468B-97E3-F3F8C3396F76@redhat.com> <20140220210758.GW51006@rohan.local> Message-ID: Actually, @aerogear_project makes sense (see @netty_project) On Thu, Feb 20, 2014 at 10:35 PM, Matthias Wessendorf wrote: > @__aerogear or @_aerogear ? > > > > > On Thu, Feb 20, 2014 at 10:07 PM, Douglas Campos wrote: > >> **If** we're really forced to change, I'd go with @aerogear_project >> >> -- >> qmx >> _______________________________________________ >> 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 > -- 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/20140220/a7675211/attachment-0001.html From bruno at abstractj.org Thu Feb 20 17:17:48 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Thu, 20 Feb 2014 19:17:48 -0300 Subject: [aerogear-dev] Let's change the AeroGear Twitter account handle In-Reply-To: References: <52EA3687.2050601@redhat.com> <52EA39C6.8020607@redhat.com> <52EF9D46.6000306@redhat.com> <953401D5-1AA2-44BB-8240-859183299450@redhat.com> <79297C6E-D46C-468B-97E3-F3F8C3396F76@redhat.com> <20140220210758.GW51006@rohan.local> Message-ID: I still can't see what the real value added on it. Everyone knows that there's a team behind it, so I can't see why "_team", also do we plan to create handles for "AeroGearPush", "AeroGearSecurity"...if yes, that makes sense. And "_project", well we know, it's a project, the "s" on @aerogears always gave to me the sense of a bunch of people behind this to make it happen. On Thu, Feb 20, 2014 at 6:54 PM, Matthias Wessendorf wrote: > Actually, @aerogear_project makes sense (see @netty_project) > > > On Thu, Feb 20, 2014 at 10:35 PM, Matthias Wessendorf wrote: > >> @__aerogear or @_aerogear ? >> >> >> >> >> On Thu, Feb 20, 2014 at 10:07 PM, Douglas Campos wrote: >> >>> **If** we're really forced to change, I'd go with @aerogear_project >>> >>> -- >>> qmx >>> _______________________________________________ >>> 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 >> > > > > -- > 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 > -- -- "The measure of a man is what he does with power" - Plato - @abstractj - Volenti Nihil Difficile -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140220/3d0fc177/attachment.html From ted.goddard at icesoft.com Thu Feb 20 19:27:55 2014 From: ted.goddard at icesoft.com (TedGoddard) Date: Thu, 20 Feb 2014 16:27:55 -0800 (PST) Subject: [aerogear-dev] Google summer of code In-Reply-To: References: Message-ID: <1392942475423-6377.post@n5.nabble.com> Matthias Wessendorf wrote > * Demo: Implementing native features in mobile applications One option for native features would be to use BridgeIt: I'll do some additional work on this demo, but in this fork of the aerogear-js-cookbook I've added photo thumbnails: https://github.com/bridgeit/aerogear-js-cookbook/tree/master/intro_to_pipeline Cheers, Ted. -- View this message in context: http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Google-summer-of-code-tp6320p6377.html Sent from the aerogear-dev mailing list archive at Nabble.com. From matzew at apache.org Fri Feb 21 00:59:14 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 21 Feb 2014 06:59:14 +0100 Subject: [aerogear-dev] Let's change the AeroGear Twitter account handle In-Reply-To: References: <52EA3687.2050601@redhat.com> <52EA39C6.8020607@redhat.com> <52EF9D46.6000306@redhat.com> <953401D5-1AA2-44BB-8240-859183299450@redhat.com> <79297C6E-D46C-468B-97E3-F3F8C3396F76@redhat.com> <20140220210758.GW51006@rohan.local> Message-ID: On Thu, Feb 20, 2014 at 11:17 PM, Bruno Oliveira wrote: > I still can't see what the real value added on it. Everyone knows that > there's a team behind it, so I can't see why "_team", also do we plan to > create handles for "AeroGearPush", "AeroGearSecurity"...if yes, > not sure on all these twitter handles. I'd vote -1 on all these accounts > that makes sense. And "_project", well we know, > _project or _team - I think both is fine. I never really thought too much about it (team vs. project). > it's a project, the "s" on @aerogears always gave to me the sense of a > bunch of people behind this to make it happen. > I think the "real problem" is folks think "AeroGears" is the name of the project Wednesday I gave an AeroGear presentation. Due to the twitter handle of @AeroGears, two of those that asked questions, actually called the project AeroGears :)))) And that's what I have noticed before, which is, I think, the reason why Hylke brought it up. Unfortunately @AeroGear is taken, but I do think that @AeroGears is misleading - in terms of the name. However, your "@aerogears always gave to me the sense of a bunch of people behind this to make it happen." is a good thought! Which is believe leads towards _team, right? Again I never really interpreted too much into the meaning of the twitter handle, besides the fact that folks do not really get our name. Greetings, Matthias > > > > > On Thu, Feb 20, 2014 at 6:54 PM, Matthias Wessendorf wrote: > >> Actually, @aerogear_project makes sense (see @netty_project) >> >> >> On Thu, Feb 20, 2014 at 10:35 PM, Matthias Wessendorf wrote: >> >>> @__aerogear or @_aerogear ? >>> >>> >>> >>> >>> On Thu, Feb 20, 2014 at 10:07 PM, Douglas Campos wrote: >>> >>>> **If** we're really forced to change, I'd go with @aerogear_project >>>> >>>> -- >>>> qmx >>>> _______________________________________________ >>>> 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 >>> >> >> >> >> -- >> 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 >> > > > > -- > > -- > "The measure of a man is what he does with power" - Plato > - > @abstractj > - > Volenti Nihil Difficile > > _______________________________________________ > 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/20140221/03c9ba1d/attachment.html From matzew at apache.org Fri Feb 21 02:04:51 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 21 Feb 2014 08:04:51 +0100 Subject: [aerogear-dev] Google summer of code In-Reply-To: <1392942475423-6377.post@n5.nabble.com> References: <1392942475423-6377.post@n5.nabble.com> Message-ID: Hello Ted, how are things? Has been a while. Regarding using BridgeIt in our GoogleSummerOfCode projects, to be honest, I personally don't think we have the bandwidth to support that. The focus for our GSoC ideas should be really AeroGear focused. Also the items you are quoting are from last year's list, and I am not sure there is still interest in support them for this year. That said, if you like showing how to use BridgeIt w/ AeroGear that's fine - I will checkout the fork over the weekend, but I doubt that's an option for our GSoC project ideas. Greetings, Matthias On Fri, Feb 21, 2014 at 1:27 AM, TedGoddard wrote: > Matthias Wessendorf wrote > > * Demo: Implementing native features in mobile applications > > One option for native features would be to use BridgeIt: I'll do some > additional work on this demo, but in this fork of the aerogear-js-cookbook > I've added photo thumbnails: > > > https://github.com/bridgeit/aerogear-js-cookbook/tree/master/intro_to_pipeline > > Cheers, > Ted. > > > > > -- > View this message in context: > http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Google-summer-of-code-tp6320p6377.html > Sent from the aerogear-dev mailing list archive at Nabble.com. > _______________________________________________ > 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/20140221/bfbb1512/attachment-0001.html From matzew at apache.org Fri Feb 21 02:30:15 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 21 Feb 2014 08:30:15 +0100 Subject: [aerogear-dev] AeroGear people page In-Reply-To: References: <5306382D.5040306@redhat.com> <421D8587-C2F4-4484-A8A9-F0DB3395031A@redhat.com> Message-ID: On Thu, Feb 20, 2014 at 6:34 PM, Bruno Oliveira wrote: > When you know nothing about me, just include "This person loves bacon and > beer", that's enough to describe myself. > :-) > > -- > abstractj > > On February 20, 2014 at 2:19:46 PM, Lucas Holmquist (lholmqui at redhat.com) > wrote: > > > i think we should keep the descriptions you put :) > > > _______________________________________________ > 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/20140221/e8dce8ef/attachment.html From matzew at apache.org Fri Feb 21 02:31:42 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 21 Feb 2014 08:31:42 +0100 Subject: [aerogear-dev] AeroGear people page In-Reply-To: <5306382D.5040306@redhat.com> References: <5306382D.5040306@redhat.com> Message-ID: looks really cool, Hylke! On Thu, Feb 20, 2014 at 6:15 PM, Hylke Bons wrote: > Hello, > > I did a rough mockup for a people page like we talked about in the other > thread: > > https://raw2.github.com/hbons/aerogear-design/master/website-restructure/people_page.png > > Fairly basic for now so that we can get something up fast and improve on > it later. > Github commits would be nice to have, but I guess we can leave it out > for now, as it might be tricky. > > If everyone involved could fill in this small template we can get this > up and running soon: > http://oksoclap.com/p/AeroGearPeople > > Pass the word! :) > > Cheers, > > Hylke > _______________________________________________ > 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/20140221/5600e5b9/attachment.html From corinnekrych at gmail.com Fri Feb 21 03:30:40 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Fri, 21 Feb 2014 09:30:40 +0100 Subject: [aerogear-dev] AeroGear people page In-Reply-To: References: <5306382D.5040306@redhat.com> Message-ID: <37016429-7698-4255-8FA1-29FB324B52E2@gmail.com> +1 Hylke I?ve done my homework! ++ Corinne On 21 Feb 2014, at 08:31, Matthias Wessendorf wrote: > looks really cool, Hylke! > > > On Thu, Feb 20, 2014 at 6:15 PM, Hylke Bons wrote: > Hello, > > I did a rough mockup for a people page like we talked about in the other > thread: > https://raw2.github.com/hbons/aerogear-design/master/website-restructure/people_page.png > > Fairly basic for now so that we can get something up fast and improve on > it later. > Github commits would be nice to have, but I guess we can leave it out > for now, as it might be tricky. > > If everyone involved could fill in this small template we can get this > up and running soon: > http://oksoclap.com/p/AeroGearPeople > > Pass the word! :) > > Cheers, > > Hylke > _______________________________________________ > 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 From miguel21op at gmail.com Fri Feb 21 03:54:06 2014 From: miguel21op at gmail.com (Miguel Lemos) Date: Fri, 21 Feb 2014 08:54:06 +0000 Subject: [aerogear-dev] Issues with Aerogear on Cordova In-Reply-To: References: Message-ID: Hi! I'm trying to create a php batch to test faster my notifications. So I did this (simplified example): $ch = curl_init('https://aerogear-metalpush.rhcloud.com/rest/sender'); $data = array( 'message' => array( 'atl' => 'Aviso', 'avs' => 'Mensagem', 'badge' => '1' ) ); $data_st = json_encode($data); $headers = array("Accept: application/json", "Content-Type: application/json"); curl_setopt($ch, CURLOPT_CONNECTTIMEOUT, 6); curl_setopt($ch, CURLOPT_CUSTOMREQUEST, "POST"); curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false); curl_setopt($ch, CURLOPT_RETURNTRANSFER, true); curl_setopt($ch, CURLOPT_USERPWD, "$key:$secret"); curl_setopt($ch, CURLOPT_HTTPHEADER, $headers); curl_setopt($ch, CURLOPT_POSTFIELDS, $data_st); $result = curl_exec($ch); I think that's something wrong with the $data array because the server returns: " *The request sent by the client was syntactically incorrect ().* If I strip the string from the "message" it returns "job submitted", but of course I don't receive nothing. Thanks again M On Thu, Feb 20, 2014 at 8:48 AM, Sebastien Blanc wrote: > This is really cool Miguel ! > Don't hesitate to ask us other questions and also , like you did with your > screenshot, give us feedback ! > Thanks again for your interest in the project. > Sebi > > > > On Thu, Feb 20, 2014 at 9:43 AM, Miiguel Lemos wrote: > >> Not all, but a couple of steps on the right direction, I hope ;-) >> >> Enviado do meu iPad >> >> No dia 19/02/2014, ?s 21:20, Matthias Wessendorf >> escreveu: >> >> Nice! >> >> Glad you are all set! >> >> -Matthias >> >> >> On Wed, Feb 19, 2014 at 4:38 PM, Miguel Lemos wrote: >> >>> A small souvenir ;-) >>> >>> Thanks again >>> >>> >>> >>> >>> On Wed, Feb 19, 2014 at 3:20 PM, Miguel Lemos wrote: >>> >>>> Hi Matthias, >>>> >>>> Maybe I didn't make myself clear, but your answer was clear enough to >>>> respond to my post :-) >>>> >>>> Thanks again. >>>> >>>> Carry on! >>>> >>>> M >>>> >>>> >>>> >>>> On Wed, Feb 19, 2014 at 3:05 PM, Matthias Wessendorf >>> > wrote: >>>> >>>>> >>>>> >>>>> >>>>> On Wed, Feb 19, 2014 at 3:43 PM, Miguel Lemos wrote: >>>>> >>>>>> Dear Matthias, >>>>>> >>>>>> According to the information posted in the url below, I can send (and >>>>>> read) several parameters / keys in the scope of the notification service >>>>>> (as it should be...): >>>>>> >>>>>> http://aerogear.org/docs/specs/aerogear-push-messages/ >>>>>> >>>>>> According to the values on it, the receiver should have the capacity >>>>>> to decide what to do next. >>>>>> >>>>>> First, and the easiest thing: don't show the "Alert" text, but any >>>>>> other part of content received and / or change "Alert" to another >>>>>> language, for instance. >>>>>> >>>>> >>>>> Not sure I follow. >>>>> >>>>> The 'alert' is a keyword on iOS, which our server (and our Cordova >>>>> Libs) do recognize. What do you want to change there ? >>>>> For the completion of our spec, we are showing all of the keywords, >>>>> that are supported. >>>>> >>>>> >>>>> >>>>>> >>>>>> Second, if I create (for instance) a lat, lon and rad parameters, I >>>>>> can decide if I show the notification immediately, or only when the user >>>>>> reaches a matchable location, within a given radius. >>>>>> This is just an example of the freedom that must be available to >>>>>> decide what to do according to a given parameter that the software on the >>>>>> client's side can interpret. The message itself may not be the most >>>>>> important part of the whole thing... >>>>>> >>>>> >>>>> If you don't want or need that alert, simply leave it our of the >>>>> payload. It's just part of the demo/docs as that is quite handy to get >>>>> going. >>>>> >>>>> >>>>>> >>>>>> So, the question is: how can I read those parameters / keys before >>>>>> deciding to do with the notification? Through a "regular" object keys >>>>>> iterator? Thank you very much again. If there's some place in the >>>>>> documentation where I can understand that, please let me know. >>>>>> >>>>> >>>>> yes, like here (using alert just as an example): >>>>> >>>>> >>>>> function onNotification(e) { >>>>> alert(e.payload.foo); >>>>> alert(e.payload.key); >>>>> } >>>>> >>>>> And the curl for that would be something _like_ this: >>>>> curl -3 -u "ID:secrect" -v -H "Accept: application/json" -H >>>>> "Content-type: application/json" -X POST -d '{"message": {"foo":"bar >>>>> value", "key":"HELLO"}}' >>>>> https://something-doamin.rhcloud.com/rest/sender >>>>> >>>>> >>>>> -Matthias >>>>> >>>>> >>>>> >>>>> >>>>>> >>>>>> >>>>>> Miguel >>>>>> >>>>>> >>>>>> >>>>>> On Wed, Feb 19, 2014 at 1:34 PM, Matthias Wessendorf < >>>>>> matzew at apache.org> wrote: >>>>>> >>>>>>> Awesome, >>>>>>> >>>>>>> we are interested in hearing your feedback. >>>>>>> >>>>>>> Good luck w/ the development process! >>>>>>> >>>>>>> -Matthias >>>>>>> >>>>>>> >>>>>>> On Wed, Feb 19, 2014 at 2:29 PM, Miguel Lemos wrote: >>>>>>> >>>>>>>> Thanks. Of course I'll give you my feedback ;-) >>>>>>>> >>>>>>>> I've some questions about the service as a whole, but I'll make >>>>>>>> some more testing and then I'll let you know. >>>>>>>> >>>>>>>> Thank you very much again for your attention. >>>>>>>> >>>>>>>> All the best, >>>>>>>> >>>>>>>> Miguel >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Feb 19, 2014 at 1:25 PM, Matthias Wessendorf < >>>>>>>> matzew at apache.org> wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, Feb 19, 2014 at 2:18 PM, Miguel Lemos < >>>>>>>>> miguel21op at gmail.com> wrote: >>>>>>>>> >>>>>>>>>> Hi Matthias, >>>>>>>>>> >>>>>>>>>> One of the biggest reasons I'm testing this solutions is because >>>>>>>>>> iOS! >>>>>>>>>> >>>>>>>>>> Once we already developed a full native Android push (considering >>>>>>>>>> geofencing) notification service. The issue is to port our solution to iOS >>>>>>>>>> (not only the notifications, but everything). That's why I'm personally >>>>>>>>>> testing Cordova on Android and already partially on IOS. So far so good.. >>>>>>>>>> >>>>>>>>> >>>>>>>>> Sounds very interesting. If you are interested, let us know how it >>>>>>>>> goes. >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> I'm starting with Android because it's easier to me. But next >>>>>>>>>> week I want to test your solution with iOS. Why? Is there any problem? >>>>>>>>>> >>>>>>>>> >>>>>>>>> No problem there at all :-) I was just curious if you target >>>>>>>>> Android first/only. >>>>>>>>> >>>>>>>>> Greetings, >>>>>>>>> Matthias >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> >>>>>>>>>> Miguel >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Wed, Feb 19, 2014 at 1:04 PM, Matthias Wessendorf < >>>>>>>>>> matzew at apache.org> wrote: >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Wed, Feb 19, 2014 at 1:20 PM, Miguel Lemos < >>>>>>>>>>> miguel21op at gmail.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi all, >>>>>>>>>>>> >>>>>>>>>>>> I tested and now it works, thanks. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> glad it all worked out >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> When I tried for the first time, I tried with the function >>>>>>>>>>>> global, reflecting the Github example. But as it didn't work (because of >>>>>>>>>>>> the "damn" URL issue...) I tried several things, one of them being put the >>>>>>>>>>>> alert function inside the deviceready event. Of course, when I solved the >>>>>>>>>>>> URL thing I never more remembered to put it outside again... >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Things like that might happen. >>>>>>>>>>> >>>>>>>>>>> Regarding the URL, we will try to update the OpenShift blog post. >>>>>>>>>>> >>>>>>>>>>> I just checkout project documentation, and it looks like they >>>>>>>>>>> are already 'right'. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Wondering: Are you building Cordova clients for Android only, or >>>>>>>>>>> do you plan to use the iOS platform as well ? >>>>>>>>>>> >>>>>>>>>>> Greetings, >>>>>>>>>>> Matthias >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> 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 >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> 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 >>>>> >>>>> _______________________________________________ >>>>> 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 >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140221/28308726/attachment-0001.html From matzew at apache.org Fri Feb 21 04:01:02 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 21 Feb 2014 10:01:02 +0100 Subject: [aerogear-dev] Issues with Aerogear on Cordova In-Reply-To: References: Message-ID: Hey Miguel, we had an intern working on a PHP client, last year here is is project: https://github.com/tmccarthy9/aerogear-unified-push-php-client I know he has been testing it against our server - perhaps that library is handy for you ? Btw. if you feel to make changes to the given PHP client, feel free to send PullRequests against the repo, we will be able to merge them -Matthias On Fri, Feb 21, 2014 at 9:54 AM, Miguel Lemos wrote: > Hi! > > I'm trying to create a php batch to test faster my notifications. So I did > this (simplified example): > > $ch = curl_init('https://aerogear-metalpush.rhcloud.com/rest/sender'); > > $data = array( > 'message' => array( > 'atl' => 'Aviso', > 'avs' => 'Mensagem', > 'badge' => '1' > ) > ); > > $data_st = json_encode($data); > $headers = array("Accept: application/json", "Content-Type: > application/json"); > curl_setopt($ch, CURLOPT_CONNECTTIMEOUT, 6); > curl_setopt($ch, CURLOPT_CUSTOMREQUEST, "POST"); > curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false); > curl_setopt($ch, CURLOPT_RETURNTRANSFER, true); > curl_setopt($ch, CURLOPT_USERPWD, "$key:$secret"); > curl_setopt($ch, CURLOPT_HTTPHEADER, > $headers); > curl_setopt($ch, CURLOPT_POSTFIELDS, $data_st); > > $result = curl_exec($ch); > > I think that's something wrong with the $data array because the server > returns: " > *The request sent by the client was syntactically incorrect (). * > > If I strip the string from the "message" it returns "job submitted", but > of course I don't receive nothing. > > Thanks again > > M > > > > > On Thu, Feb 20, 2014 at 8:48 AM, Sebastien Blanc wrote: > >> This is really cool Miguel ! >> Don't hesitate to ask us other questions and also , like you did with >> your screenshot, give us feedback ! >> Thanks again for your interest in the project. >> Sebi >> >> >> >> On Thu, Feb 20, 2014 at 9:43 AM, Miiguel Lemos wrote: >> >>> Not all, but a couple of steps on the right direction, I hope ;-) >>> >>> Enviado do meu iPad >>> >>> No dia 19/02/2014, ?s 21:20, Matthias Wessendorf >>> escreveu: >>> >>> Nice! >>> >>> Glad you are all set! >>> >>> -Matthias >>> >>> >>> On Wed, Feb 19, 2014 at 4:38 PM, Miguel Lemos wrote: >>> >>>> A small souvenir ;-) >>>> >>>> Thanks again >>>> >>>> >>>> >>>> >>>> On Wed, Feb 19, 2014 at 3:20 PM, Miguel Lemos wrote: >>>> >>>>> Hi Matthias, >>>>> >>>>> Maybe I didn't make myself clear, but your answer was clear enough to >>>>> respond to my post :-) >>>>> >>>>> Thanks again. >>>>> >>>>> Carry on! >>>>> >>>>> M >>>>> >>>>> >>>>> >>>>> On Wed, Feb 19, 2014 at 3:05 PM, Matthias Wessendorf < >>>>> matzew at apache.org> wrote: >>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Wed, Feb 19, 2014 at 3:43 PM, Miguel Lemos wrote: >>>>>> >>>>>>> Dear Matthias, >>>>>>> >>>>>>> According to the information posted in the url below, I can send >>>>>>> (and read) several parameters / keys in the scope of the notification >>>>>>> service (as it should be...): >>>>>>> >>>>>>> http://aerogear.org/docs/specs/aerogear-push-messages/ >>>>>>> >>>>>>> According to the values on it, the receiver should have the capacity >>>>>>> to decide what to do next. >>>>>>> >>>>>>> First, and the easiest thing: don't show the "Alert" text, but any >>>>>>> other part of content received and / or change "Alert" to another >>>>>>> language, for instance. >>>>>>> >>>>>> >>>>>> Not sure I follow. >>>>>> >>>>>> The 'alert' is a keyword on iOS, which our server (and our Cordova >>>>>> Libs) do recognize. What do you want to change there ? >>>>>> For the completion of our spec, we are showing all of the keywords, >>>>>> that are supported. >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> Second, if I create (for instance) a lat, lon and rad parameters, I >>>>>>> can decide if I show the notification immediately, or only when the user >>>>>>> reaches a matchable location, within a given radius. >>>>>>> This is just an example of the freedom that must be available to >>>>>>> decide what to do according to a given parameter that the software on the >>>>>>> client's side can interpret. The message itself may not be the most >>>>>>> important part of the whole thing... >>>>>>> >>>>>> >>>>>> If you don't want or need that alert, simply leave it our of the >>>>>> payload. It's just part of the demo/docs as that is quite handy to get >>>>>> going. >>>>>> >>>>>> >>>>>>> >>>>>>> So, the question is: how can I read those parameters / keys before >>>>>>> deciding to do with the notification? Through a "regular" object keys >>>>>>> iterator? Thank you very much again. If there's some place in the >>>>>>> documentation where I can understand that, please let me know. >>>>>>> >>>>>> >>>>>> yes, like here (using alert just as an example): >>>>>> >>>>>> >>>>>> function onNotification(e) { >>>>>> alert(e.payload.foo); >>>>>> alert(e.payload.key); >>>>>> } >>>>>> >>>>>> And the curl for that would be something _like_ this: >>>>>> curl -3 -u "ID:secrect" -v -H "Accept: application/json" -H >>>>>> "Content-type: application/json" -X POST -d '{"message": {"foo":"bar >>>>>> value", "key":"HELLO"}}' >>>>>> https://something-doamin.rhcloud.com/rest/sender >>>>>> >>>>>> >>>>>> -Matthias >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> Miguel >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Wed, Feb 19, 2014 at 1:34 PM, Matthias Wessendorf < >>>>>>> matzew at apache.org> wrote: >>>>>>> >>>>>>>> Awesome, >>>>>>>> >>>>>>>> we are interested in hearing your feedback. >>>>>>>> >>>>>>>> Good luck w/ the development process! >>>>>>>> >>>>>>>> -Matthias >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Feb 19, 2014 at 2:29 PM, Miguel Lemos >>>>>>> > wrote: >>>>>>>> >>>>>>>>> Thanks. Of course I'll give you my feedback ;-) >>>>>>>>> >>>>>>>>> I've some questions about the service as a whole, but I'll make >>>>>>>>> some more testing and then I'll let you know. >>>>>>>>> >>>>>>>>> Thank you very much again for your attention. >>>>>>>>> >>>>>>>>> All the best, >>>>>>>>> >>>>>>>>> Miguel >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, Feb 19, 2014 at 1:25 PM, Matthias Wessendorf < >>>>>>>>> matzew at apache.org> wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Wed, Feb 19, 2014 at 2:18 PM, Miguel Lemos < >>>>>>>>>> miguel21op at gmail.com> wrote: >>>>>>>>>> >>>>>>>>>>> Hi Matthias, >>>>>>>>>>> >>>>>>>>>>> One of the biggest reasons I'm testing this solutions is because >>>>>>>>>>> iOS! >>>>>>>>>>> >>>>>>>>>>> Once we already developed a full native Android push >>>>>>>>>>> (considering geofencing) notification service. The issue is to port our >>>>>>>>>>> solution to iOS (not only the notifications, but everything). That's why >>>>>>>>>>> I'm personally testing Cordova on Android and already partially on IOS. So >>>>>>>>>>> far so good.. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Sounds very interesting. If you are interested, let us know how >>>>>>>>>> it goes. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I'm starting with Android because it's easier to me. But next >>>>>>>>>>> week I want to test your solution with iOS. Why? Is there any problem? >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> No problem there at all :-) I was just curious if you target >>>>>>>>>> Android first/only. >>>>>>>>>> >>>>>>>>>> Greetings, >>>>>>>>>> Matthias >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks >>>>>>>>>>> >>>>>>>>>>> Miguel >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Wed, Feb 19, 2014 at 1:04 PM, Matthias Wessendorf < >>>>>>>>>>> matzew at apache.org> wrote: >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Wed, Feb 19, 2014 at 1:20 PM, Miguel Lemos < >>>>>>>>>>>> miguel21op at gmail.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Hi all, >>>>>>>>>>>>> >>>>>>>>>>>>> I tested and now it works, thanks. >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> glad it all worked out >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> When I tried for the first time, I tried with the function >>>>>>>>>>>>> global, reflecting the Github example. But as it didn't work (because of >>>>>>>>>>>>> the "damn" URL issue...) I tried several things, one of them being put the >>>>>>>>>>>>> alert function inside the deviceready event. Of course, when I solved the >>>>>>>>>>>>> URL thing I never more remembered to put it outside again... >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Things like that might happen. >>>>>>>>>>>> >>>>>>>>>>>> Regarding the URL, we will try to update the OpenShift blog >>>>>>>>>>>> post. >>>>>>>>>>>> >>>>>>>>>>>> I just checkout project documentation, and it looks like they >>>>>>>>>>>> are already 'right'. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Wondering: Are you building Cordova clients for Android only, >>>>>>>>>>>> or do you plan to use the iOS platform as well ? >>>>>>>>>>>> >>>>>>>>>>>> Greetings, >>>>>>>>>>>> Matthias >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> 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 >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> 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 >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>> >> >> >> _______________________________________________ >> 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/20140221/3f476dcc/attachment-0001.html From scm.blanc at gmail.com Fri Feb 21 04:03:04 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Fri, 21 Feb 2014 10:03:04 +0100 Subject: [aerogear-dev] Issues with Aerogear on Cordova In-Reply-To: References: Message-ID: On Fri, Feb 21, 2014 at 10:01 AM, Matthias Wessendorf wrote: > Hey Miguel, > > we had an intern working on a PHP client, last year > > here is is project: > https://github.com/tmccarthy9/aerogear-unified-push-php-client > Especially this class https://github.com/tmccarthy9/aerogear-unified-push-php-client/blob/master/src/Tester.php which shows how to construct a message > > > I know he has been testing it against our server - perhaps that library is > handy for you ? > > Btw. if you feel to make changes to the given PHP client, feel free to > send PullRequests against the repo, we will be able to merge them > > -Matthias > > > > > On Fri, Feb 21, 2014 at 9:54 AM, Miguel Lemos wrote: > >> Hi! >> >> I'm trying to create a php batch to test faster my notifications. So I >> did this (simplified example): >> >> $ch = curl_init('https://aerogear-metalpush.rhcloud.com/rest/sender'); >> >> $data = array( >> 'message' => array( >> 'atl' => 'Aviso', >> 'avs' => 'Mensagem', >> 'badge' => '1' >> ) >> ); >> >> $data_st = json_encode($data); >> $headers = array("Accept: application/json", "Content-Type: >> application/json"); >> curl_setopt($ch, CURLOPT_CONNECTTIMEOUT, 6); >> curl_setopt($ch, CURLOPT_CUSTOMREQUEST, "POST"); >> curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false); >> curl_setopt($ch, CURLOPT_RETURNTRANSFER, true); >> curl_setopt($ch, CURLOPT_USERPWD, "$key:$secret"); >> curl_setopt($ch, CURLOPT_HTTPHEADER, >> $headers); >> curl_setopt($ch, CURLOPT_POSTFIELDS, $data_st); >> >> $result = curl_exec($ch); >> >> I think that's something wrong with the $data array because the server >> returns: " >> *The request sent by the client was syntactically incorrect (). * >> >> If I strip the string from the "message" it returns "job submitted", but >> of course I don't receive nothing. >> >> Thanks again >> >> M >> >> >> >> >> On Thu, Feb 20, 2014 at 8:48 AM, Sebastien Blanc wrote: >> >>> This is really cool Miguel ! >>> Don't hesitate to ask us other questions and also , like you did with >>> your screenshot, give us feedback ! >>> Thanks again for your interest in the project. >>> Sebi >>> >>> >>> >>> On Thu, Feb 20, 2014 at 9:43 AM, Miiguel Lemos wrote: >>> >>>> Not all, but a couple of steps on the right direction, I hope ;-) >>>> >>>> Enviado do meu iPad >>>> >>>> No dia 19/02/2014, ?s 21:20, Matthias Wessendorf >>>> escreveu: >>>> >>>> Nice! >>>> >>>> Glad you are all set! >>>> >>>> -Matthias >>>> >>>> >>>> On Wed, Feb 19, 2014 at 4:38 PM, Miguel Lemos wrote: >>>> >>>>> A small souvenir ;-) >>>>> >>>>> Thanks again >>>>> >>>>> >>>>> >>>>> >>>>> On Wed, Feb 19, 2014 at 3:20 PM, Miguel Lemos wrote: >>>>> >>>>>> Hi Matthias, >>>>>> >>>>>> Maybe I didn't make myself clear, but your answer was clear enough to >>>>>> respond to my post :-) >>>>>> >>>>>> Thanks again. >>>>>> >>>>>> Carry on! >>>>>> >>>>>> M >>>>>> >>>>>> >>>>>> >>>>>> On Wed, Feb 19, 2014 at 3:05 PM, Matthias Wessendorf < >>>>>> matzew at apache.org> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Wed, Feb 19, 2014 at 3:43 PM, Miguel Lemos wrote: >>>>>>> >>>>>>>> Dear Matthias, >>>>>>>> >>>>>>>> According to the information posted in the url below, I can send >>>>>>>> (and read) several parameters / keys in the scope of the notification >>>>>>>> service (as it should be...): >>>>>>>> >>>>>>>> http://aerogear.org/docs/specs/aerogear-push-messages/ >>>>>>>> >>>>>>>> According to the values on it, the receiver should have the >>>>>>>> capacity to decide what to do next. >>>>>>>> >>>>>>>> First, and the easiest thing: don't show the "Alert" text, but any >>>>>>>> other part of content received and / or change "Alert" to another >>>>>>>> language, for instance. >>>>>>>> >>>>>>> >>>>>>> Not sure I follow. >>>>>>> >>>>>>> The 'alert' is a keyword on iOS, which our server (and our Cordova >>>>>>> Libs) do recognize. What do you want to change there ? >>>>>>> For the completion of our spec, we are showing all of the keywords, >>>>>>> that are supported. >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Second, if I create (for instance) a lat, lon and rad parameters, I >>>>>>>> can decide if I show the notification immediately, or only when the user >>>>>>>> reaches a matchable location, within a given radius. >>>>>>>> This is just an example of the freedom that must be available to >>>>>>>> decide what to do according to a given parameter that the software on the >>>>>>>> client's side can interpret. The message itself may not be the most >>>>>>>> important part of the whole thing... >>>>>>>> >>>>>>> >>>>>>> If you don't want or need that alert, simply leave it our of the >>>>>>> payload. It's just part of the demo/docs as that is quite handy to get >>>>>>> going. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> So, the question is: how can I read those parameters / keys before >>>>>>>> deciding to do with the notification? Through a "regular" object keys >>>>>>>> iterator? Thank you very much again. If there's some place in the >>>>>>>> documentation where I can understand that, please let me know. >>>>>>>> >>>>>>> >>>>>>> yes, like here (using alert just as an example): >>>>>>> >>>>>>> >>>>>>> function onNotification(e) { >>>>>>> alert(e.payload.foo); >>>>>>> alert(e.payload.key); >>>>>>> } >>>>>>> >>>>>>> And the curl for that would be something _like_ this: >>>>>>> curl -3 -u "ID:secrect" -v -H "Accept: application/json" -H >>>>>>> "Content-type: application/json" -X POST -d '{"message": {"foo":"bar >>>>>>> value", "key":"HELLO"}}' >>>>>>> https://something-doamin.rhcloud.com/rest/sender >>>>>>> >>>>>>> >>>>>>> -Matthias >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Miguel >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Feb 19, 2014 at 1:34 PM, Matthias Wessendorf < >>>>>>>> matzew at apache.org> wrote: >>>>>>>> >>>>>>>>> Awesome, >>>>>>>>> >>>>>>>>> we are interested in hearing your feedback. >>>>>>>>> >>>>>>>>> Good luck w/ the development process! >>>>>>>>> >>>>>>>>> -Matthias >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, Feb 19, 2014 at 2:29 PM, Miguel Lemos < >>>>>>>>> miguel21op at gmail.com> wrote: >>>>>>>>> >>>>>>>>>> Thanks. Of course I'll give you my feedback ;-) >>>>>>>>>> >>>>>>>>>> I've some questions about the service as a whole, but I'll make >>>>>>>>>> some more testing and then I'll let you know. >>>>>>>>>> >>>>>>>>>> Thank you very much again for your attention. >>>>>>>>>> >>>>>>>>>> All the best, >>>>>>>>>> >>>>>>>>>> Miguel >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Wed, Feb 19, 2014 at 1:25 PM, Matthias Wessendorf < >>>>>>>>>> matzew at apache.org> wrote: >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Wed, Feb 19, 2014 at 2:18 PM, Miguel Lemos < >>>>>>>>>>> miguel21op at gmail.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi Matthias, >>>>>>>>>>>> >>>>>>>>>>>> One of the biggest reasons I'm testing this solutions is >>>>>>>>>>>> because iOS! >>>>>>>>>>>> >>>>>>>>>>>> Once we already developed a full native Android push >>>>>>>>>>>> (considering geofencing) notification service. The issue is to port our >>>>>>>>>>>> solution to iOS (not only the notifications, but everything). That's why >>>>>>>>>>>> I'm personally testing Cordova on Android and already partially on IOS. So >>>>>>>>>>>> far so good.. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Sounds very interesting. If you are interested, let us know how >>>>>>>>>>> it goes. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I'm starting with Android because it's easier to me. But next >>>>>>>>>>>> week I want to test your solution with iOS. Why? Is there any problem? >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> No problem there at all :-) I was just curious if you target >>>>>>>>>>> Android first/only. >>>>>>>>>>> >>>>>>>>>>> Greetings, >>>>>>>>>>> Matthias >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks >>>>>>>>>>>> >>>>>>>>>>>> Miguel >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Wed, Feb 19, 2014 at 1:04 PM, Matthias Wessendorf < >>>>>>>>>>>> matzew at apache.org> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Wed, Feb 19, 2014 at 1:20 PM, Miguel Lemos < >>>>>>>>>>>>> miguel21op at gmail.com> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Hi all, >>>>>>>>>>>>>> >>>>>>>>>>>>>> I tested and now it works, thanks. >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> glad it all worked out >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> When I tried for the first time, I tried with the function >>>>>>>>>>>>>> global, reflecting the Github example. But as it didn't work (because of >>>>>>>>>>>>>> the "damn" URL issue...) I tried several things, one of them being put the >>>>>>>>>>>>>> alert function inside the deviceready event. Of course, when I solved the >>>>>>>>>>>>>> URL thing I never more remembered to put it outside again... >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Things like that might happen. >>>>>>>>>>>>> >>>>>>>>>>>>> Regarding the URL, we will try to update the OpenShift blog >>>>>>>>>>>>> post. >>>>>>>>>>>>> >>>>>>>>>>>>> I just checkout project documentation, and it looks like they >>>>>>>>>>>>> are already 'right'. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Wondering: Are you building Cordova clients for Android only, >>>>>>>>>>>>> or do you plan to use the iOS platform as well ? >>>>>>>>>>>>> >>>>>>>>>>>>> Greetings, >>>>>>>>>>>>> Matthias >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> 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 >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> 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 >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>> >>> >>> >>> _______________________________________________ >>> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140221/d6182edc/attachment-0001.html From miguel21op at gmail.com Fri Feb 21 04:10:31 2014 From: miguel21op at gmail.com (Miguel Lemos) Date: Fri, 21 Feb 2014 09:10:31 +0000 Subject: [aerogear-dev] Issues with Aerogear on Cordova In-Reply-To: References: Message-ID: OK. I'll give it a try. In any case can someone explain what's wrong with my string? I think that's the only problem. Thanks again for the swift response. M On Fri, Feb 21, 2014 at 9:01 AM, Matthias Wessendorf wrote: > Hey Miguel, > > we had an intern working on a PHP client, last year > > here is is project: > https://github.com/tmccarthy9/aerogear-unified-push-php-client > > I know he has been testing it against our server - perhaps that library is > handy for you ? > > Btw. if you feel to make changes to the given PHP client, feel free to > send PullRequests against the repo, we will be able to merge them > > -Matthias > > > > > On Fri, Feb 21, 2014 at 9:54 AM, Miguel Lemos wrote: > >> Hi! >> >> I'm trying to create a php batch to test faster my notifications. So I >> did this (simplified example): >> >> $ch = curl_init('https://aerogear-metalpush.rhcloud.com/rest/sender'); >> >> $data = array( >> 'message' => array( >> 'atl' => 'Aviso', >> 'avs' => 'Mensagem', >> 'badge' => '1' >> ) >> ); >> >> $data_st = json_encode($data); >> $headers = array("Accept: application/json", "Content-Type: >> application/json"); >> curl_setopt($ch, CURLOPT_CONNECTTIMEOUT, 6); >> curl_setopt($ch, CURLOPT_CUSTOMREQUEST, "POST"); >> curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false); >> curl_setopt($ch, CURLOPT_RETURNTRANSFER, true); >> curl_setopt($ch, CURLOPT_USERPWD, "$key:$secret"); >> curl_setopt($ch, CURLOPT_HTTPHEADER, >> $headers); >> curl_setopt($ch, CURLOPT_POSTFIELDS, $data_st); >> >> $result = curl_exec($ch); >> >> I think that's something wrong with the $data array because the server >> returns: " >> *The request sent by the client was syntactically incorrect (). * >> >> If I strip the string from the "message" it returns "job submitted", but >> of course I don't receive nothing. >> >> Thanks again >> >> M >> >> >> >> >> On Thu, Feb 20, 2014 at 8:48 AM, Sebastien Blanc wrote: >> >>> This is really cool Miguel ! >>> Don't hesitate to ask us other questions and also , like you did with >>> your screenshot, give us feedback ! >>> Thanks again for your interest in the project. >>> Sebi >>> >>> >>> >>> On Thu, Feb 20, 2014 at 9:43 AM, Miiguel Lemos wrote: >>> >>>> Not all, but a couple of steps on the right direction, I hope ;-) >>>> >>>> Enviado do meu iPad >>>> >>>> No dia 19/02/2014, ?s 21:20, Matthias Wessendorf >>>> escreveu: >>>> >>>> Nice! >>>> >>>> Glad you are all set! >>>> >>>> -Matthias >>>> >>>> >>>> On Wed, Feb 19, 2014 at 4:38 PM, Miguel Lemos wrote: >>>> >>>>> A small souvenir ;-) >>>>> >>>>> Thanks again >>>>> >>>>> >>>>> >>>>> >>>>> On Wed, Feb 19, 2014 at 3:20 PM, Miguel Lemos wrote: >>>>> >>>>>> Hi Matthias, >>>>>> >>>>>> Maybe I didn't make myself clear, but your answer was clear enough to >>>>>> respond to my post :-) >>>>>> >>>>>> Thanks again. >>>>>> >>>>>> Carry on! >>>>>> >>>>>> M >>>>>> >>>>>> >>>>>> >>>>>> On Wed, Feb 19, 2014 at 3:05 PM, Matthias Wessendorf < >>>>>> matzew at apache.org> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Wed, Feb 19, 2014 at 3:43 PM, Miguel Lemos wrote: >>>>>>> >>>>>>>> Dear Matthias, >>>>>>>> >>>>>>>> According to the information posted in the url below, I can send >>>>>>>> (and read) several parameters / keys in the scope of the notification >>>>>>>> service (as it should be...): >>>>>>>> >>>>>>>> http://aerogear.org/docs/specs/aerogear-push-messages/ >>>>>>>> >>>>>>>> According to the values on it, the receiver should have the >>>>>>>> capacity to decide what to do next. >>>>>>>> >>>>>>>> First, and the easiest thing: don't show the "Alert" text, but any >>>>>>>> other part of content received and / or change "Alert" to another >>>>>>>> language, for instance. >>>>>>>> >>>>>>> >>>>>>> Not sure I follow. >>>>>>> >>>>>>> The 'alert' is a keyword on iOS, which our server (and our Cordova >>>>>>> Libs) do recognize. What do you want to change there ? >>>>>>> For the completion of our spec, we are showing all of the keywords, >>>>>>> that are supported. >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Second, if I create (for instance) a lat, lon and rad parameters, I >>>>>>>> can decide if I show the notification immediately, or only when the user >>>>>>>> reaches a matchable location, within a given radius. >>>>>>>> This is just an example of the freedom that must be available to >>>>>>>> decide what to do according to a given parameter that the software on the >>>>>>>> client's side can interpret. The message itself may not be the most >>>>>>>> important part of the whole thing... >>>>>>>> >>>>>>> >>>>>>> If you don't want or need that alert, simply leave it our of the >>>>>>> payload. It's just part of the demo/docs as that is quite handy to get >>>>>>> going. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> So, the question is: how can I read those parameters / keys before >>>>>>>> deciding to do with the notification? Through a "regular" object keys >>>>>>>> iterator? Thank you very much again. If there's some place in the >>>>>>>> documentation where I can understand that, please let me know. >>>>>>>> >>>>>>> >>>>>>> yes, like here (using alert just as an example): >>>>>>> >>>>>>> >>>>>>> function onNotification(e) { >>>>>>> alert(e.payload.foo); >>>>>>> alert(e.payload.key); >>>>>>> } >>>>>>> >>>>>>> And the curl for that would be something _like_ this: >>>>>>> curl -3 -u "ID:secrect" -v -H "Accept: application/json" -H >>>>>>> "Content-type: application/json" -X POST -d '{"message": {"foo":"bar >>>>>>> value", "key":"HELLO"}}' >>>>>>> https://something-doamin.rhcloud.com/rest/sender >>>>>>> >>>>>>> >>>>>>> -Matthias >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Miguel >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Feb 19, 2014 at 1:34 PM, Matthias Wessendorf < >>>>>>>> matzew at apache.org> wrote: >>>>>>>> >>>>>>>>> Awesome, >>>>>>>>> >>>>>>>>> we are interested in hearing your feedback. >>>>>>>>> >>>>>>>>> Good luck w/ the development process! >>>>>>>>> >>>>>>>>> -Matthias >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, Feb 19, 2014 at 2:29 PM, Miguel Lemos < >>>>>>>>> miguel21op at gmail.com> wrote: >>>>>>>>> >>>>>>>>>> Thanks. Of course I'll give you my feedback ;-) >>>>>>>>>> >>>>>>>>>> I've some questions about the service as a whole, but I'll make >>>>>>>>>> some more testing and then I'll let you know. >>>>>>>>>> >>>>>>>>>> Thank you very much again for your attention. >>>>>>>>>> >>>>>>>>>> All the best, >>>>>>>>>> >>>>>>>>>> Miguel >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Wed, Feb 19, 2014 at 1:25 PM, Matthias Wessendorf < >>>>>>>>>> matzew at apache.org> wrote: >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Wed, Feb 19, 2014 at 2:18 PM, Miguel Lemos < >>>>>>>>>>> miguel21op at gmail.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi Matthias, >>>>>>>>>>>> >>>>>>>>>>>> One of the biggest reasons I'm testing this solutions is >>>>>>>>>>>> because iOS! >>>>>>>>>>>> >>>>>>>>>>>> Once we already developed a full native Android push >>>>>>>>>>>> (considering geofencing) notification service. The issue is to port our >>>>>>>>>>>> solution to iOS (not only the notifications, but everything). That's why >>>>>>>>>>>> I'm personally testing Cordova on Android and already partially on IOS. So >>>>>>>>>>>> far so good.. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Sounds very interesting. If you are interested, let us know how >>>>>>>>>>> it goes. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I'm starting with Android because it's easier to me. But next >>>>>>>>>>>> week I want to test your solution with iOS. Why? Is there any problem? >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> No problem there at all :-) I was just curious if you target >>>>>>>>>>> Android first/only. >>>>>>>>>>> >>>>>>>>>>> Greetings, >>>>>>>>>>> Matthias >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks >>>>>>>>>>>> >>>>>>>>>>>> Miguel >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Wed, Feb 19, 2014 at 1:04 PM, Matthias Wessendorf < >>>>>>>>>>>> matzew at apache.org> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Wed, Feb 19, 2014 at 1:20 PM, Miguel Lemos < >>>>>>>>>>>>> miguel21op at gmail.com> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Hi all, >>>>>>>>>>>>>> >>>>>>>>>>>>>> I tested and now it works, thanks. >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> glad it all worked out >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> When I tried for the first time, I tried with the function >>>>>>>>>>>>>> global, reflecting the Github example. But as it didn't work (because of >>>>>>>>>>>>>> the "damn" URL issue...) I tried several things, one of them being put the >>>>>>>>>>>>>> alert function inside the deviceready event. Of course, when I solved the >>>>>>>>>>>>>> URL thing I never more remembered to put it outside again... >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Things like that might happen. >>>>>>>>>>>>> >>>>>>>>>>>>> Regarding the URL, we will try to update the OpenShift blog >>>>>>>>>>>>> post. >>>>>>>>>>>>> >>>>>>>>>>>>> I just checkout project documentation, and it looks like they >>>>>>>>>>>>> are already 'right'. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Wondering: Are you building Cordova clients for Android only, >>>>>>>>>>>>> or do you plan to use the iOS platform as well ? >>>>>>>>>>>>> >>>>>>>>>>>>> Greetings, >>>>>>>>>>>>> Matthias >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> 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 >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> 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 >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>> >>> >>> >>> _______________________________________________ >>> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140221/75da1685/attachment-0001.html From matzew at apache.org Fri Feb 21 04:17:23 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 21 Feb 2014 10:17:23 +0100 Subject: [aerogear-dev] Issues with Aerogear on Cordova In-Reply-To: References: Message-ID: Oh - I just see the PHP client supports some sort of older API we used to have in the past: https://github.com/tmccarthy9/aerogear-unified-push-php-client/blob/master/src/SenderClient.php#L103 Since the intern left, nobody was actually paying too much attention on the PHP client - we are mostly Java Weenies :) On Fri, Feb 21, 2014 at 10:10 AM, Miguel Lemos wrote: > OK. I'll give it a try. In any case can someone explain what's wrong with > my string? I think that's the only problem. > > Thanks again for the swift response. > > M > > > On Fri, Feb 21, 2014 at 9:01 AM, Matthias Wessendorf wrote: > >> Hey Miguel, >> >> we had an intern working on a PHP client, last year >> >> here is is project: >> https://github.com/tmccarthy9/aerogear-unified-push-php-client >> >> I know he has been testing it against our server - perhaps that library >> is handy for you ? >> >> Btw. if you feel to make changes to the given PHP client, feel free to >> send PullRequests against the repo, we will be able to merge them >> >> -Matthias >> >> >> >> >> On Fri, Feb 21, 2014 at 9:54 AM, Miguel Lemos wrote: >> >>> Hi! >>> >>> I'm trying to create a php batch to test faster my notifications. So I >>> did this (simplified example): >>> >>> $ch = curl_init('https://aerogear-metalpush.rhcloud.com/rest/sender'); >>> >>> $data = array( >>> 'message' => array( >>> 'atl' => 'Aviso', >>> 'avs' => 'Mensagem', >>> 'badge' => '1' >>> ) >>> ); >>> >>> $data_st = json_encode($data); >>> $headers = array("Accept: application/json", "Content-Type: >>> application/json"); >>> curl_setopt($ch, CURLOPT_CONNECTTIMEOUT, 6); >>> curl_setopt($ch, CURLOPT_CUSTOMREQUEST, "POST"); >>> curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false); >>> curl_setopt($ch, CURLOPT_RETURNTRANSFER, true); >>> curl_setopt($ch, CURLOPT_USERPWD, "$key:$secret"); >>> curl_setopt($ch, CURLOPT_HTTPHEADER, >>> $headers); >>> curl_setopt($ch, CURLOPT_POSTFIELDS, $data_st); >>> >>> $result = curl_exec($ch); >>> >>> I think that's something wrong with the $data array because the server >>> returns: " >>> *The request sent by the client was syntactically incorrect (). * >>> >>> If I strip the string from the "message" it returns "job submitted", >>> but of course I don't receive nothing. >>> >>> Thanks again >>> >>> M >>> >>> >>> >>> >>> On Thu, Feb 20, 2014 at 8:48 AM, Sebastien Blanc wrote: >>> >>>> This is really cool Miguel ! >>>> Don't hesitate to ask us other questions and also , like you did with >>>> your screenshot, give us feedback ! >>>> Thanks again for your interest in the project. >>>> Sebi >>>> >>>> >>>> >>>> On Thu, Feb 20, 2014 at 9:43 AM, Miiguel Lemos wrote: >>>> >>>>> Not all, but a couple of steps on the right direction, I hope ;-) >>>>> >>>>> Enviado do meu iPad >>>>> >>>>> No dia 19/02/2014, ?s 21:20, Matthias Wessendorf >>>>> escreveu: >>>>> >>>>> Nice! >>>>> >>>>> Glad you are all set! >>>>> >>>>> -Matthias >>>>> >>>>> >>>>> On Wed, Feb 19, 2014 at 4:38 PM, Miguel Lemos wrote: >>>>> >>>>>> A small souvenir ;-) >>>>>> >>>>>> Thanks again >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Wed, Feb 19, 2014 at 3:20 PM, Miguel Lemos wrote: >>>>>> >>>>>>> Hi Matthias, >>>>>>> >>>>>>> Maybe I didn't make myself clear, but your answer was clear enough >>>>>>> to respond to my post :-) >>>>>>> >>>>>>> Thanks again. >>>>>>> >>>>>>> Carry on! >>>>>>> >>>>>>> M >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Wed, Feb 19, 2014 at 3:05 PM, Matthias Wessendorf < >>>>>>> matzew at apache.org> wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Feb 19, 2014 at 3:43 PM, Miguel Lemos >>>>>>> > wrote: >>>>>>>> >>>>>>>>> Dear Matthias, >>>>>>>>> >>>>>>>>> According to the information posted in the url below, I can send >>>>>>>>> (and read) several parameters / keys in the scope of the notification >>>>>>>>> service (as it should be...): >>>>>>>>> >>>>>>>>> http://aerogear.org/docs/specs/aerogear-push-messages/ >>>>>>>>> >>>>>>>>> According to the values on it, the receiver should have the >>>>>>>>> capacity to decide what to do next. >>>>>>>>> >>>>>>>>> First, and the easiest thing: don't show the "Alert" text, but >>>>>>>>> any other part of content received and / or change "Alert" to another >>>>>>>>> language, for instance. >>>>>>>>> >>>>>>>> >>>>>>>> Not sure I follow. >>>>>>>> >>>>>>>> The 'alert' is a keyword on iOS, which our server (and our Cordova >>>>>>>> Libs) do recognize. What do you want to change there ? >>>>>>>> For the completion of our spec, we are showing all of the keywords, >>>>>>>> that are supported. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> Second, if I create (for instance) a lat, lon and rad parameters, >>>>>>>>> I can decide if I show the notification immediately, or only when the user >>>>>>>>> reaches a matchable location, within a given radius. >>>>>>>>> This is just an example of the freedom that must be available to >>>>>>>>> decide what to do according to a given parameter that the software on the >>>>>>>>> client's side can interpret. The message itself may not be the most >>>>>>>>> important part of the whole thing... >>>>>>>>> >>>>>>>> >>>>>>>> If you don't want or need that alert, simply leave it our of the >>>>>>>> payload. It's just part of the demo/docs as that is quite handy to get >>>>>>>> going. >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> So, the question is: how can I read those parameters / keys before >>>>>>>>> deciding to do with the notification? Through a "regular" object keys >>>>>>>>> iterator? Thank you very much again. If there's some place in the >>>>>>>>> documentation where I can understand that, please let me know. >>>>>>>>> >>>>>>>> >>>>>>>> yes, like here (using alert just as an example): >>>>>>>> >>>>>>>> >>>>>>>> function onNotification(e) { >>>>>>>> alert(e.payload.foo); >>>>>>>> alert(e.payload.key); >>>>>>>> } >>>>>>>> >>>>>>>> And the curl for that would be something _like_ this: >>>>>>>> curl -3 -u "ID:secrect" -v -H "Accept: application/json" -H >>>>>>>> "Content-type: application/json" -X POST -d '{"message": {"foo":"bar >>>>>>>> value", "key":"HELLO"}}' >>>>>>>> https://something-doamin.rhcloud.com/rest/sender >>>>>>>> >>>>>>>> >>>>>>>> -Matthias >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Miguel >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, Feb 19, 2014 at 1:34 PM, Matthias Wessendorf < >>>>>>>>> matzew at apache.org> wrote: >>>>>>>>> >>>>>>>>>> Awesome, >>>>>>>>>> >>>>>>>>>> we are interested in hearing your feedback. >>>>>>>>>> >>>>>>>>>> Good luck w/ the development process! >>>>>>>>>> >>>>>>>>>> -Matthias >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Wed, Feb 19, 2014 at 2:29 PM, Miguel Lemos < >>>>>>>>>> miguel21op at gmail.com> wrote: >>>>>>>>>> >>>>>>>>>>> Thanks. Of course I'll give you my feedback ;-) >>>>>>>>>>> >>>>>>>>>>> I've some questions about the service as a whole, but I'll make >>>>>>>>>>> some more testing and then I'll let you know. >>>>>>>>>>> >>>>>>>>>>> Thank you very much again for your attention. >>>>>>>>>>> >>>>>>>>>>> All the best, >>>>>>>>>>> >>>>>>>>>>> Miguel >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Wed, Feb 19, 2014 at 1:25 PM, Matthias Wessendorf < >>>>>>>>>>> matzew at apache.org> wrote: >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Wed, Feb 19, 2014 at 2:18 PM, Miguel Lemos < >>>>>>>>>>>> miguel21op at gmail.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Hi Matthias, >>>>>>>>>>>>> >>>>>>>>>>>>> One of the biggest reasons I'm testing this solutions is >>>>>>>>>>>>> because iOS! >>>>>>>>>>>>> >>>>>>>>>>>>> Once we already developed a full native Android push >>>>>>>>>>>>> (considering geofencing) notification service. The issue is to port our >>>>>>>>>>>>> solution to iOS (not only the notifications, but everything). That's why >>>>>>>>>>>>> I'm personally testing Cordova on Android and already partially on IOS. So >>>>>>>>>>>>> far so good.. >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Sounds very interesting. If you are interested, let us know how >>>>>>>>>>>> it goes. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> I'm starting with Android because it's easier to me. But next >>>>>>>>>>>>> week I want to test your solution with iOS. Why? Is there any problem? >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> No problem there at all :-) I was just curious if you target >>>>>>>>>>>> Android first/only. >>>>>>>>>>>> >>>>>>>>>>>> Greetings, >>>>>>>>>>>> Matthias >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks >>>>>>>>>>>>> >>>>>>>>>>>>> Miguel >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Wed, Feb 19, 2014 at 1:04 PM, Matthias Wessendorf < >>>>>>>>>>>>> matzew at apache.org> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Wed, Feb 19, 2014 at 1:20 PM, Miguel Lemos < >>>>>>>>>>>>>> miguel21op at gmail.com> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi all, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I tested and now it works, thanks. >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> glad it all worked out >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> When I tried for the first time, I tried with the function >>>>>>>>>>>>>>> global, reflecting the Github example. But as it didn't work (because of >>>>>>>>>>>>>>> the "damn" URL issue...) I tried several things, one of them being put the >>>>>>>>>>>>>>> alert function inside the deviceready event. Of course, when I solved the >>>>>>>>>>>>>>> URL thing I never more remembered to put it outside again... >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Things like that might happen. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Regarding the URL, we will try to update the OpenShift blog >>>>>>>>>>>>>> post. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I just checkout project documentation, and it looks like they >>>>>>>>>>>>>> are already 'right'. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Wondering: Are you building Cordova clients for Android only, >>>>>>>>>>>>>> or do you plan to use the iOS platform as well ? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Greetings, >>>>>>>>>>>>>> Matthias >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>> 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 >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> 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 >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>> >>>> >>>> >>>> _______________________________________________ >>>> 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/20140221/bc92626f/attachment-0001.html From miguel21op at gmail.com Fri Feb 21 04:27:09 2014 From: miguel21op at gmail.com (Miguel Lemos) Date: Fri, 21 Feb 2014 09:27:09 +0000 Subject: [aerogear-dev] Issues with Aerogear on Cordova In-Reply-To: References: Message-ID: <3F10F3EC-EDF2-455C-94D3-ADE15B7C9AD5@gmail.com> Yes. I think it's only a small thing about the structure of the json data I'm sending... Enviado do meu iPhone No dia 21/02/2014, ?s 09:17, Matthias Wessendorf escreveu: > Oh - I just see the PHP client supports some sort of older API we used to have in the past: > > https://github.com/tmccarthy9/aerogear-unified-push-php-client/blob/master/src/SenderClient.php#L103 > > Since the intern left, nobody was actually paying too much attention on the PHP client - we are mostly Java Weenies :) > > > >> On Fri, Feb 21, 2014 at 10:10 AM, Miguel Lemos wrote: >> OK. I'll give it a try. In any case can someone explain what's wrong with my string? I think that's the only problem. >> >> Thanks again for the swift response. >> >> M >> >> >>> On Fri, Feb 21, 2014 at 9:01 AM, Matthias Wessendorf wrote: >>> Hey Miguel, >>> >>> we had an intern working on a PHP client, last year >>> >>> here is is project: >>> https://github.com/tmccarthy9/aerogear-unified-push-php-client >>> >>> I know he has been testing it against our server - perhaps that library is handy for you ? >>> >>> Btw. if you feel to make changes to the given PHP client, feel free to send PullRequests against the repo, we will be able to merge them >>> >>> -Matthias >>> >>> >>> >>> >>>> On Fri, Feb 21, 2014 at 9:54 AM, Miguel Lemos wrote: >>>> Hi! >>>> >>>> I'm trying to create a php batch to test faster my notifications. So I did this (simplified example): >>>> >>>> $ch = curl_init('https://aerogear-metalpush.rhcloud.com/rest/sender'); >>>> >>>> $data = array( >>>> 'message' => array( >>>> 'atl' => 'Aviso', >>>> 'avs' => 'Mensagem', >>>> 'badge' => '1' >>>> ) >>>> ); >>>> >>>> $data_st = json_encode($data); >>>> $headers = array("Accept: application/json", "Content-Type: application/json"); >>>> curl_setopt($ch, CURLOPT_CONNECTTIMEOUT, 6); >>>> curl_setopt($ch, CURLOPT_CUSTOMREQUEST, "POST"); >>>> curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false); >>>> curl_setopt($ch, CURLOPT_RETURNTRANSFER, true); >>>> curl_setopt($ch, CURLOPT_USERPWD, "$key:$secret"); >>>> curl_setopt($ch, CURLOPT_HTTPHEADER, $headers); >>>> curl_setopt($ch, CURLOPT_POSTFIELDS, $data_st); >>>> >>>> $result = curl_exec($ch); >>>> >>>> I think that's something wrong with the $data array because the server returns: " The request sent by the client was syntactically incorrect (). >>>> >>>> If I strip the string from the "message" it returns "job submitted", but of course I don't receive nothing. >>>> >>>> Thanks again >>>> >>>> M >>>> >>>> >>>> >>>> >>>>> On Thu, Feb 20, 2014 at 8:48 AM, Sebastien Blanc wrote: >>>>> This is really cool Miguel ! >>>>> Don't hesitate to ask us other questions and also , like you did with your screenshot, give us feedback ! >>>>> Thanks again for your interest in the project. >>>>> Sebi >>>>> >>>>> >>>>> >>>>>> On Thu, Feb 20, 2014 at 9:43 AM, Miiguel Lemos wrote: >>>>>> Not all, but a couple of steps on the right direction, I hope ;-) >>>>>> >>>>>> Enviado do meu iPad >>>>>> >>>>>> No dia 19/02/2014, ?s 21:20, Matthias Wessendorf escreveu: >>>>>> >>>>>>> Nice! >>>>>>> >>>>>>> Glad you are all set! >>>>>>> >>>>>>> -Matthias >>>>>>> >>>>>>> >>>>>>>> On Wed, Feb 19, 2014 at 4:38 PM, Miguel Lemos wrote: >>>>>>>> A small souvenir ;-) >>>>>>>> >>>>>>>> Thanks again >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> On Wed, Feb 19, 2014 at 3:20 PM, Miguel Lemos wrote: >>>>>>>>> Hi Matthias, >>>>>>>>> >>>>>>>>> Maybe I didn't make myself clear, but your answer was clear enough to respond to my post :-) >>>>>>>>> >>>>>>>>> Thanks again. >>>>>>>>> >>>>>>>>> Carry on! >>>>>>>>> >>>>>>>>> M >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> On Wed, Feb 19, 2014 at 3:05 PM, Matthias Wessendorf wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> On Wed, Feb 19, 2014 at 3:43 PM, Miguel Lemos wrote: >>>>>>>>>>> Dear Matthias, >>>>>>>>>>> >>>>>>>>>>> According to the information posted in the url below, I can send (and read) several parameters / keys in the scope of the notification service (as it should be...): >>>>>>>>>>> >>>>>>>>>>> http://aerogear.org/docs/specs/aerogear-push-messages/ >>>>>>>>>>> >>>>>>>>>>> According to the values on it, the receiver should have the capacity to decide what to do next. >>>>>>>>>>> >>>>>>>>>>> First, and the easiest thing: don't show the "Alert" text, but any other part of content received and / or change "Alert" to another language, for instance. >>>>>>>>>> >>>>>>>>>> Not sure I follow. >>>>>>>>>> >>>>>>>>>> The 'alert' is a keyword on iOS, which our server (and our Cordova Libs) do recognize. What do you want to change there ? >>>>>>>>>> For the completion of our spec, we are showing all of the keywords, that are supported. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Second, if I create (for instance) a lat, lon and rad parameters, I can decide if I show the notification immediately, or only when the user reaches a matchable location, within a given radius. >>>>>>>>>>> This is just an example of the freedom that must be available to decide what to do according to a given parameter that the software on the client's side can interpret. The message itself may not be the most important part of the whole thing... >>>>>>>>>> >>>>>>>>>> If you don't want or need that alert, simply leave it our of the payload. It's just part of the demo/docs as that is quite handy to get going. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> So, the question is: how can I read those parameters / keys before deciding to do with the notification? Through a "regular" object keys iterator? Thank you very much again. If there's some place in the documentation where I can understand that, please let me know. >>>>>>>>>> >>>>>>>>>> yes, like here (using alert just as an example): >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> function onNotification(e) { >>>>>>>>>> alert(e.payload.foo); >>>>>>>>>> alert(e.payload.key); >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> And the curl for that would be something _like_ this: >>>>>>>>>> curl -3 -u "ID:secrect" -v -H "Accept: application/json" -H "Content-type: application/json" -X POST -d '{"message": {"foo":"bar value", "key":"HELLO"}}' https://something-doamin.rhcloud.com/rest/sender >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -Matthias >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Miguel >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> On Wed, Feb 19, 2014 at 1:34 PM, Matthias Wessendorf wrote: >>>>>>>>>>>> Awesome, >>>>>>>>>>>> >>>>>>>>>>>> we are interested in hearing your feedback. >>>>>>>>>>>> >>>>>>>>>>>> Good luck w/ the development process! >>>>>>>>>>>> >>>>>>>>>>>> -Matthias >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> On Wed, Feb 19, 2014 at 2:29 PM, Miguel Lemos wrote: >>>>>>>>>>>>> Thanks. Of course I'll give you my feedback ;-) >>>>>>>>>>>>> >>>>>>>>>>>>> I've some questions about the service as a whole, but I'll make some more testing and then I'll let you know. >>>>>>>>>>>>> >>>>>>>>>>>>> Thank you very much again for your attention. >>>>>>>>>>>>> >>>>>>>>>>>>> All the best, >>>>>>>>>>>>> >>>>>>>>>>>>> Miguel >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> On Wed, Feb 19, 2014 at 1:25 PM, Matthias Wessendorf wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Wed, Feb 19, 2014 at 2:18 PM, Miguel Lemos wrote: >>>>>>>>>>>>>>> Hi Matthias, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> One of the biggest reasons I'm testing this solutions is because iOS! >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Once we already developed a full native Android push (considering geofencing) notification service. The issue is to port our solution to iOS (not only the notifications, but everything). That's why I'm personally testing Cordova on Android and already partially on IOS. So far so good.. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Sounds very interesting. If you are interested, let us know how it goes. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I'm starting with Android because it's easier to me. But next week I want to test your solution with iOS. Why? Is there any problem? >>>>>>>>>>>>>> >>>>>>>>>>>>>> No problem there at all :-) I was just curious if you target Android first/only. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Greetings, >>>>>>>>>>>>>> Matthias >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Miguel >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Wed, Feb 19, 2014 at 1:04 PM, Matthias Wessendorf wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Wed, Feb 19, 2014 at 1:20 PM, Miguel Lemos wrote: >>>>>>>>>>>>>>>>> Hi all, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I tested and now it works, thanks. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> glad it all worked out >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> When I tried for the first time, I tried with the function global, reflecting the Github example. But as it didn't work (because of the "damn" URL issue...) I tried several things, one of them being put the alert function inside the deviceready event. Of course, when I solved the URL thing I never more remembered to put it outside again... >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Things like that might happen. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Regarding the URL, we will try to update the OpenShift blog post. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I just checkout project documentation, and it looks like they are already 'right'. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Wondering: Are you building Cordova clients for Android only, or do you plan to use the iOS platform as well ? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Greetings, >>>>>>>>>>>>>>>> Matthias >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>> >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> 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 >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> 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 >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140221/33a47f51/attachment-0001.html From miguel21op at gmail.com Fri Feb 21 04:28:53 2014 From: miguel21op at gmail.com (Miguel Lemos) Date: Fri, 21 Feb 2014 09:28:53 +0000 Subject: [aerogear-dev] Issues with Aerogear on Cordova In-Reply-To: References: Message-ID: <8C1E5C5E-8067-4253-AF5B-EFC313A5177F@gmail.com> Meanwhile can you send me a Java example? Thanks. Enviado do meu iPhone No dia 21/02/2014, ?s 09:17, Matthias Wessendorf escreveu: > Oh - I just see the PHP client supports some sort of older API we used to have in the past: > > https://github.com/tmccarthy9/aerogear-unified-push-php-client/blob/master/src/SenderClient.php#L103 > > Since the intern left, nobody was actually paying too much attention on the PHP client - we are mostly Java Weenies :) > > > >> On Fri, Feb 21, 2014 at 10:10 AM, Miguel Lemos wrote: >> OK. I'll give it a try. In any case can someone explain what's wrong with my string? I think that's the only problem. >> >> Thanks again for the swift response. >> >> M >> >> >>> On Fri, Feb 21, 2014 at 9:01 AM, Matthias Wessendorf wrote: >>> Hey Miguel, >>> >>> we had an intern working on a PHP client, last year >>> >>> here is is project: >>> https://github.com/tmccarthy9/aerogear-unified-push-php-client >>> >>> I know he has been testing it against our server - perhaps that library is handy for you ? >>> >>> Btw. if you feel to make changes to the given PHP client, feel free to send PullRequests against the repo, we will be able to merge them >>> >>> -Matthias >>> >>> >>> >>> >>>> On Fri, Feb 21, 2014 at 9:54 AM, Miguel Lemos wrote: >>>> Hi! >>>> >>>> I'm trying to create a php batch to test faster my notifications. So I did this (simplified example): >>>> >>>> $ch = curl_init('https://aerogear-metalpush.rhcloud.com/rest/sender'); >>>> >>>> $data = array( >>>> 'message' => array( >>>> 'atl' => 'Aviso', >>>> 'avs' => 'Mensagem', >>>> 'badge' => '1' >>>> ) >>>> ); >>>> >>>> $data_st = json_encode($data); >>>> $headers = array("Accept: application/json", "Content-Type: application/json"); >>>> curl_setopt($ch, CURLOPT_CONNECTTIMEOUT, 6); >>>> curl_setopt($ch, CURLOPT_CUSTOMREQUEST, "POST"); >>>> curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false); >>>> curl_setopt($ch, CURLOPT_RETURNTRANSFER, true); >>>> curl_setopt($ch, CURLOPT_USERPWD, "$key:$secret"); >>>> curl_setopt($ch, CURLOPT_HTTPHEADER, $headers); >>>> curl_setopt($ch, CURLOPT_POSTFIELDS, $data_st); >>>> >>>> $result = curl_exec($ch); >>>> >>>> I think that's something wrong with the $data array because the server returns: " The request sent by the client was syntactically incorrect (). >>>> >>>> If I strip the string from the "message" it returns "job submitted", but of course I don't receive nothing. >>>> >>>> Thanks again >>>> >>>> M >>>> >>>> >>>> >>>> >>>>> On Thu, Feb 20, 2014 at 8:48 AM, Sebastien Blanc wrote: >>>>> This is really cool Miguel ! >>>>> Don't hesitate to ask us other questions and also , like you did with your screenshot, give us feedback ! >>>>> Thanks again for your interest in the project. >>>>> Sebi >>>>> >>>>> >>>>> >>>>>> On Thu, Feb 20, 2014 at 9:43 AM, Miiguel Lemos wrote: >>>>>> Not all, but a couple of steps on the right direction, I hope ;-) >>>>>> >>>>>> Enviado do meu iPad >>>>>> >>>>>> No dia 19/02/2014, ?s 21:20, Matthias Wessendorf escreveu: >>>>>> >>>>>>> Nice! >>>>>>> >>>>>>> Glad you are all set! >>>>>>> >>>>>>> -Matthias >>>>>>> >>>>>>> >>>>>>>> On Wed, Feb 19, 2014 at 4:38 PM, Miguel Lemos wrote: >>>>>>>> A small souvenir ;-) >>>>>>>> >>>>>>>> Thanks again >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> On Wed, Feb 19, 2014 at 3:20 PM, Miguel Lemos wrote: >>>>>>>>> Hi Matthias, >>>>>>>>> >>>>>>>>> Maybe I didn't make myself clear, but your answer was clear enough to respond to my post :-) >>>>>>>>> >>>>>>>>> Thanks again. >>>>>>>>> >>>>>>>>> Carry on! >>>>>>>>> >>>>>>>>> M >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> On Wed, Feb 19, 2014 at 3:05 PM, Matthias Wessendorf wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> On Wed, Feb 19, 2014 at 3:43 PM, Miguel Lemos wrote: >>>>>>>>>>> Dear Matthias, >>>>>>>>>>> >>>>>>>>>>> According to the information posted in the url below, I can send (and read) several parameters / keys in the scope of the notification service (as it should be...): >>>>>>>>>>> >>>>>>>>>>> http://aerogear.org/docs/specs/aerogear-push-messages/ >>>>>>>>>>> >>>>>>>>>>> According to the values on it, the receiver should have the capacity to decide what to do next. >>>>>>>>>>> >>>>>>>>>>> First, and the easiest thing: don't show the "Alert" text, but any other part of content received and / or change "Alert" to another language, for instance. >>>>>>>>>> >>>>>>>>>> Not sure I follow. >>>>>>>>>> >>>>>>>>>> The 'alert' is a keyword on iOS, which our server (and our Cordova Libs) do recognize. What do you want to change there ? >>>>>>>>>> For the completion of our spec, we are showing all of the keywords, that are supported. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Second, if I create (for instance) a lat, lon and rad parameters, I can decide if I show the notification immediately, or only when the user reaches a matchable location, within a given radius. >>>>>>>>>>> This is just an example of the freedom that must be available to decide what to do according to a given parameter that the software on the client's side can interpret. The message itself may not be the most important part of the whole thing... >>>>>>>>>> >>>>>>>>>> If you don't want or need that alert, simply leave it our of the payload. It's just part of the demo/docs as that is quite handy to get going. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> So, the question is: how can I read those parameters / keys before deciding to do with the notification? Through a "regular" object keys iterator? Thank you very much again. If there's some place in the documentation where I can understand that, please let me know. >>>>>>>>>> >>>>>>>>>> yes, like here (using alert just as an example): >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> function onNotification(e) { >>>>>>>>>> alert(e.payload.foo); >>>>>>>>>> alert(e.payload.key); >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> And the curl for that would be something _like_ this: >>>>>>>>>> curl -3 -u "ID:secrect" -v -H "Accept: application/json" -H "Content-type: application/json" -X POST -d '{"message": {"foo":"bar value", "key":"HELLO"}}' https://something-doamin.rhcloud.com/rest/sender >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -Matthias >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Miguel >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> On Wed, Feb 19, 2014 at 1:34 PM, Matthias Wessendorf wrote: >>>>>>>>>>>> Awesome, >>>>>>>>>>>> >>>>>>>>>>>> we are interested in hearing your feedback. >>>>>>>>>>>> >>>>>>>>>>>> Good luck w/ the development process! >>>>>>>>>>>> >>>>>>>>>>>> -Matthias >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> On Wed, Feb 19, 2014 at 2:29 PM, Miguel Lemos wrote: >>>>>>>>>>>>> Thanks. Of course I'll give you my feedback ;-) >>>>>>>>>>>>> >>>>>>>>>>>>> I've some questions about the service as a whole, but I'll make some more testing and then I'll let you know. >>>>>>>>>>>>> >>>>>>>>>>>>> Thank you very much again for your attention. >>>>>>>>>>>>> >>>>>>>>>>>>> All the best, >>>>>>>>>>>>> >>>>>>>>>>>>> Miguel >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> On Wed, Feb 19, 2014 at 1:25 PM, Matthias Wessendorf wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Wed, Feb 19, 2014 at 2:18 PM, Miguel Lemos wrote: >>>>>>>>>>>>>>> Hi Matthias, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> One of the biggest reasons I'm testing this solutions is because iOS! >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Once we already developed a full native Android push (considering geofencing) notification service. The issue is to port our solution to iOS (not only the notifications, but everything). That's why I'm personally testing Cordova on Android and already partially on IOS. So far so good.. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Sounds very interesting. If you are interested, let us know how it goes. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I'm starting with Android because it's easier to me. But next week I want to test your solution with iOS. Why? Is there any problem? >>>>>>>>>>>>>> >>>>>>>>>>>>>> No problem there at all :-) I was just curious if you target Android first/only. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Greetings, >>>>>>>>>>>>>> Matthias >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Miguel >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Wed, Feb 19, 2014 at 1:04 PM, Matthias Wessendorf wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Wed, Feb 19, 2014 at 1:20 PM, Miguel Lemos wrote: >>>>>>>>>>>>>>>>> Hi all, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I tested and now it works,