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>
	<CAAg5f2T=z1kSSRHOu7cDjWhSKMybGJ7-OJs23z8+191zsnj29w@mail.gmail.com>
	<52EA7A28.1050404@redhat.com>
Message-ID: <20140203094941.4161d323@kapy-ntb-x220>

On Thu, 30 Jan 2014 11:13:28 -0500
Summers Pittman <supittma at redhat.com> wrote:

> On 01/30/2014 11:03 AM, Matthias Wessendorf wrote:
> >
> >
> >
> > On Thu, Jan 30, 2014 at 4:23 PM, Summers Pittman <supittma at redhat.com 
> > <mailto:supittma at redhat.com>> 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: <CAFJm-3HXr5cWjDV2jksdR_KmMqA4dbG1KRByXWv530n8LunjbQ@mail.gmail.com>

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>
	<C8F4F8C2-B7EA-4CEA-AC25-0059E02F4FC0@redhat.com>
	<20140131204202.GG61817@rohan.local>
Message-ID: <DE298E9A-BB5A-4622-9EF2-60C1B7E004F7@redhat.com>


On Jan 31, 2014, at 3:42 PM, Douglas Campos <qmx at qmx.me> wrote:

> On Tue, Jan 28, 2014 at 02:13:05PM -0500, Lucas Holmquist wrote:
>> 
>> On Jan 28, 2014, at 2:08 PM, Douglas Campos <qmx at qmx.me> 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: <BDFD0219-F9AA-4E90-8D80-D7CFAD7536EC@redhat.com>


On Feb 1, 2014, at 4:08 PM, Douglas Campos <qmx at qmx.me> 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: <CAAg5f2S-E=dLWiqCQS7Vj0sw9+_C=2yrW2Fbiiph6iis7KP9-w@mail.gmail.com>
References: <52EA3687.2050601@redhat.com>	<CAAg5f2S2fQCA_LYf9kdTvUPmrgRD=PUHsFbu5-d-FrZ9LzQN4g@mail.gmail.com>	<52EA39C6.8020607@redhat.com>
	<CAAg5f2S-E=dLWiqCQS7Vj0sw9+_C=2yrW2Fbiiph6iis7KP9-w@mail.gmail.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 <hbons at redhat.com 
> <mailto:hbons at redhat.com>> 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 <hbons at redhat.com
>>     <mailto:hbons at redhat.com>> 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
>>         <mailto: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  <mailto:aerogear-dev at lists.jboss.org>
>>     https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>     _______________________________________________
>     aerogear-dev mailing list
>     aerogear-dev at lists.jboss.org <mailto: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: <C107AC74-8FE7-45AA-8E75-7EC892F4BAA5@redhat.com>	<2A4CF6B8-B8DD-4E31-B764-C7452CD99D19@redhat.com>	<20140120123559.3a3aec13@kapy-ntb-x220>	<CAD_dpu0t+mqTH2y7iWMwmhW1R-qx1jAEo85sWzhNrSQ2T+UWbA@mail.gmail.com>	<B5C2318A-94B2-438D-BE4A-19C838425F0D@gmail.com>	<52DE6B7B.6050202@redhat.com>	<20140122130302.233deb81@kapy-ntb-x220>	<A0DEAE4B-C521-4844-8344-C486A75C6C66@gmail.com>	<52DFC3ED.2060405@redhat.com>	<F40B7BBA-D8B2-44FF-BAD7-F313A8F216F3@gmail.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>	<CAAg5f2S2fQCA_LYf9kdTvUPmrgRD=PUHsFbu5-d-FrZ9LzQN4g@mail.gmail.com>	<52EA39C6.8020607@redhat.com>
	<CAAg5f2S-E=dLWiqCQS7Vj0sw9+_C=2yrW2Fbiiph6iis7KP9-w@mail.gmail.com>
	<52EF9D46.6000306@redhat.com>
Message-ID: <953401D5-1AA2-44BB-8240-859183299450@redhat.com>


On Feb 3, 2014, at 8:44 AM, Hylke Bons <hbons at redhat.com> 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 <hbons at redhat.com> 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 <hbons at redhat.com> 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>
	<CAAg5f2S2fQCA_LYf9kdTvUPmrgRD=PUHsFbu5-d-FrZ9LzQN4g@mail.gmail.com>
	<52EA39C6.8020607@redhat.com>
	<CAAg5f2S-E=dLWiqCQS7Vj0sw9+_C=2yrW2Fbiiph6iis7KP9-w@mail.gmail.com>
	<52EF9D46.6000306@redhat.com>
	<953401D5-1AA2-44BB-8240-859183299450@redhat.com>
Message-ID: <CAAg5f2Q=krkMe0U2Ra51PyZTQi_qCiO1RZ0DyYYCZtUE8RDgKA@mail.gmail.com>

On Mon, Feb 3, 2014 at 2:52 PM, Lucas Holmquist <lholmqui at redhat.com> wrote:

>
> On Feb 3, 2014, at 8:44 AM, Hylke Bons <hbons at redhat.com> 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 <hbons at redhat.com> 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 <hbons at redhat.com> 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>	<CAAg5f2S2fQCA_LYf9kdTvUPmrgRD=PUHsFbu5-d-FrZ9LzQN4g@mail.gmail.com>	<52EA39C6.8020607@redhat.com>	<CAAg5f2S-E=dLWiqCQS7Vj0sw9+_C=2yrW2Fbiiph6iis7KP9-w@mail.gmail.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 <hbons at redhat.com 
> <mailto:hbons at redhat.com>> 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 <hbons at redhat.com 
>>> <mailto:hbons at redhat.com>> 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 <hbons at redhat.com
>>>>     <mailto:hbons at redhat.com>> 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
>>>>         <mailto: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  <mailto:aerogear-dev at lists.jboss.org>
>>>>     https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>>
>>>     _______________________________________________
>>>     aerogear-dev mailing list
>>>     aerogear-dev at lists.jboss.org <mailto: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 <mailto:aerogear-dev at lists.jboss.org>
>> https://lists.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: <C107AC74-8FE7-45AA-8E75-7EC892F4BAA5@redhat.com>
	<2A4CF6B8-B8DD-4E31-B764-C7452CD99D19@redhat.com>
	<20140120123559.3a3aec13@kapy-ntb-x220>
	<CAD_dpu0t+mqTH2y7iWMwmhW1R-qx1jAEo85sWzhNrSQ2T+UWbA@mail.gmail.com>
	<B5C2318A-94B2-438D-BE4A-19C838425F0D@gmail.com>
	<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: <C107AC74-8FE7-45AA-8E75-7EC892F4BAA5@redhat.com>
	<2A4CF6B8-B8DD-4E31-B764-C7452CD99D19@redhat.com>
	<20140120123559.3a3aec13@kapy-ntb-x220>
	<CAD_dpu0t+mqTH2y7iWMwmhW1R-qx1jAEo85sWzhNrSQ2T+UWbA@mail.gmail.com>
	<B5C2318A-94B2-438D-BE4A-19C838425F0D@gmail.com>
	<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 <hbons at redhat.com> 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 <supittma at redhat.com> 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: <CAFJm-3FCDNPmfHkJXzC6JAOx=HKhZ1k6qdo62BSZkZrDkdd7Zg@mail.gmail.com>

Just catching up on all this, but I think this looks good.


On 3 February 2014 15:33, Lucas Holmquist <lholmqui at redhat.com> wrote:

>
> On Feb 3, 2014, at 9:27 AM, Summers Pittman <supittma at redhat.com> 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: <CAFJm-3FCDNPmfHkJXzC6JAOx=HKhZ1k6qdo62BSZkZrDkdd7Zg@mail.gmail.com>
References: <52EFA76E.3000106@redhat.com>
	<91EE6BCE-B105-46D0-9D75-4B6E8D2ECBFC@redhat.com>
	<CAFJm-3FCDNPmfHkJXzC6JAOx=HKhZ1k6qdo62BSZkZrDkdd7Zg@mail.gmail.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 <lholmqui at redhat.com
> <mailto:lholmqui at redhat.com>> wrote:
>
>
>     On Feb 3, 2014, at 9:27 AM, Summers Pittman <supittma at redhat.com
>     <mailto:supittma at redhat.com>> 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 <mailto:aerogear-dev at lists.jboss.org>
>     > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>     _______________________________________________
>     aerogear-dev mailing list
>     aerogear-dev at lists.jboss.org <mailto:aerogear-dev at lists.jboss.org>
>     https://lists.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>
	<CAFJm-3FCDNPmfHkJXzC6JAOx=HKhZ1k6qdo62BSZkZrDkdd7Zg@mail.gmail.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>
	<CAFJm-3FCDNPmfHkJXzC6JAOx=HKhZ1k6qdo62BSZkZrDkdd7Zg@mail.gmail.com>
	<52EFAB66.4020707@redhat.com>
Message-ID: <0C68E922-30E5-4E68-A4F4-E20B1F2BA0A6@gmail.com>


On 03 Feb 2014, at 15:44, Summers Pittman <supittma at redhat.com> 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 <lholmqui at redhat.com
>> <mailto:lholmqui at redhat.com>> wrote:
>> 
>> 
>>    On Feb 3, 2014, at 9:27 AM, Summers Pittman <supittma at redhat.com
>>    <mailto:supittma at redhat.com>> 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 <mailto:aerogear-dev at lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>> 
>> 
>>    _______________________________________________
>>    aerogear-dev mailing list
>>    aerogear-dev at lists.jboss.org <mailto:aerogear-dev at lists.jboss.org>
>>    https://lists.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>
	<CAFJm-3FCDNPmfHkJXzC6JAOx=HKhZ1k6qdo62BSZkZrDkdd7Zg@mail.gmail.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>	<CAFJm-3FCDNPmfHkJXzC6JAOx=HKhZ1k6qdo62BSZkZrDkdd7Zg@mail.gmail.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 <supittma at redhat.com> 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 <lholmqui at redhat.com
>>> <mailto:lholmqui at redhat.com>> wrote:
>>>
>>>
>>>     On Feb 3, 2014, at 9:27 AM, Summers Pittman <supittma at redhat.com
>>>     <mailto:supittma at redhat.com>> 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 <mailto:aerogear-dev at lists.jboss.org>
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>>     _______________________________________________
>>>     aerogear-dev mailing list
>>>     aerogear-dev at lists.jboss.org <mailto:aerogear-dev at lists.jboss.org>
>>>     https://lists.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: <BDFD0219-F9AA-4E90-8D80-D7CFAD7536EC@redhat.com>
References: <20140201210800.GM61817@rohan.local>
	<BDFD0219-F9AA-4E90-8D80-D7CFAD7536EC@redhat.com>
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 <qmx at qmx.me> 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>
	<BDFD0219-F9AA-4E90-8D80-D7CFAD7536EC@redhat.com>
	<20140203145830.GF75920@rohan.local>
Message-ID: <C8DCAEC6-B626-4407-9313-6A11CC43F7A8@redhat.com>


On Feb 3, 2014, at 9:58 AM, Douglas Campos <qmx at qmx.me> wrote:

> On Mon, Feb 03, 2014 at 08:40:49AM -0500, Lucas Holmquist wrote:
>> 
>> On Feb 1, 2014, at 4:08 PM, Douglas Campos <qmx at qmx.me> 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: <CAAg5f2RTdtxoDhk1uk0My_NWT7cLdjya7jaHpE5sPKpcoMr00Q@mail.gmail.com>

On Mon, Feb 3, 2014 at 3:27 PM, Summers Pittman <supittma at redhat.com> 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>
	<CAFJm-3FCDNPmfHkJXzC6JAOx=HKhZ1k6qdo62BSZkZrDkdd7Zg@mail.gmail.com>
	<52EFAB66.4020707@redhat.com> <20140203145202.GE75920@rohan.local>
Message-ID: <CAAg5f2RkdicsmqQi6HQdL3LqWGt=0pNYEMQ4q=A7J6sy7Qoc5A@mail.gmail.com>

On Mon, Feb 3, 2014 at 3:52 PM, Douglas Campos <qmx at qmx.me> 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: <CAFJm-3HXr5cWjDV2jksdR_KmMqA4dbG1KRByXWv530n8LunjbQ@mail.gmail.com>
References: <CAFJm-3HXr5cWjDV2jksdR_KmMqA4dbG1KRByXWv530n8LunjbQ@mail.gmail.com>
Message-ID: <20140203152912.GG75920@rohan.local>

[13:28:18]  <jbott>	 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]  <jbott>	 Minutes:        http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-02-03-15.05.html
[13:28:18]  <jbott>	 Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-02-03-15.05.txt
[13:28:18]  <jbott>	 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: <CAFJm-3HXr5cWjDV2jksdR_KmMqA4dbG1KRByXWv530n8LunjbQ@mail.gmail.com>
	<20140203152912.GG75920@rohan.local>
Message-ID: <CAAg5f2S1fw0DJM3L7aTVZChiQO63UHBszaZfaVxpJGc3fhipUA@mail.gmail.com>

yay - meeting logs :-)

thanks for sharing


On Mon, Feb 3, 2014 at 4:29 PM, Douglas Campos <qmx at qmx.me> wrote:

> [13:28:18]  <jbott>      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]  <jbott>      Minutes:
> http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-02-03-15.05.html
> [13:28:18]  <jbott>      Minutes (text):
> http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-02-03-15.05.txt
> [13:28:18]  <jbott>      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: <CAAg5f2RTdtxoDhk1uk0My_NWT7cLdjya7jaHpE5sPKpcoMr00Q@mail.gmail.com>
References: <52EFA76E.3000106@redhat.com>
	<CAAg5f2RTdtxoDhk1uk0My_NWT7cLdjya7jaHpE5sPKpcoMr00Q@mail.gmail.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 <supittma at redhat.com 
> <mailto:supittma at redhat.com>> 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 <mailto: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>
	<CAAg5f2RTdtxoDhk1uk0My_NWT7cLdjya7jaHpE5sPKpcoMr00Q@mail.gmail.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 <supittma at redhat.com> wrote:

> On 02/03/2014 10:28 AM, Matthias Wessendorf wrote:
>> 
>> 
>> 
>> On Mon, Feb 3, 2014 at 3:27 PM, Summers Pittman <supittma at redhat.com> 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>
	<CAAg5f2RTdtxoDhk1uk0My_NWT7cLdjya7jaHpE5sPKpcoMr00Q@mail.gmail.com>
	<52EFB6EC.6080406@redhat.com>
Message-ID: <CAAg5f2ToWdi3h0X1vNWd4e3M9UcBCN=VcUvVBF9rTgNVRGomXA@mail.gmail.com>

On Mon, Feb 3, 2014 at 4:34 PM, Summers Pittman <supittma at redhat.com> wrote:

>  On 02/03/2014 10:28 AM, Matthias Wessendorf wrote:
>
>
>
>
> On Mon, Feb 3, 2014 at 3:27 PM, Summers Pittman <supittma at redhat.com>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: <CAAg5f2ToWdi3h0X1vNWd4e3M9UcBCN=VcUvVBF9rTgNVRGomXA@mail.gmail.com>
References: <52EFA76E.3000106@redhat.com>
	<CAAg5f2RTdtxoDhk1uk0My_NWT7cLdjya7jaHpE5sPKpcoMr00Q@mail.gmail.com>
	<52EFB6EC.6080406@redhat.com>
	<CAAg5f2ToWdi3h0X1vNWd4e3M9UcBCN=VcUvVBF9rTgNVRGomXA@mail.gmail.com>
Message-ID: <CE82B032-BA90-4D3A-BFD6-C3EFD55FC214@redhat.com>


On Feb 3, 2014, at 10:50 AM, Matthias Wessendorf <matzew at apache.org> wrote:

> 
> 
> 
> On Mon, Feb 3, 2014 at 4:34 PM, Summers Pittman <supittma at redhat.com> wrote:
> On 02/03/2014 10:28 AM, Matthias Wessendorf wrote:
>> 
>> 
>> 
>> On Mon, Feb 3, 2014 at 3:27 PM, Summers Pittman <supittma at redhat.com> 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: <CE82B032-BA90-4D3A-BFD6-C3EFD55FC214@redhat.com>
References: <52EFA76E.3000106@redhat.com>
	<CAAg5f2RTdtxoDhk1uk0My_NWT7cLdjya7jaHpE5sPKpcoMr00Q@mail.gmail.com>
	<52EFB6EC.6080406@redhat.com>
	<CAAg5f2ToWdi3h0X1vNWd4e3M9UcBCN=VcUvVBF9rTgNVRGomXA@mail.gmail.com>
	<CE82B032-BA90-4D3A-BFD6-C3EFD55FC214@redhat.com>
Message-ID: <6267A8E7-AE48-4A2E-9156-8D246FE3806F@gmail.com>


On 03 Feb 2014, at 16:52, Lucas Holmquist <lholmqui at redhat.com> wrote:

> 
> On Feb 3, 2014, at 10:50 AM, Matthias Wessendorf <matzew at apache.org> wrote:
> 
>> 
>> 
>> 
>> On Mon, Feb 3, 2014 at 4:34 PM, Summers Pittman <supittma at redhat.com> wrote:
>> On 02/03/2014 10:28 AM, Matthias Wessendorf wrote:
>>> 
>>> 
>>> 
>>> On Mon, Feb 3, 2014 at 3:27 PM, Summers Pittman <supittma at redhat.com> 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: <CE82B032-BA90-4D3A-BFD6-C3EFD55FC214@redhat.com>
References: <52EFA76E.3000106@redhat.com>	<CAAg5f2RTdtxoDhk1uk0My_NWT7cLdjya7jaHpE5sPKpcoMr00Q@mail.gmail.com>	<52EFB6EC.6080406@redhat.com>	<CAAg5f2ToWdi3h0X1vNWd4e3M9UcBCN=VcUvVBF9rTgNVRGomXA@mail.gmail.com>
	<CE82B032-BA90-4D3A-BFD6-C3EFD55FC214@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 <matzew at apache.org 
> <mailto:matzew at apache.org>> wrote:
>
>>
>>
>>
>> On Mon, Feb 3, 2014 at 4:34 PM, Summers Pittman <supittma at redhat.com 
>> <mailto:supittma at redhat.com>> wrote:
>>
>>     On 02/03/2014 10:28 AM, Matthias Wessendorf wrote:
>>>
>>>
>>>
>>>     On Mon, Feb 3, 2014 at 3:27 PM, Summers Pittman
>>>     <supittma at redhat.com <mailto:supittma at redhat.com>> 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
>>>         <mailto: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  <mailto:aerogear-dev at lists.jboss.org>
>>>     https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>
>>     _______________________________________________
>>     aerogear-dev mailing list
>>     aerogear-dev at lists.jboss.org <mailto: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 <mailto:aerogear-dev at lists.jboss.org>
>> https://lists.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: <C8DCAEC6-B626-4407-9313-6A11CC43F7A8@redhat.com>
References: <20140201210800.GM61817@rohan.local>
	<BDFD0219-F9AA-4E90-8D80-D7CFAD7536EC@redhat.com>
	<20140203145830.GF75920@rohan.local>
	<C8DCAEC6-B626-4407-9313-6A11CC43F7A8@redhat.com>
Message-ID: <3F959B90-1EAD-4455-BCD5-663801284DA2@redhat.com>


On Feb 3, 2014, at 10:06 AM, Lucas Holmquist <lholmqui at redhat.com> wrote:

> 
> On Feb 3, 2014, at 9:58 AM, Douglas Campos <qmx at qmx.me> wrote:
> 
>> On Mon, Feb 03, 2014 at 08:40:49AM -0500, Lucas Holmquist wrote:
>>> 
>>> On Feb 1, 2014, at 4:08 PM, Douglas Campos <qmx at qmx.me> 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>
	<CAAg5f2RTdtxoDhk1uk0My_NWT7cLdjya7jaHpE5sPKpcoMr00Q@mail.gmail.com>
	<52EFB6EC.6080406@redhat.com>
	<CAAg5f2ToWdi3h0X1vNWd4e3M9UcBCN=VcUvVBF9rTgNVRGomXA@mail.gmail.com>
	<CE82B032-BA90-4D3A-BFD6-C3EFD55FC214@redhat.com>
	<52EFBBFB.5060406@redhat.com>
Message-ID: <CAAg5f2QEpQtfXWn6zkwLb+G-x1Oj_7Bj7usyJzeaAQq9X3fmUw@mail.gmail.com>

On Mon, Feb 3, 2014 at 4:55 PM, Summers Pittman <supittma at redhat.com> wrote:

>  On 02/03/2014 10:52 AM, Lucas Holmquist wrote:
>
>
>  On Feb 3, 2014, at 10:50 AM, Matthias Wessendorf <matzew at apache.org>
> wrote:
>
>
>
>
> On Mon, Feb 3, 2014 at 4:34 PM, Summers Pittman <supittma at redhat.com>wrote:
>
>>  On 02/03/2014 10:28 AM, Matthias Wessendorf wrote:
>>
>>
>>
>>
>> On Mon, Feb 3, 2014 at 3:27 PM, Summers Pittman <supittma at redhat.com>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: <CAAg5f2RsDptcyjj2zExyPY+ftMNZPeoNDpniuA+spo0twMsOaA@mail.gmail.com>

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>
	<BDFD0219-F9AA-4E90-8D80-D7CFAD7536EC@redhat.com>
	<20140203145830.GF75920@rohan.local>
	<C8DCAEC6-B626-4407-9313-6A11CC43F7A8@redhat.com>
	<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: <CAAg5f2RsDptcyjj2zExyPY+ftMNZPeoNDpniuA+spo0twMsOaA@mail.gmail.com>
References: <CAAg5f2RsDptcyjj2zExyPY+ftMNZPeoNDpniuA+spo0twMsOaA@mail.gmail.com>
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 <matzew at apache.org> 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: <CAAg5f2RsDptcyjj2zExyPY+ftMNZPeoNDpniuA+spo0twMsOaA@mail.gmail.com>
References: <CAAg5f2RsDptcyjj2zExyPY+ftMNZPeoNDpniuA+spo0twMsOaA@mail.gmail.com>
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: <CAAg5f2RsDptcyjj2zExyPY+ftMNZPeoNDpniuA+spo0twMsOaA@mail.gmail.com>
	<099DA0A2-DD97-4C8F-90B8-665F20F98B19@redhat.com>
Message-ID: <CAAg5f2S=he---8bjma0EX+YVYsVPy5_JCRX0yeFeU0zDME2Xig@mail.gmail.com>

On Monday, February 3, 2014, Lucas Holmquist <lholmqui at redhat.com> 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 <matzew at apache.org<javascript:_e(%7B%7D,'cvml','matzew at apache.org');>>
> 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<javascript:_e(%7B%7D,'cvml','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: <CAAg5f2RsDptcyjj2zExyPY+ftMNZPeoNDpniuA+spo0twMsOaA@mail.gmail.com>
	<52EFDF71.5080404@gmail.com>
Message-ID: <CAAg5f2S8-R6mOp3_tzQQVa++9jr5t3muJyxbyKD+R6CoApWutw@mail.gmail.com>

On Monday, February 3, 2014, JR Conlin <jrconlin at gmail.com> 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 <javascript:_e(%7B%7D,'cvml','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/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: <CAAg5f2RsDptcyjj2zExyPY+ftMNZPeoNDpniuA+spo0twMsOaA@mail.gmail.com>
References: <CAAg5f2RsDptcyjj2zExyPY+ftMNZPeoNDpniuA+spo0twMsOaA@mail.gmail.com>
Message-ID: <CAD_dpu3nfve41zW=yeYmUi_hEj0We3kRRG7t4GEOGpDOzr86bQ@mail.gmail.com>

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 <matzew at apache.org>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: <CAAg5f2S=he---8bjma0EX+YVYsVPy5_JCRX0yeFeU0zDME2Xig@mail.gmail.com>
References: <CAAg5f2RsDptcyjj2zExyPY+ftMNZPeoNDpniuA+spo0twMsOaA@mail.gmail.com>	<099DA0A2-DD97-4C8F-90B8-665F20F98B19@redhat.com>
	<CAAg5f2S=he---8bjma0EX+YVYsVPy5_JCRX0yeFeU0zDME2Xig@mail.gmail.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 <lholmqui at redhat.com
> <mailto:lholmqui at redhat.com>> 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 <matzew at apache.org
>     <javascript:_e(%7B%7D,'cvml','matzew at apache.org');>> 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
>>     <javascript:_e(%7B%7D,'cvml','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: <CAAg5f2RsDptcyjj2zExyPY+ftMNZPeoNDpniuA+spo0twMsOaA@mail.gmail.com>
	<099DA0A2-DD97-4C8F-90B8-665F20F98B19@redhat.com>
	<CAAg5f2S=he---8bjma0EX+YVYsVPy5_JCRX0yeFeU0zDME2Xig@mail.gmail.com>
	<52EFE5CE.40209@gmail.com>
Message-ID: <CAAg5f2QPz5W2s5MUKzbZdV0k=t4uBzwyDF1A9c1D_yUcn1Y8Rg@mail.gmail.com>

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 <jrconlin at gmail.com> 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 <lholmqui at redhat.com<javascript:_e(%7B%7D,'cvml','lholmqui at redhat.com');>>
> 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 <matzew at apache.org>
>> 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 <javascript:_e(%7B%7D,'cvml','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/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: <CAAg5f2QPz5W2s5MUKzbZdV0k=t4uBzwyDF1A9c1D_yUcn1Y8Rg@mail.gmail.com>
References: <CAAg5f2RsDptcyjj2zExyPY+ftMNZPeoNDpniuA+spo0twMsOaA@mail.gmail.com>	<099DA0A2-DD97-4C8F-90B8-665F20F98B19@redhat.com>	<CAAg5f2S=he---8bjma0EX+YVYsVPy5_JCRX0yeFeU0zDME2Xig@mail.gmail.com>	<52EFE5CE.40209@gmail.com>
	<CAAg5f2QPz5W2s5MUKzbZdV0k=t4uBzwyDF1A9c1D_yUcn1Y8Rg@mail.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 <jrconlin at gmail.com
> <mailto:jrconlin at gmail.com>> 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 <lholmqui at redhat.com
>>     <javascript:_e(%7B%7D,'cvml','lholmqui at redhat.com');>> 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
>>         <matzew at apache.org> 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 <javascript:_e(%7B%7D,'cvml','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: <CAAg5f2RsDptcyjj2zExyPY+ftMNZPeoNDpniuA+spo0twMsOaA@mail.gmail.com>
	<099DA0A2-DD97-4C8F-90B8-665F20F98B19@redhat.com>
	<CAAg5f2S=he---8bjma0EX+YVYsVPy5_JCRX0yeFeU0zDME2Xig@mail.gmail.com>
	<52EFE5CE.40209@gmail.com>
	<CAAg5f2QPz5W2s5MUKzbZdV0k=t4uBzwyDF1A9c1D_yUcn1Y8Rg@mail.gmail.com>
	<52EFEB68.5010203@gmail.com>
Message-ID: <CAAg5f2SsOahGsHJ3UudS04Hpk9AYuNCmc4whf-_ZdmTM4f9tuw@mail.gmail.com>

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 <jrconlin at gmail.com> 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 <jrconlin at gmail.com> 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 <lholmqui at redhat.com> 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 <matzew at apache.org>
>>> 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: <CAAg5f2SsOahGsHJ3UudS04Hpk9AYuNCmc4whf-_ZdmTM4f9tuw@mail.gmail.com>
References: <CAAg5f2RsDptcyjj2zExyPY+ftMNZPeoNDpniuA+spo0twMsOaA@mail.gmail.com>
	<099DA0A2-DD97-4C8F-90B8-665F20F98B19@redhat.com>
	<CAAg5f2S=he---8bjma0EX+YVYsVPy5_JCRX0yeFeU0zDME2Xig@mail.gmail.com>
	<52EFE5CE.40209@gmail.com>
	<CAAg5f2QPz5W2s5MUKzbZdV0k=t4uBzwyDF1A9c1D_yUcn1Y8Rg@mail.gmail.com>
	<52EFEB68.5010203@gmail.com>
	<CAAg5f2SsOahGsHJ3UudS04Hpk9AYuNCmc4whf-_ZdmTM4f9tuw@mail.gmail.com>
Message-ID: <CAFJm-3GRU39q4VM96_4Zujjg3T+WadN+njbSX8nSW_=6K90j2Q@mail.gmail.com>

Cool, will try it out later today!




On 3 February 2014 22:50, Matthias Wessendorf <matzew at apache.org> 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 <jrconlin at gmail.com> 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 <jrconlin at gmail.com> 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 <lholmqui at redhat.com>
>>> 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 <matzew at apache.org>
>>>> 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: <CAAg5f2SaSJ=wJT6cshXyucBTvXKPBQ=F_h0zTggM2mKaCYoCvg@mail.gmail.com>

When do we plan on releasing the 1.4 ?

On Tuesday, February 4, 2014, Corinne Krych <corinnekrych at gmail.com> 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 <javascript:;>
> 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: <CF09A466-11C5-4C13-AE70-E7DD88EA52D9@gmail.com>

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: <CF09A466-11C5-4C13-AE70-E7DD88EA52D9@gmail.com>
References: <CF09A466-11C5-4C13-AE70-E7DD88EA52D9@gmail.com>
Message-ID: <CAAg5f2SrSXnDCmxfrtzwxn24O=S2FKrN1Lhs+kOnpr4BaNbXyg@mail.gmail.com>

I can delete my iOS-sync-poc, right?

On Tuesday, February 4, 2014, Corinne Krych <corinnekrych at gmail.com> 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 <javascript:;>
> 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: <B74C9D63-59D6-457E-AF39-E4177320F7D2@gmail.com>

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: <CAAg5f2SaSJ=wJT6cshXyucBTvXKPBQ=F_h0zTggM2mKaCYoCvg@mail.gmail.com>
References: <2B45D240-C2CA-4E20-825A-63579B79DBD5@gmail.com>
	<CAAg5f2SaSJ=wJT6cshXyucBTvXKPBQ=F_h0zTggM2mKaCYoCvg@mail.gmail.com>
Message-ID: <E9BCE4E3-E7CA-4F95-BE7F-FC957DA07F29@gmail.com>

a question for our meeting, lots left items crypto related, i think.
On 04 Feb 2014, at 09:00, Matthias Wessendorf <matzew at apache.org> wrote:

> When do we plan on releasing the 1.4 ?
> 
> On Tuesday, February 4, 2014, Corinne Krych <corinnekrych at gmail.com> 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: <CAAg5f2SrSXnDCmxfrtzwxn24O=S2FKrN1Lhs+kOnpr4BaNbXyg@mail.gmail.com>
References: <CF09A466-11C5-4C13-AE70-E7DD88EA52D9@gmail.com>
	<CAAg5f2SrSXnDCmxfrtzwxn24O=S2FKrN1Lhs+kOnpr4BaNbXyg@mail.gmail.com>
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 <matzew at apache.org> wrote:

> I can delete my iOS-sync-poc, right?
> 
> On Tuesday, February 4, 2014, Corinne Krych <corinnekrych at gmail.com> 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: <B74C9D63-59D6-457E-AF39-E4177320F7D2@gmail.com>
References: <B74C9D63-59D6-457E-AF39-E4177320F7D2@gmail.com>
Message-ID: <CAAg5f2R09nBCZES4N4PkcrkOqqvPR3fObZpMMcuX5udsC7U+vw@mail.gmail.com>

On Tue, Feb 4, 2014 at 9:11 AM, Corinne Krych <corinnekrych at gmail.com>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: <CF09A466-11C5-4C13-AE70-E7DD88EA52D9@gmail.com>
	<CAAg5f2SrSXnDCmxfrtzwxn24O=S2FKrN1Lhs+kOnpr4BaNbXyg@mail.gmail.com>
	<548066C6-FC90-4B03-8A21-F5D02399A313@gmail.com>
Message-ID: <CAAg5f2QhdUDf9igq3V8X1RFbckOw5YZg7DvBdw5JPF+s4Zsqag@mail.gmail.com>

Ok, does not hurt to keep it around :-)


On Tue, Feb 4, 2014 at 9:13 AM, Corinne Krych <corinnekrych at gmail.com>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 <matzew at apache.org> wrote:
>
> > I can delete my iOS-sync-poc, right?
> >
> > On Tuesday, February 4, 2014, Corinne Krych <corinnekrych at gmail.com>
> 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: <CAAg5f2QhdUDf9igq3V8X1RFbckOw5YZg7DvBdw5JPF+s4Zsqag@mail.gmail.com>
References: <CF09A466-11C5-4C13-AE70-E7DD88EA52D9@gmail.com>
	<CAAg5f2SrSXnDCmxfrtzwxn24O=S2FKrN1Lhs+kOnpr4BaNbXyg@mail.gmail.com>
	<548066C6-FC90-4B03-8A21-F5D02399A313@gmail.com>
	<CAAg5f2QhdUDf9igq3V8X1RFbckOw5YZg7DvBdw5JPF+s4Zsqag@mail.gmail.com>
Message-ID: <CAFJm-3EnnGeyH5jXThAau+1ieRQBArTWPxLvywcW1_2abuYVTw@mail.gmail.com>

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 <matzew at apache.org> wrote:

> Ok, does not hurt to keep it around :-)
>
>
> On Tue, Feb 4, 2014 at 9:13 AM, Corinne Krych <corinnekrych at gmail.com>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 <matzew at apache.org> wrote:
>>
>> > I can delete my iOS-sync-poc, right?
>> >
>> > On Tuesday, February 4, 2014, Corinne Krych <corinnekrych at gmail.com>
>> 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: <CAFJm-3EnnGeyH5jXThAau+1ieRQBArTWPxLvywcW1_2abuYVTw@mail.gmail.com>
References: <CF09A466-11C5-4C13-AE70-E7DD88EA52D9@gmail.com>
	<CAAg5f2SrSXnDCmxfrtzwxn24O=S2FKrN1Lhs+kOnpr4BaNbXyg@mail.gmail.com>
	<548066C6-FC90-4B03-8A21-F5D02399A313@gmail.com>
	<CAAg5f2QhdUDf9igq3V8X1RFbckOw5YZg7DvBdw5JPF+s4Zsqag@mail.gmail.com>
	<CAFJm-3EnnGeyH5jXThAau+1ieRQBArTWPxLvywcW1_2abuYVTw@mail.gmail.com>
Message-ID: <CAL8vO=dRkOF1cu5XY65veo3fgC3f-14qOYVLDhhfFd2+17fthg@mail.gmail.com>

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 <daniel.bevenius at gmail.com> 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 <matzew at apache.org> wrote:
>
>> Ok, does not hurt to keep it around :-)
>>
>>
>> On Tue, Feb 4, 2014 at 9:13 AM, Corinne Krych <corinnekrych at gmail.com>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 <matzew at apache.org> wrote:
>>>
>>> > I can delete my iOS-sync-poc, right?
>>> >
>>> > On Tuesday, February 4, 2014, Corinne Krych <corinnekrych at gmail.com>
>>> 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: <CAAg5f2R09nBCZES4N4PkcrkOqqvPR3fObZpMMcuX5udsC7U+vw@mail.gmail.com>
References: <B74C9D63-59D6-457E-AF39-E4177320F7D2@gmail.com>
	<CAAg5f2R09nBCZES4N4PkcrkOqqvPR3fObZpMMcuX5udsC7U+vw@mail.gmail.com>
Message-ID: <3E247C9A-880A-4411-9D68-264565C78FE0@gmail.com>


On 04 Feb 2014, at 09:15, Matthias Wessendorf <matzew at apache.org> wrote:

> 
> 
> 
> On Tue, Feb 4, 2014 at 9:11 AM, Corinne Krych <corinnekrych at gmail.com> 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: <CAL8vO=ejFuobRbuq-rpLuOzfwb8pBxrx8vg_BxDFJAv-kuPdKA@mail.gmail.com>
References: <2BC0CB71-5EAD-4AA6-9495-AD86CD122BD6@gmail.com>
	<F7AA1126-DEA9-44CC-ACB0-1EE9983D07C9@gmail.com>
	<CAL8vO=ejFuobRbuq-rpLuOzfwb8pBxrx8vg_BxDFJAv-kuPdKA@mail.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 <corinnekrych at gmail.com> 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 <cvasilak at gmail.com> 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 <corinnekrych at gmail.com> 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>
	<F7AA1126-DEA9-44CC-ACB0-1EE9983D07C9@gmail.com>
	<CAL8vO=ejFuobRbuq-rpLuOzfwb8pBxrx8vg_BxDFJAv-kuPdKA@mail.gmail.com>
	<4E2E9378-95F1-4CBE-88EC-545AFFF62D37@gmail.com>
Message-ID: <CAAg5f2Rs-THvWM=vDmWdM9KHDoRYfG5kT2pgcP-=ju0idj-Bbg@mail.gmail.com>

consistency FTW


On Tue, Feb 4, 2014 at 1:55 PM, Corinne Krych <corinnekrych at gmail.com>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 <corinnekrych at gmail.com> 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 <cvasilak at gmail.com>
> 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 <corinnekrych at gmail.com>
> 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: <E9BCE4E3-E7CA-4F95-BE7F-FC957DA07F29@gmail.com>
References: <2B45D240-C2CA-4E20-825A-63579B79DBD5@gmail.com>
	<CAAg5f2SaSJ=wJT6cshXyucBTvXKPBQ=F_h0zTggM2mKaCYoCvg@mail.gmail.com>
	<E9BCE4E3-E7CA-4F95-BE7F-FC957DA07F29@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 <corinnekrych at gmail.com> wrote:

> a question for our meeting, lots left items crypto related, i think.
> On 04 Feb 2014, at 09:00, Matthias Wessendorf <matzew at apache.org> wrote:
> 
>> When do we plan on releasing the 1.4 ?
>> 
>> On Tuesday, February 4, 2014, Corinne Krych <corinnekrych at gmail.com> 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: <CAL8vO=ejFuobRbuq-rpLuOzfwb8pBxrx8vg_BxDFJAv-kuPdKA@mail.gmail.com>
References: <2BC0CB71-5EAD-4AA6-9495-AD86CD122BD6@gmail.com>
	<F7AA1126-DEA9-44CC-ACB0-1EE9983D07C9@gmail.com>
	<CAL8vO=ejFuobRbuq-rpLuOzfwb8pBxrx8vg_BxDFJAv-kuPdKA@mail.gmail.com>
Message-ID: <CAL8vO=e30+DL=xUB5kDSb_EQJmsBbaB_ORveSLGncH4_rZv=bg@mail.gmail.com>

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 <corinnekrych at gmail.com> 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 <cvasilak at gmail.com> 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 <corinnekrych at gmail.com> 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: <B74C9D63-59D6-457E-AF39-E4177320F7D2@gmail.com>
References: <B74C9D63-59D6-457E-AF39-E4177320F7D2@gmail.com>
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 <corinnekrych at gmail.com> 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: <CF09A466-11C5-4C13-AE70-E7DD88EA52D9@gmail.com>
References: <CF09A466-11C5-4C13-AE70-E7DD88EA52D9@gmail.com>
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: <CF09A466-11C5-4C13-AE70-E7DD88EA52D9@gmail.com>
	<52F11871.1090808@redhat.com>
Message-ID: <DB39C9AF-5B3F-453C-9A56-FE46FB6338E1@redhat.com>



Sent from my iPhone

> On Feb 4, 2014, at 11:42 AM, Summers Pittman <supittma at redhat.com> 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: <CF09A466-11C5-4C13-AE70-E7DD88EA52D9@gmail.com>
	<52F11871.1090808@redhat.com>
Message-ID: <CAAg5f2RMpHRkoP+-QW=KePR8q8k-_isM802nQJCo7ZKzXU9=fw@mail.gmail.com>

On Tue, Feb 4, 2014 at 5:42 PM, Summers Pittman <supittma at redhat.com> 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: <CAAg5f2RMpHRkoP+-QW=KePR8q8k-_isM802nQJCo7ZKzXU9=fw@mail.gmail.com>
References: <CF09A466-11C5-4C13-AE70-E7DD88EA52D9@gmail.com>	<52F11871.1090808@redhat.com>
	<CAAg5f2RMpHRkoP+-QW=KePR8q8k-_isM802nQJCo7ZKzXU9=fw@mail.gmail.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 <supittma at redhat.com 
> <mailto:supittma at redhat.com>> 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 <mailto:aerogear-dev at lists.jboss.org>
>     > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>     _______________________________________________
>     aerogear-dev mailing list
>     aerogear-dev at lists.jboss.org <mailto: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: <CF09A466-11C5-4C13-AE70-E7DD88EA52D9@gmail.com>
	<52F11871.1090808@redhat.com>
	<CAAg5f2RMpHRkoP+-QW=KePR8q8k-_isM802nQJCo7ZKzXU9=fw@mail.gmail.com>
	<52F11F02.3060007@redhat.com>
Message-ID: <CAAg5f2QVdoJSGfjh2zfPY=2hsqudBjHP3XxmZ+gyFUKzBOwxjg@mail.gmail.com>

On Tue, Feb 4, 2014 at 6:10 PM, Summers Pittman <supittma at redhat.com> wrote:

>  On 02/04/2014 11:52 AM, Matthias Wessendorf wrote:
>
>
>
>
> On Tue, Feb 4, 2014 at 5:42 PM, Summers Pittman <supittma at redhat.com>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: <CAAg5f2TdG_jV48CjKAtk=D8ydQEjLCvi+6h-TBmo+ZTWvTfJyg@mail.gmail.com>

On Tue, Feb 4, 2014 at 6:13 PM, Karel Piwko <kpiwko at redhat.com> 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: <CAAg5f2TdG_jV48CjKAtk=D8ydQEjLCvi+6h-TBmo+ZTWvTfJyg@mail.gmail.com>
References: <20140204181339.60267f2c@kapy-ntb-x220>
	<CAAg5f2TdG_jV48CjKAtk=D8ydQEjLCvi+6h-TBmo+ZTWvTfJyg@mail.gmail.com>
Message-ID: <CAAg5f2QFeuAz0xhdUZ5HcCaLwu6A5nH1t8nHnshvL+x0RgR+RA@mail.gmail.com>

oh, this was a cross-post :-) (adding keycloak)


On Tue, Feb 4, 2014 at 6:20 PM, Matthias Wessendorf <matzew at apache.org>wrote:

>
>
>
> On Tue, Feb 4, 2014 at 6:13 PM, Karel Piwko <kpiwko at redhat.com> 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: <CAAg5f2QFeuAz0xhdUZ5HcCaLwu6A5nH1t8nHnshvL+x0RgR+RA@mail.gmail.com>
References: <20140204181339.60267f2c@kapy-ntb-x220>
	<CAAg5f2TdG_jV48CjKAtk=D8ydQEjLCvi+6h-TBmo+ZTWvTfJyg@mail.gmail.com>
	<CAAg5f2QFeuAz0xhdUZ5HcCaLwu6A5nH1t8nHnshvL+x0RgR+RA@mail.gmail.com>
Message-ID: <20140204183437.0737d77f@kapy-ntb-x220>

On Tue, 4 Feb 2014 18:21:10 +0100
Matthias Wessendorf <matzew at apache.org> wrote:

> oh, this was a cross-post :-) (adding keycloak)
> 
> 
> On Tue, Feb 4, 2014 at 6:20 PM, Matthias Wessendorf <matzew at apache.org>wrote:
> 
> >
> >
> >
> > On Tue, Feb 4, 2014 at 6:13 PM, Karel Piwko <kpiwko at redhat.com> 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>
	<CAAg5f2TdG_jV48CjKAtk=D8ydQEjLCvi+6h-TBmo+ZTWvTfJyg@mail.gmail.com>
	<CAAg5f2QFeuAz0xhdUZ5HcCaLwu6A5nH1t8nHnshvL+x0RgR+RA@mail.gmail.com>
	<20140204183437.0737d77f@kapy-ntb-x220>
Message-ID: <CAAg5f2RzyGYRf36-abKv_rn8TZ6v1sH3LO-_YfFoLRczs8Ln3g@mail.gmail.com>

On Tue, Feb 4, 2014 at 6:34 PM, Karel Piwko <kpiwko at redhat.com> wrote:

> On Tue, 4 Feb 2014 18:21:10 +0100
> Matthias Wessendorf <matzew at apache.org> wrote:
>
> > oh, this was a cross-post :-) (adding keycloak)
> >
> >
> > On Tue, Feb 4, 2014 at 6:20 PM, Matthias Wessendorf <matzew at apache.org
> >wrote:
> >
> > >
> > >
> > >
> > > On Tue, Feb 4, 2014 at 6:13 PM, Karel Piwko <kpiwko at redhat.com> 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: <CAAg5f2QVdoJSGfjh2zfPY=2hsqudBjHP3XxmZ+gyFUKzBOwxjg@mail.gmail.com>
References: <CF09A466-11C5-4C13-AE70-E7DD88EA52D9@gmail.com>
	<52F11871.1090808@redhat.com>
	<CAAg5f2RMpHRkoP+-QW=KePR8q8k-_isM802nQJCo7ZKzXU9=fw@mail.gmail.com>
	<52F11F02.3060007@redhat.com>
	<CAAg5f2QVdoJSGfjh2zfPY=2hsqudBjHP3XxmZ+gyFUKzBOwxjg@mail.gmail.com>
Message-ID: <CAL8vO=crTAmqKQ-41i0c1QsYpL9DMUkd3KArj05qpvibNW+Grw@mail.gmail.com>

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 <matzew at apache.org> wrote:

>
>
>
> On Tue, Feb 4, 2014 at 6:10 PM, Summers Pittman <supittma at redhat.com>wrote:
>
>>  On 02/04/2014 11:52 AM, Matthias Wessendorf wrote:
>>
>>
>>
>>
>> On Tue, Feb 4, 2014 at 5:42 PM, Summers Pittman <supittma at redhat.com>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: <B74C9D63-59D6-457E-AF39-E4177320F7D2@gmail.com>
	<20140204170257.0c396f7b@kapy-ntb-x220>
Message-ID: <CAL8vO=ev=eZs+MPB-_2Och_V3dWEW=e56DRGi3QMYM9M2ravAQ@mail.gmail.com>

+1
Thanks for sharing.



On 4 February 2014 17:02, Karel Piwko <kpiwko at redhat.com> 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 <corinnekrych at gmail.com> 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: <CAFJm-3GRU39q4VM96_4Zujjg3T+WadN+njbSX8nSW_=6K90j2Q@mail.gmail.com>
References: <CAAg5f2RsDptcyjj2zExyPY+ftMNZPeoNDpniuA+spo0twMsOaA@mail.gmail.com>
	<099DA0A2-DD97-4C8F-90B8-665F20F98B19@redhat.com>
	<CAAg5f2S=he---8bjma0EX+YVYsVPy5_JCRX0yeFeU0zDME2Xig@mail.gmail.com>
	<52EFE5CE.40209@gmail.com>
	<CAAg5f2QPz5W2s5MUKzbZdV0k=t4uBzwyDF1A9c1D_yUcn1Y8Rg@mail.gmail.com>
	<52EFEB68.5010203@gmail.com>
	<CAAg5f2SsOahGsHJ3UudS04Hpk9AYuNCmc4whf-_ZdmTM4f9tuw@mail.gmail.com>
	<CAFJm-3GRU39q4VM96_4Zujjg3T+WadN+njbSX8nSW_=6K90j2Q@mail.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 <daniel.bevenius at gmail.com> wrote:

> Cool, will try it out later today!
> 
> 
> 
> 
> On 3 February 2014 22:50, Matthias Wessendorf <matzew at apache.org> 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 <jrconlin at gmail.com> 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 <jrconlin at gmail.com> 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 <lholmqui at redhat.com> 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 <matzew at apache.org> 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: <CAAg5f2RsDptcyjj2zExyPY+ftMNZPeoNDpniuA+spo0twMsOaA@mail.gmail.com>
	<099DA0A2-DD97-4C8F-90B8-665F20F98B19@redhat.com>
	<CAAg5f2S=he---8bjma0EX+YVYsVPy5_JCRX0yeFeU0zDME2Xig@mail.gmail.com>
	<52EFE5CE.40209@gmail.com>
	<CAAg5f2QPz5W2s5MUKzbZdV0k=t4uBzwyDF1A9c1D_yUcn1Y8Rg@mail.gmail.com>
	<52EFEB68.5010203@gmail.com>
	<CAAg5f2SsOahGsHJ3UudS04Hpk9AYuNCmc4whf-_ZdmTM4f9tuw@mail.gmail.com>
	<CAFJm-3GRU39q4VM96_4Zujjg3T+WadN+njbSX8nSW_=6K90j2Q@mail.gmail.com>
	<42C979F5-1913-430D-9CD4-5348F8FAE65B@redhat.com>
Message-ID: <CAD_dpu09W3BcvgCA-FjXBTZG2esh4409B6G+0c_+gOzc3TxRXA@mail.gmail.com>

awesome Luke !


On Tue, Feb 4, 2014 at 9:25 PM, Lucas Holmquist <lholmqui at redhat.com> 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 <daniel.bevenius at gmail.com>
> wrote:
>
> Cool, will try it out later today!
>
>
>
>
> On 3 February 2014 22:50, Matthias Wessendorf <matzew at apache.org> 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 <jrconlin at gmail.com> 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 <jrconlin at gmail.com> 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 <lholmqui at redhat.com>
>>>> 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 <matzew at apache.org>
>>>>> 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: <CAAg5f2TikGLSoXWzQDOXy-Tg5ihZU4GwTAXS6YAD_CsM00bKkQ@mail.gmail.com>
References: <CAAg5f2RaSeK0VMnC3Qd7E4SAMkLb-by4DnkccMoCp9c9Bfb3tw@mail.gmail.com>
	<66BF1C73-3838-4CFD-936E-26FC5282E7E5@gmail.com>
	<CAAg5f2TikGLSoXWzQDOXy-Tg5ihZU4GwTAXS6YAD_CsM00bKkQ@mail.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 <matzew at apache.org> wrote:

> 
> 
> 
> On Thu, Jan 16, 2014 at 9:21 AM, Christos Vasilakis <cvasilak at gmail.com> wrote:
> 
> On Jan 16, 2014, at 8:31 AM, Matthias Wessendorf <matzew at apache.org> 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: <CAAg5f2RaSeK0VMnC3Qd7E4SAMkLb-by4DnkccMoCp9c9Bfb3tw@mail.gmail.com>
	<66BF1C73-3838-4CFD-936E-26FC5282E7E5@gmail.com>
	<CAAg5f2TikGLSoXWzQDOXy-Tg5ihZU4GwTAXS6YAD_CsM00bKkQ@mail.gmail.com>
	<041C11E2-C3CE-4BA6-B2A4-6DE13FE036E9@gmail.com>
Message-ID: <C325DC28-D4F5-47AB-B770-768C5D58F731@gmail.com>

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 <cvasilak at gmail.com> 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 <matzew at apache.org> wrote:
> 
>> 
>> 
>> 
>> On Thu, Jan 16, 2014 at 9:21 AM, Christos Vasilakis <cvasilak at gmail.com> wrote:
>> 
>> On Jan 16, 2014, at 8:31 AM, Matthias Wessendorf <matzew at apache.org> 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: <C325DC28-D4F5-47AB-B770-768C5D58F731@gmail.com>
References: <CAAg5f2RaSeK0VMnC3Qd7E4SAMkLb-by4DnkccMoCp9c9Bfb3tw@mail.gmail.com>
	<66BF1C73-3838-4CFD-936E-26FC5282E7E5@gmail.com>
	<CAAg5f2TikGLSoXWzQDOXy-Tg5ihZU4GwTAXS6YAD_CsM00bKkQ@mail.gmail.com>
	<041C11E2-C3CE-4BA6-B2A4-6DE13FE036E9@gmail.com>
	<C325DC28-D4F5-47AB-B770-768C5D58F731@gmail.com>
Message-ID: <CAAg5f2T1r+y0EciShD-zN-5FSQGf_KvY8=N4Ja_6H23B5q8UaQ@mail.gmail.com>

On Wed, Feb 5, 2014 at 9:33 AM, Corinne Krych <corinnekrych at gmail.com>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 <cvasilak at gmail.com> 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 <matzew at apache.org>
> wrote:
> >
> >>
> >>
> >>
> >> On Thu, Jan 16, 2014 at 9:21 AM, Christos Vasilakis <cvasilak at gmail.com>
> wrote:
> >>
> >> On Jan 16, 2014, at 8:31 AM, Matthias Wessendorf <matzew at apache.org>
> 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: <CAAg5f2T1r+y0EciShD-zN-5FSQGf_KvY8=N4Ja_6H23B5q8UaQ@mail.gmail.com>
References: <CAAg5f2RaSeK0VMnC3Qd7E4SAMkLb-by4DnkccMoCp9c9Bfb3tw@mail.gmail.com>
	<66BF1C73-3838-4CFD-936E-26FC5282E7E5@gmail.com>
	<CAAg5f2TikGLSoXWzQDOXy-Tg5ihZU4GwTAXS6YAD_CsM00bKkQ@mail.gmail.com>
	<041C11E2-C3CE-4BA6-B2A4-6DE13FE036E9@gmail.com>
	<C325DC28-D4F5-47AB-B770-768C5D58F731@gmail.com>
	<CAAg5f2T1r+y0EciShD-zN-5FSQGf_KvY8=N4Ja_6H23B5q8UaQ@mail.gmail.com>
Message-ID: <FBC1A819-03A7-42B5-BF92-D60014C96746@gmail.com>


On 05 Feb 2014, at 09:36, Matthias Wessendorf <matzew at apache.org> wrote:

> 
> 
> 
> On Wed, Feb 5, 2014 at 9:33 AM, Corinne Krych <corinnekrych at gmail.com> 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 <cvasilak at gmail.com> 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 <matzew at apache.org> wrote:
> >
> >>
> >>
> >>
> >> On Thu, Jan 16, 2014 at 9:21 AM, Christos Vasilakis <cvasilak at gmail.com> wrote:
> >>
> >> On Jan 16, 2014, at 8:31 AM, Matthias Wessendorf <matzew at apache.org> 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: <EDCB268A-FB02-4676-B14A-6297FB7DB4AE@gmail.com>

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: <CAAg5f2T1r+y0EciShD-zN-5FSQGf_KvY8=N4Ja_6H23B5q8UaQ@mail.gmail.com>
References: <CAAg5f2RaSeK0VMnC3Qd7E4SAMkLb-by4DnkccMoCp9c9Bfb3tw@mail.gmail.com>
	<66BF1C73-3838-4CFD-936E-26FC5282E7E5@gmail.com>
	<CAAg5f2TikGLSoXWzQDOXy-Tg5ihZU4GwTAXS6YAD_CsM00bKkQ@mail.gmail.com>
	<041C11E2-C3CE-4BA6-B2A4-6DE13FE036E9@gmail.com>
	<C325DC28-D4F5-47AB-B770-768C5D58F731@gmail.com>
	<CAAg5f2T1r+y0EciShD-zN-5FSQGf_KvY8=N4Ja_6H23B5q8UaQ@mail.gmail.com>
Message-ID: <7828166D-B8BC-4685-BC1D-4BBDC2001CC1@gmail.com>


On Feb 5, 2014, at 10:36 AM, Matthias Wessendorf <matzew at apache.org> wrote:

> 
> 
> 
> On Wed, Feb 5, 2014 at 9:33 AM, Corinne Krych <corinnekrych at gmail.com> 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 <cvasilak at gmail.com> 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 <matzew at apache.org> wrote:
> >
> >>
> >>
> >>
> >> On Thu, Jan 16, 2014 at 9:21 AM, Christos Vasilakis <cvasilak at gmail.com> wrote:
> >>
> >> On Jan 16, 2014, at 8:31 AM, Matthias Wessendorf <matzew at apache.org> 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: <CAAg5f2RsDptcyjj2zExyPY+ftMNZPeoNDpniuA+spo0twMsOaA@mail.gmail.com>
References: <CAAg5f2RsDptcyjj2zExyPY+ftMNZPeoNDpniuA+spo0twMsOaA@mail.gmail.com>
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 <matzew at apache.org> 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: <CAAg5f2RsDptcyjj2zExyPY+ftMNZPeoNDpniuA+spo0twMsOaA@mail.gmail.com>
	<20140205103218.40efeb64@kapy-ntb-x220>
Message-ID: <CAAg5f2Q0AXrJYK-j2xeWTpXLkXvV0wp9+wY=FpavvVtwfC=v8Q@mail.gmail.com>

On Wed, Feb 5, 2014 at 10:32 AM, Karel Piwko <kpiwko at redhat.com> 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 <matzew at apache.org> 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: <EDCB268A-FB02-4676-B14A-6297FB7DB4AE@gmail.com>
References: <EDCB268A-FB02-4676-B14A-6297FB7DB4AE@gmail.com>
Message-ID: <CAKVvow_SBRYsO4xj2VMNx72hxVOLgoUTbj_CxKJzu8MAWGr=2A@mail.gmail.com>

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
>
-------------- 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: <CAAg5f2QWjG5-ak-jjMY1=NapZNEJZk26t8Z5hqaxR0ery5tEFw@mail.gmail.com>

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 <bburke at redhat.com> 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 <corinnekrych at gmail.com> 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 <bburke at redhat.com> 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: <CAKVvow_SBRYsO4xj2VMNx72hxVOLgoUTbj_CxKJzu8MAWGr=2A@mail.gmail.com>
References: <EDCB268A-FB02-4676-B14A-6297FB7DB4AE@gmail.com>
	<CAKVvow_SBRYsO4xj2VMNx72hxVOLgoUTbj_CxKJzu8MAWGr=2A@mail.gmail.com>
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 <cvasilak at gmail.com> 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



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: <CAAg5f2QWjG5-ak-jjMY1=NapZNEJZk26t8Z5hqaxR0ery5tEFw@mail.gmail.com>
References: <CAAg5f2QWjG5-ak-jjMY1=NapZNEJZk26t8Z5hqaxR0ery5tEFw@mail.gmail.com>
Message-ID: <etPan.52f25042.327b23c6.9cb8@animus>

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: <EDCB268A-FB02-4676-B14A-6297FB7DB4AE@gmail.com>
	<CAKVvow_SBRYsO4xj2VMNx72hxVOLgoUTbj_CxKJzu8MAWGr=2A@mail.gmail.com>
	<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 <cvasilak at gmail.com> 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



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: <EDCB268A-FB02-4676-B14A-6297FB7DB4AE@gmail.com>
	<CAKVvow_SBRYsO4xj2VMNx72hxVOLgoUTbj_CxKJzu8MAWGr=2A@mail.gmail.com>
	<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 <supittma at redhat.com> 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 <cvasilak at gmail.com> 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



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: <etPan.52f25042.327b23c6.9cb8@animus>
References: <CAAg5f2QWjG5-ak-jjMY1=NapZNEJZk26t8Z5hqaxR0ery5tEFw@mail.gmail.com>
	<etPan.52f25042.327b23c6.9cb8@animus>
Message-ID: <CAAg5f2QwOaNenHEO_QSOk2Hga_cf0i755eP4+0oCE1-uvtQ0cQ@mail.gmail.com>

Hello Bruno!


On Wed, Feb 5, 2014 at 3:52 PM, Bruno Oliveira <bruno at abstractj.org> 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: <CAAg5f2QwOaNenHEO_QSOk2Hga_cf0i755eP4+0oCE1-uvtQ0cQ@mail.gmail.com>
References: <CAAg5f2QWjG5-ak-jjMY1=NapZNEJZk26t8Z5hqaxR0ery5tEFw@mail.gmail.com>
	<etPan.52f25042.327b23c6.9cb8@animus>
	<CAAg5f2QwOaNenHEO_QSOk2Hga_cf0i755eP4+0oCE1-uvtQ0cQ@mail.gmail.com>
Message-ID: <etPan.52f26153.643c9869.9cb8@animus>

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: <etPan.52f26153.643c9869.9cb8@animus>
References: <CAAg5f2QWjG5-ak-jjMY1=NapZNEJZk26t8Z5hqaxR0ery5tEFw@mail.gmail.com>
	<etPan.52f25042.327b23c6.9cb8@animus>
	<CAAg5f2QwOaNenHEO_QSOk2Hga_cf0i755eP4+0oCE1-uvtQ0cQ@mail.gmail.com>
	<etPan.52f26153.643c9869.9cb8@animus>
Message-ID: <CAAg5f2Q4DVFeqKN8Ft+0Obi4TH64ZLfvp2J5K=pMVspMpGdB8Q@mail.gmail.com>

Hello Bruno,


On Wed, Feb 5, 2014 at 5:05 PM, Bruno Oliveira <bruno at abstractj.org> 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: <CAAg5f2Q4DVFeqKN8Ft+0Obi4TH64ZLfvp2J5K=pMVspMpGdB8Q@mail.gmail.com>
References: <CAAg5f2QWjG5-ak-jjMY1=NapZNEJZk26t8Z5hqaxR0ery5tEFw@mail.gmail.com>
	<etPan.52f25042.327b23c6.9cb8@animus>
	<CAAg5f2QwOaNenHEO_QSOk2Hga_cf0i755eP4+0oCE1-uvtQ0cQ@mail.gmail.com>
	<etPan.52f26153.643c9869.9cb8@animus>
	<CAAg5f2Q4DVFeqKN8Ft+0Obi4TH64ZLfvp2J5K=pMVspMpGdB8Q@mail.gmail.com>
Message-ID: <CAKjsGbuw5Oscw2Fkc81E0FPa9diA7obOfzF1J9beHY7=mAXP-g@mail.gmail.com>

On Wed, Feb 5, 2014 at 2:49 PM, Matthias Wessendorf <matzew at apache.org>wrote:

> Hello Bruno,
>
>
> On Wed, Feb 5, 2014 at 5:05 PM, Bruno Oliveira <bruno at abstractj.org>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: <CAKjsGbuw5Oscw2Fkc81E0FPa9diA7obOfzF1J9beHY7=mAXP-g@mail.gmail.com>
References: <CAAg5f2QWjG5-ak-jjMY1=NapZNEJZk26t8Z5hqaxR0ery5tEFw@mail.gmail.com>
	<etPan.52f25042.327b23c6.9cb8@animus>
	<CAAg5f2QwOaNenHEO_QSOk2Hga_cf0i755eP4+0oCE1-uvtQ0cQ@mail.gmail.com>
	<etPan.52f26153.643c9869.9cb8@animus>
	<CAAg5f2Q4DVFeqKN8Ft+0Obi4TH64ZLfvp2J5K=pMVspMpGdB8Q@mail.gmail.com>
	<CAKjsGbuw5Oscw2Fkc81E0FPa9diA7obOfzF1J9beHY7=mAXP-g@mail.gmail.com>
Message-ID: <CAAg5f2REYCb+Pg31XQVpvoe4QFWtb-anajFEwVZE68uC8cqxQA@mail.gmail.com>

On Wed, Feb 5, 2014 at 6:53 PM, Daniel Passos <daniel at passos.me> wrote:

> On Wed, Feb 5, 2014 at 2:49 PM, Matthias Wessendorf <matzew at apache.org>wrote:
>
>> Hello Bruno,
>>
>>
>> On Wed, Feb 5, 2014 at 5:05 PM, Bruno Oliveira <bruno at abstractj.org>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: <CAAg5f2REYCb+Pg31XQVpvoe4QFWtb-anajFEwVZE68uC8cqxQA@mail.gmail.com>
References: <CAAg5f2QWjG5-ak-jjMY1=NapZNEJZk26t8Z5hqaxR0ery5tEFw@mail.gmail.com>
	<etPan.52f25042.327b23c6.9cb8@animus>
	<CAAg5f2QwOaNenHEO_QSOk2Hga_cf0i755eP4+0oCE1-uvtQ0cQ@mail.gmail.com>
	<etPan.52f26153.643c9869.9cb8@animus>
	<CAAg5f2Q4DVFeqKN8Ft+0Obi4TH64ZLfvp2J5K=pMVspMpGdB8Q@mail.gmail.com>
	<CAKjsGbuw5Oscw2Fkc81E0FPa9diA7obOfzF1J9beHY7=mAXP-g@mail.gmail.com>
	<CAAg5f2REYCb+Pg31XQVpvoe4QFWtb-anajFEwVZE68uC8cqxQA@mail.gmail.com>
Message-ID: <etPan.52f285e8.66334873.9cb8@animus>

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: <etPan.52f285e8.66334873.9cb8@animus>
References: <CAAg5f2QWjG5-ak-jjMY1=NapZNEJZk26t8Z5hqaxR0ery5tEFw@mail.gmail.com>
	<etPan.52f25042.327b23c6.9cb8@animus>
	<CAAg5f2QwOaNenHEO_QSOk2Hga_cf0i755eP4+0oCE1-uvtQ0cQ@mail.gmail.com>
	<etPan.52f26153.643c9869.9cb8@animus>
	<CAAg5f2Q4DVFeqKN8Ft+0Obi4TH64ZLfvp2J5K=pMVspMpGdB8Q@mail.gmail.com>
	<CAKjsGbuw5Oscw2Fkc81E0FPa9diA7obOfzF1J9beHY7=mAXP-g@mail.gmail.com>
	<CAAg5f2REYCb+Pg31XQVpvoe4QFWtb-anajFEwVZE68uC8cqxQA@mail.gmail.com>
	<etPan.52f285e8.66334873.9cb8@animus>
Message-ID: <CAAg5f2QEpE-peqZEaMox3O-fTKwXd1S9=3kS7Yg2mArr3K4zmQ@mail.gmail.com>

On Wed, Feb 5, 2014 at 7:41 PM, Bruno Oliveira <bruno at abstractj.org> 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: <CAAg5f2QEpE-peqZEaMox3O-fTKwXd1S9=3kS7Yg2mArr3K4zmQ@mail.gmail.com>
References: <CAAg5f2QWjG5-ak-jjMY1=NapZNEJZk26t8Z5hqaxR0ery5tEFw@mail.gmail.com>
	<etPan.52f25042.327b23c6.9cb8@animus>
	<CAAg5f2QwOaNenHEO_QSOk2Hga_cf0i755eP4+0oCE1-uvtQ0cQ@mail.gmail.com>
	<etPan.52f26153.643c9869.9cb8@animus>
	<CAAg5f2Q4DVFeqKN8Ft+0Obi4TH64ZLfvp2J5K=pMVspMpGdB8Q@mail.gmail.com>
	<CAKjsGbuw5Oscw2Fkc81E0FPa9diA7obOfzF1J9beHY7=mAXP-g@mail.gmail.com>
	<CAAg5f2REYCb+Pg31XQVpvoe4QFWtb-anajFEwVZE68uC8cqxQA@mail.gmail.com>
	<etPan.52f285e8.66334873.9cb8@animus>
	<CAAg5f2QEpE-peqZEaMox3O-fTKwXd1S9=3kS7Yg2mArr3K4zmQ@mail.gmail.com>
Message-ID: <etPan.52f28a5b.74b0dc51.9cb8@animus>

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: <etPan.52f28a5b.74b0dc51.9cb8@animus>
References: <CAAg5f2QWjG5-ak-jjMY1=NapZNEJZk26t8Z5hqaxR0ery5tEFw@mail.gmail.com>
	<etPan.52f25042.327b23c6.9cb8@animus>
	<CAAg5f2QwOaNenHEO_QSOk2Hga_cf0i755eP4+0oCE1-uvtQ0cQ@mail.gmail.com>
	<etPan.52f26153.643c9869.9cb8@animus>
	<CAAg5f2Q4DVFeqKN8Ft+0Obi4TH64ZLfvp2J5K=pMVspMpGdB8Q@mail.gmail.com>
	<CAKjsGbuw5Oscw2Fkc81E0FPa9diA7obOfzF1J9beHY7=mAXP-g@mail.gmail.com>
	<CAAg5f2REYCb+Pg31XQVpvoe4QFWtb-anajFEwVZE68uC8cqxQA@mail.gmail.com>
	<etPan.52f285e8.66334873.9cb8@animus>
	<CAAg5f2QEpE-peqZEaMox3O-fTKwXd1S9=3kS7Yg2mArr3K4zmQ@mail.gmail.com>
	<etPan.52f28a5b.74b0dc51.9cb8@animus>
Message-ID: <CAAg5f2SaAzUmEJ_D+tQzpjoXnzjBmcn4YG5eFQY=CNBUMMPGXA@mail.gmail.com>

On Wed, Feb 5, 2014 at 8:00 PM, Bruno Oliveira <bruno at abstractj.org> 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: <CAAg5f2SaAzUmEJ_D+tQzpjoXnzjBmcn4YG5eFQY=CNBUMMPGXA@mail.gmail.com>
References: <CAAg5f2QWjG5-ak-jjMY1=NapZNEJZk26t8Z5hqaxR0ery5tEFw@mail.gmail.com>
	<etPan.52f25042.327b23c6.9cb8@animus>
	<CAAg5f2QwOaNenHEO_QSOk2Hga_cf0i755eP4+0oCE1-uvtQ0cQ@mail.gmail.com>
	<etPan.52f26153.643c9869.9cb8@animus>
	<CAAg5f2Q4DVFeqKN8Ft+0Obi4TH64ZLfvp2J5K=pMVspMpGdB8Q@mail.gmail.com>
	<CAKjsGbuw5Oscw2Fkc81E0FPa9diA7obOfzF1J9beHY7=mAXP-g@mail.gmail.com>
	<CAAg5f2REYCb+Pg31XQVpvoe4QFWtb-anajFEwVZE68uC8cqxQA@mail.gmail.com>
	<etPan.52f285e8.66334873.9cb8@animus>
	<CAAg5f2QEpE-peqZEaMox3O-fTKwXd1S9=3kS7Yg2mArr3K4zmQ@mail.gmail.com>
	<etPan.52f28a5b.74b0dc51.9cb8@animus>
	<CAAg5f2SaAzUmEJ_D+tQzpjoXnzjBmcn4YG5eFQY=CNBUMMPGXA@mail.gmail.com>
Message-ID: <etPan.52f298cc.19495cff.9cb8@animus>

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: <etPan.52f298cc.19495cff.9cb8@animus>
References: <CAAg5f2QWjG5-ak-jjMY1=NapZNEJZk26t8Z5hqaxR0ery5tEFw@mail.gmail.com>
	<etPan.52f25042.327b23c6.9cb8@animus>
	<CAAg5f2QwOaNenHEO_QSOk2Hga_cf0i755eP4+0oCE1-uvtQ0cQ@mail.gmail.com>
	<etPan.52f26153.643c9869.9cb8@animus>
	<CAAg5f2Q4DVFeqKN8Ft+0Obi4TH64ZLfvp2J5K=pMVspMpGdB8Q@mail.gmail.com>
	<CAKjsGbuw5Oscw2Fkc81E0FPa9diA7obOfzF1J9beHY7=mAXP-g@mail.gmail.com>
	<CAAg5f2REYCb+Pg31XQVpvoe4QFWtb-anajFEwVZE68uC8cqxQA@mail.gmail.com>
	<etPan.52f285e8.66334873.9cb8@animus>
	<CAAg5f2QEpE-peqZEaMox3O-fTKwXd1S9=3kS7Yg2mArr3K4zmQ@mail.gmail.com>
	<etPan.52f28a5b.74b0dc51.9cb8@animus>
	<CAAg5f2SaAzUmEJ_D+tQzpjoXnzjBmcn4YG5eFQY=CNBUMMPGXA@mail.gmail.com>
	<etPan.52f298cc.19495cff.9cb8@animus>
Message-ID: <CAAg5f2TYDRcd4WAtJzkSSc5M1B0_66cgjD4OE1WDsx+hUr02tQ@mail.gmail.com>

On Wed, Feb 5, 2014 at 9:02 PM, Bruno Oliveira <bruno at abstractj.org> 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: <CAAg5f2TYDRcd4WAtJzkSSc5M1B0_66cgjD4OE1WDsx+hUr02tQ@mail.gmail.com>
References: <etPan.52f26153.643c9869.9cb8@animus>
	<CAAg5f2Q4DVFeqKN8Ft+0Obi4TH64ZLfvp2J5K=pMVspMpGdB8Q@mail.gmail.com>
	<CAKjsGbuw5Oscw2Fkc81E0FPa9diA7obOfzF1J9beHY7=mAXP-g@mail.gmail.com>
	<CAAg5f2REYCb+Pg31XQVpvoe4QFWtb-anajFEwVZE68uC8cqxQA@mail.gmail.com>
	<etPan.52f285e8.66334873.9cb8@animus>
	<CAAg5f2QEpE-peqZEaMox3O-fTKwXd1S9=3kS7Yg2mArr3K4zmQ@mail.gmail.com>
	<etPan.52f28a5b.74b0dc51.9cb8@animus>
	<CAAg5f2SaAzUmEJ_D+tQzpjoXnzjBmcn4YG5eFQY=CNBUMMPGXA@mail.gmail.com>
	<etPan.52f298cc.19495cff.9cb8@animus>
	<CAAg5f2TYDRcd4WAtJzkSSc5M1B0_66cgjD4OE1WDsx+hUr02tQ@mail.gmail.com>
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: <etPan.52f26153.643c9869.9cb8@animus>
	<CAAg5f2Q4DVFeqKN8Ft+0Obi4TH64ZLfvp2J5K=pMVspMpGdB8Q@mail.gmail.com>
	<CAKjsGbuw5Oscw2Fkc81E0FPa9diA7obOfzF1J9beHY7=mAXP-g@mail.gmail.com>
	<CAAg5f2REYCb+Pg31XQVpvoe4QFWtb-anajFEwVZE68uC8cqxQA@mail.gmail.com>
	<etPan.52f285e8.66334873.9cb8@animus>
	<CAAg5f2QEpE-peqZEaMox3O-fTKwXd1S9=3kS7Yg2mArr3K4zmQ@mail.gmail.com>
	<etPan.52f28a5b.74b0dc51.9cb8@animus>
	<CAAg5f2SaAzUmEJ_D+tQzpjoXnzjBmcn4YG5eFQY=CNBUMMPGXA@mail.gmail.com>
	<etPan.52f298cc.19495cff.9cb8@animus>
	<CAAg5f2TYDRcd4WAtJzkSSc5M1B0_66cgjD4OE1WDsx+hUr02tQ@mail.gmail.com>
	<20140205201314.GR75920@rohan.local>
Message-ID: <etPan.52f29c70.2ae8944a.9cb8@animus>

+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: <CAD_dpu2LGDXWLBffxNsUKR8yhwT=umZ0edgEnbxymV6tqdqmmw@mail.gmail.com>

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: <CAD_dpu2LGDXWLBffxNsUKR8yhwT=umZ0edgEnbxymV6tqdqmmw@mail.gmail.com>
References: <CAD_dpu2LGDXWLBffxNsUKR8yhwT=umZ0edgEnbxymV6tqdqmmw@mail.gmail.com>
Message-ID: <CAAg5f2SXkuuvisvFVjtFATSSYxQuxt459mEFkRO17pzEuo3A6A@mail.gmail.com>

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....

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: <CAAg5f2SXkuuvisvFVjtFATSSYxQuxt459mEFkRO17pzEuo3A6A@mail.gmail.com>
References: <CAD_dpu2LGDXWLBffxNsUKR8yhwT=umZ0edgEnbxymV6tqdqmmw@mail.gmail.com>
	<CAAg5f2SXkuuvisvFVjtFATSSYxQuxt459mEFkRO17pzEuo3A6A@mail.gmail.com>
Message-ID: <58891AD3-0741-4CB7-99F1-00547F0B2B57@gmail.com>



Envoy? de mon iPhone

Le Feb 5, 2014 ? 23:52, Matthias Wessendorf <matzew at apache.org> a ?crit :

> 
> 
> 
> 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 ?
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: <CAD_dpu0S5UyPJzf7zaS6hFrgPgBU6tORcmSPKFBP6XXJ5BxT5g@mail.gmail.com>

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: <CAD_dpu0S5UyPJzf7zaS6hFrgPgBU6tORcmSPKFBP6XXJ5BxT5g@mail.gmail.com>
References: <CAD_dpu0S5UyPJzf7zaS6hFrgPgBU6tORcmSPKFBP6XXJ5BxT5g@mail.gmail.com>
Message-ID: <CAAg5f2SF5H8UAxjacg65w4PwNEVuj3kehZF-C4NJWS=wmV+5MQ@mail.gmail.com>

On Thu, Feb 6, 2014 at 9:42 AM, Sebastien Blanc <scm.blanc at gmail.com> 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: <CAAg5f2SF5H8UAxjacg65w4PwNEVuj3kehZF-C4NJWS=wmV+5MQ@mail.gmail.com>
References: <CAD_dpu0S5UyPJzf7zaS6hFrgPgBU6tORcmSPKFBP6XXJ5BxT5g@mail.gmail.com>
	<CAAg5f2SF5H8UAxjacg65w4PwNEVuj3kehZF-C4NJWS=wmV+5MQ@mail.gmail.com>
Message-ID: <CAD_dpu3KJmiNCmgX3b7U2oNM0ZFiHETkT+XFJ8Wpe_L3=FHbPw@mail.gmail.com>

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 <scm.blanc at gmail.com>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: <CAD_dpu3KJmiNCmgX3b7U2oNM0ZFiHETkT+XFJ8Wpe_L3=FHbPw@mail.gmail.com>
References: <CAD_dpu0S5UyPJzf7zaS6hFrgPgBU6tORcmSPKFBP6XXJ5BxT5g@mail.gmail.com>
	<CAAg5f2SF5H8UAxjacg65w4PwNEVuj3kehZF-C4NJWS=wmV+5MQ@mail.gmail.com>
	<CAD_dpu3KJmiNCmgX3b7U2oNM0ZFiHETkT+XFJ8Wpe_L3=FHbPw@mail.gmail.com>
Message-ID: <CAAg5f2RDwiF2FbfhVDu6_yEGnXvS_vunPYU6yzVpQ8aHhq7Upw@mail.gmail.com>

On Thu, Feb 6, 2014 at 9:52 AM, Sebastien Blanc <scm.blanc at gmail.com> 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 <scm.blanc at gmail.com>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: <CAAg5f2RDwiF2FbfhVDu6_yEGnXvS_vunPYU6yzVpQ8aHhq7Upw@mail.gmail.com>
References: <CAD_dpu0S5UyPJzf7zaS6hFrgPgBU6tORcmSPKFBP6XXJ5BxT5g@mail.gmail.com>
	<CAAg5f2SF5H8UAxjacg65w4PwNEVuj3kehZF-C4NJWS=wmV+5MQ@mail.gmail.com>
	<CAD_dpu3KJmiNCmgX3b7U2oNM0ZFiHETkT+XFJ8Wpe_L3=FHbPw@mail.gmail.com>
	<CAAg5f2RDwiF2FbfhVDu6_yEGnXvS_vunPYU6yzVpQ8aHhq7Upw@mail.gmail.com>
Message-ID: <CAD_dpu3awVbB7vMVK2iZniZ2eC73ob=2U-69gyRqqWqrAei13w@mail.gmail.com>

On Thu, Feb 6, 2014 at 9:57 AM, Matthias Wessendorf <matzew at apache.org>wrote:

>
>
>
> On Thu, Feb 6, 2014 at 9:52 AM, Sebastien Blanc <scm.blanc at gmail.com>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 <scm.blanc at gmail.com>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: <CAD_dpu3awVbB7vMVK2iZniZ2eC73ob=2U-69gyRqqWqrAei13w@mail.gmail.com>
References: <CAD_dpu0S5UyPJzf7zaS6hFrgPgBU6tORcmSPKFBP6XXJ5BxT5g@mail.gmail.com>
	<CAAg5f2SF5H8UAxjacg65w4PwNEVuj3kehZF-C4NJWS=wmV+5MQ@mail.gmail.com>
	<CAD_dpu3KJmiNCmgX3b7U2oNM0ZFiHETkT+XFJ8Wpe_L3=FHbPw@mail.gmail.com>
	<CAAg5f2RDwiF2FbfhVDu6_yEGnXvS_vunPYU6yzVpQ8aHhq7Upw@mail.gmail.com>
	<CAD_dpu3awVbB7vMVK2iZniZ2eC73ob=2U-69gyRqqWqrAei13w@mail.gmail.com>
Message-ID: <CAAg5f2Q7ixBkgRHHcornVtbgRGLjx-W8_M3XKb=Zkb5aPJVw7w@mail.gmail.com>

On Thu, Feb 6, 2014 at 10:07 AM, Sebastien Blanc <scm.blanc at gmail.com>wrote:

>
>
>
> On Thu, Feb 6, 2014 at 9:57 AM, Matthias Wessendorf <matzew at apache.org>wrote:
>
>>
>>
>>
>> On Thu, Feb 6, 2014 at 9:52 AM, Sebastien Blanc <scm.blanc at gmail.com>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 <scm.blanc at gmail.com>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: <CAAg5f2Q7ixBkgRHHcornVtbgRGLjx-W8_M3XKb=Zkb5aPJVw7w@mail.gmail.com>
References: <CAD_dpu0S5UyPJzf7zaS6hFrgPgBU6tORcmSPKFBP6XXJ5BxT5g@mail.gmail.com>
	<CAAg5f2SF5H8UAxjacg65w4PwNEVuj3kehZF-C4NJWS=wmV+5MQ@mail.gmail.com>
	<CAD_dpu3KJmiNCmgX3b7U2oNM0ZFiHETkT+XFJ8Wpe_L3=FHbPw@mail.gmail.com>
	<CAAg5f2RDwiF2FbfhVDu6_yEGnXvS_vunPYU6yzVpQ8aHhq7Upw@mail.gmail.com>
	<CAD_dpu3awVbB7vMVK2iZniZ2eC73ob=2U-69gyRqqWqrAei13w@mail.gmail.com>
	<CAAg5f2Q7ixBkgRHHcornVtbgRGLjx-W8_M3XKb=Zkb5aPJVw7w@mail.gmail.com>
Message-ID: <CAD_dpu3Vm5EjSysGePXmoHrQvCbkm-5Kdi13M_f-MO56-niSrQ@mail.gmail.com>

On Thu, Feb 6, 2014 at 10:11 AM, Matthias Wessendorf <matzew at apache.org>wrote:

>
>
>
> On Thu, Feb 6, 2014 at 10:07 AM, Sebastien Blanc <scm.blanc at gmail.com>wrote:
>
>>
>>
>>
>> On Thu, Feb 6, 2014 at 9:57 AM, Matthias Wessendorf <matzew at apache.org>wrote:
>>
>>>
>>>
>>>
>>> On Thu, Feb 6, 2014 at 9:52 AM, Sebastien Blanc <scm.blanc at gmail.com>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 <scm.blanc at gmail.com>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: <CAD_dpu3Vm5EjSysGePXmoHrQvCbkm-5Kdi13M_f-MO56-niSrQ@mail.gmail.com>
References: <CAD_dpu0S5UyPJzf7zaS6hFrgPgBU6tORcmSPKFBP6XXJ5BxT5g@mail.gmail.com>
	<CAAg5f2SF5H8UAxjacg65w4PwNEVuj3kehZF-C4NJWS=wmV+5MQ@mail.gmail.com>
	<CAD_dpu3KJmiNCmgX3b7U2oNM0ZFiHETkT+XFJ8Wpe_L3=FHbPw@mail.gmail.com>
	<CAAg5f2RDwiF2FbfhVDu6_yEGnXvS_vunPYU6yzVpQ8aHhq7Upw@mail.gmail.com>
	<CAD_dpu3awVbB7vMVK2iZniZ2eC73ob=2U-69gyRqqWqrAei13w@mail.gmail.com>
	<CAAg5f2Q7ixBkgRHHcornVtbgRGLjx-W8_M3XKb=Zkb5aPJVw7w@mail.gmail.com>
	<CAD_dpu3Vm5EjSysGePXmoHrQvCbkm-5Kdi13M_f-MO56-niSrQ@mail.gmail.com>
Message-ID: <CAAg5f2ShJasUXx1SF7YZQnix3m33ngp-jM4QR6Pc1zt3xMOhxA@mail.gmail.com>

On Thu, Feb 6, 2014 at 10:21 AM, Sebastien Blanc <scm.blanc at gmail.com>wrote:

>
>
>
> On Thu, Feb 6, 2014 at 10:11 AM, Matthias Wessendorf <matzew at apache.org>wrote:
>
>>
>>
>>
>> On Thu, Feb 6, 2014 at 10:07 AM, Sebastien Blanc <scm.blanc at gmail.com>wrote:
>>
>>>
>>>
>>>
>>> On Thu, Feb 6, 2014 at 9:57 AM, Matthias Wessendorf <matzew at apache.org>wrote:
>>>
>>>>
>>>>
>>>>
>>>> On Thu, Feb 6, 2014 at 9:52 AM, Sebastien Blanc <scm.blanc at gmail.com>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 <scm.blanc at gmail.com>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: <CAAg5f2ShJasUXx1SF7YZQnix3m33ngp-jM4QR6Pc1zt3xMOhxA@mail.gmail.com>
References: <CAD_dpu0S5UyPJzf7zaS6hFrgPgBU6tORcmSPKFBP6XXJ5BxT5g@mail.gmail.com>
	<CAAg5f2SF5H8UAxjacg65w4PwNEVuj3kehZF-C4NJWS=wmV+5MQ@mail.gmail.com>
	<CAD_dpu3KJmiNCmgX3b7U2oNM0ZFiHETkT+XFJ8Wpe_L3=FHbPw@mail.gmail.com>
	<CAAg5f2RDwiF2FbfhVDu6_yEGnXvS_vunPYU6yzVpQ8aHhq7Upw@mail.gmail.com>
	<CAD_dpu3awVbB7vMVK2iZniZ2eC73ob=2U-69gyRqqWqrAei13w@mail.gmail.com>
	<CAAg5f2Q7ixBkgRHHcornVtbgRGLjx-W8_M3XKb=Zkb5aPJVw7w@mail.gmail.com>
	<CAD_dpu3Vm5EjSysGePXmoHrQvCbkm-5Kdi13M_f-MO56-niSrQ@mail.gmail.com>
	<CAAg5f2ShJasUXx1SF7YZQnix3m33ngp-jM4QR6Pc1zt3xMOhxA@mail.gmail.com>
Message-ID: <CAD_dpu1N-vB21bJMKYQmKszhGXoHcgv9J4qdaTnt2O7hKvvW_Q@mail.gmail.com>

On Thu, Feb 6, 2014 at 10:24 AM, Matthias Wessendorf <matzew at apache.org>wrote:

>
>
>
> On Thu, Feb 6, 2014 at 10:21 AM, Sebastien Blanc <scm.blanc at gmail.com>wrote:
>
>>
>>
>>
>> On Thu, Feb 6, 2014 at 10:11 AM, Matthias Wessendorf <matzew at apache.org>wrote:
>>
>>>
>>>
>>>
>>> On Thu, Feb 6, 2014 at 10:07 AM, Sebastien Blanc <scm.blanc at gmail.com>wrote:
>>>
>>>>
>>>>
>>>>
>>>> On Thu, Feb 6, 2014 at 9:57 AM, Matthias Wessendorf <matzew at apache.org>wrote:
>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Feb 6, 2014 at 9:52 AM, Sebastien Blanc <scm.blanc at gmail.com>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 <scm.blanc at gmail.com
>>>>>>> > 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: <CAAg5f2SXkuuvisvFVjtFATSSYxQuxt459mEFkRO17pzEuo3A6A@mail.gmail.com>
References: <CAD_dpu2LGDXWLBffxNsUKR8yhwT=umZ0edgEnbxymV6tqdqmmw@mail.gmail.com>
	<CAAg5f2SXkuuvisvFVjtFATSSYxQuxt459mEFkRO17pzEuo3A6A@mail.gmail.com>
Message-ID: <CAAg5f2Sb5wV2A=6wOEKCe_mn9Z=1_c_nOZo=26M20b4osgawzQ@mail.gmail.com>

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.


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: <CAAg5f2Sb5wV2A=6wOEKCe_mn9Z=1_c_nOZo=26M20b4osgawzQ@mail.gmail.com>
References: <CAD_dpu2LGDXWLBffxNsUKR8yhwT=umZ0edgEnbxymV6tqdqmmw@mail.gmail.com>
	<CAAg5f2SXkuuvisvFVjtFATSSYxQuxt459mEFkRO17pzEuo3A6A@mail.gmail.com>
	<CAAg5f2Sb5wV2A=6wOEKCe_mn9Z=1_c_nOZo=26M20b4osgawzQ@mail.gmail.com>
Message-ID: <CAFJm-3Ek3Pw-jvrcD8=uZJT26SxxGNqv1XVx7Y6nEbZCQYP_1A@mail.gmail.com>

+1 Sounds reasonable I think.


On 6 February 2014 12:28, 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.
>
>
> 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: <EDCB268A-FB02-4676-B14A-6297FB7DB4AE@gmail.com>
	<CAKVvow_SBRYsO4xj2VMNx72hxVOLgoUTbj_CxKJzu8MAWGr=2A@mail.gmail.com>
	<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 <corinnekrych at gmail.com> wrote:

> 
> On 05 Feb 2014, at 16:04, Summers Pittman <supittma at redhat.com> 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 <cvasilak at gmail.com> 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
> 



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: <CAAg5f2Sb5wV2A=6wOEKCe_mn9Z=1_c_nOZo=26M20b4osgawzQ@mail.gmail.com>
References: <CAD_dpu2LGDXWLBffxNsUKR8yhwT=umZ0edgEnbxymV6tqdqmmw@mail.gmail.com>
	<CAAg5f2SXkuuvisvFVjtFATSSYxQuxt459mEFkRO17pzEuo3A6A@mail.gmail.com>
	<CAAg5f2Sb5wV2A=6wOEKCe_mn9Z=1_c_nOZo=26M20b4osgawzQ@mail.gmail.com>
Message-ID: <CAD_dpu3P36tPJgawpdp5i3TQMuMkUg=NzdVLvvoZC24T6tzLtQ@mail.gmail.com>

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-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: <CAD_dpu3P36tPJgawpdp5i3TQMuMkUg=NzdVLvvoZC24T6tzLtQ@mail.gmail.com>
References: <CAD_dpu2LGDXWLBffxNsUKR8yhwT=umZ0edgEnbxymV6tqdqmmw@mail.gmail.com>
	<CAAg5f2SXkuuvisvFVjtFATSSYxQuxt459mEFkRO17pzEuo3A6A@mail.gmail.com>
	<CAAg5f2Sb5wV2A=6wOEKCe_mn9Z=1_c_nOZo=26M20b4osgawzQ@mail.gmail.com>
	<CAD_dpu3P36tPJgawpdp5i3TQMuMkUg=NzdVLvvoZC24T6tzLtQ@mail.gmail.com>
Message-ID: <CAAg5f2RdD0hJgybRYo6VMoRqba9T_SLHD0Aab5tzok3RUbmmHA@mail.gmail.com>

On Thu, Feb 6, 2014 at 3:11 PM, Sebastien Blanc <scm.blanc at gmail.com> 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-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: <EDCB268A-FB02-4676-B14A-6297FB7DB4AE@gmail.com>
	<CAKVvow_SBRYsO4xj2VMNx72hxVOLgoUTbj_CxKJzu8MAWGr=2A@mail.gmail.com>
	<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: <CAAg5f2T509ZKg8A3B_=atWL6P7Cs9H1Kmxk0PWE86Rtm7+tUKg@mail.gmail.com>

On Thu, Feb 6, 2014 at 2:32 PM, Corinne Krych <corinnekrych at gmail.com>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 <corinnekrych at gmail.com> wrote:
>
> >
> > On 05 Feb 2014, at 16:04, Summers Pittman <supittma at redhat.com> 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 <cvasilak at gmail.com>
> 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: <EDCB268A-FB02-4676-B14A-6297FB7DB4AE@gmail.com>
	<CAKVvow_SBRYsO4xj2VMNx72hxVOLgoUTbj_CxKJzu8MAWGr=2A@mail.gmail.com>
	<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: <ADF6785E-D56D-4090-B55B-4B6719F3E055@gmail.com>


On Feb 6, 2014, at 3:32 PM, Corinne Krych <corinnekrych at gmail.com> 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 <corinnekrych at gmail.com> wrote:
> 
>> 
>> On 05 Feb 2014, at 16:04, Summers Pittman <supittma at redhat.com> 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 <cvasilak at gmail.com> 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



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: <B74C9D63-59D6-457E-AF39-E4177320F7D2@gmail.com>
	<CAAg5f2R09nBCZES4N4PkcrkOqqvPR3fObZpMMcuX5udsC7U+vw@mail.gmail.com>
	<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" <corinnekrych at gmail.com>
> A: "AeroGear Developer Mailing List" <aerogear-dev at lists.jboss.org>
> 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 <matzew at apache.org> wrote:
> 
> > 
> > 
> > 
> > On Tue, Feb 4, 2014 at 9:11 AM, Corinne Krych <corinnekrych at gmail.com>
> > 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: <B74C9D63-59D6-457E-AF39-E4177320F7D2@gmail.com>
	<CAAg5f2R09nBCZES4N4PkcrkOqqvPR3fObZpMMcuX5udsC7U+vw@mail.gmail.com>
	<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 <avibelli at redhat.com> 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" <corinnekrych at gmail.com>
>> A: "AeroGear Developer Mailing List" <aerogear-dev at lists.jboss.org>
>> 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 <matzew at apache.org> wrote:
>> 
>>> 
>>> 
>>> 
>>> On Tue, Feb 4, 2014 at 9:11 AM, Corinne Krych <corinnekrych at gmail.com>
>>> 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: <CAD_dpu1UmMicopDX9iH5ZKLufFnE3N7A5ZPjVjBQbSUviOm-SQ@mail.gmail.com>

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: <CAD_dpu1UmMicopDX9iH5ZKLufFnE3N7A5ZPjVjBQbSUviOm-SQ@mail.gmail.com>
References: <CAD_dpu1UmMicopDX9iH5ZKLufFnE3N7A5ZPjVjBQbSUviOm-SQ@mail.gmail.com>
Message-ID: <CAAg5f2RjUhneG5o1_U3dZ-wWQWKgZj=jp74p_4cyBUn5ABjqcQ@mail.gmail.com>

On Sun, Feb 9, 2014 at 12:06 PM, Sebastien Blanc <scm.blanc at gmail.com>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: <CAAg5f2RjUhneG5o1_U3dZ-wWQWKgZj=jp74p_4cyBUn5ABjqcQ@mail.gmail.com>
References: <CAD_dpu1UmMicopDX9iH5ZKLufFnE3N7A5ZPjVjBQbSUviOm-SQ@mail.gmail.com>
	<CAAg5f2RjUhneG5o1_U3dZ-wWQWKgZj=jp74p_4cyBUn5ABjqcQ@mail.gmail.com>
Message-ID: <CAD_dpu04jDzSWr-O2n7o=P36k-ti2yZFesk3zWONp8pwObZ6oQ@mail.gmail.com>

On Sun, Feb 9, 2014 at 2:14 PM, Matthias Wessendorf <matzew at apache.org>wrote:

>
>
>
> On Sun, Feb 9, 2014 at 12:06 PM, Sebastien Blanc <scm.blanc at gmail.com>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: <etPan.52f89596.2ae8944a.129c8@animus>

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: <CAFJm-3HCabmPt6740WiGafkAvAS9EQL1jmj3yL9XqzQL6DOKYQ@mail.gmail.com>

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<T, ID> {

    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: <CAFJm-3HCabmPt6740WiGafkAvAS9EQL1jmj3yL9XqzQL6DOKYQ@mail.gmail.com>
References: <CAFJm-3HCabmPt6740WiGafkAvAS9EQL1jmj3yL9XqzQL6DOKYQ@mail.gmail.com>
Message-ID: <63F4856A-7D07-4E5F-B947-D42E603AB40B@gmail.com>


On 10 Feb 2014, at 13:41, Daniel Bevenius <daniel.bevenius at gmail.com> 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<T, ID> {

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: <CAFJm-3HCabmPt6740WiGafkAvAS9EQL1jmj3yL9XqzQL6DOKYQ@mail.gmail.com>
	<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 <corinnekrych at gmail.com> wrote:

> 
> On 10 Feb 2014, at 13:41, Daniel Bevenius <daniel.bevenius at gmail.com> 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<T, ID> {
> 
> 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: <etPan.52f8d5af.625558ec.129c8@animus>

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: <DB875886-BB14-4B2D-A135-4430D25CA7EA@redhat.com>


On Feb 10, 2014, at 6:38 AM, Corinne Krych <corinnekrych at gmail.com> 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: <DB875886-BB14-4B2D-A135-4430D25CA7EA@redhat.com>
References: <49EB4088-E00E-40F2-A231-E294A8687171@gmail.com>
	<DB875886-BB14-4B2D-A135-4430D25CA7EA@redhat.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 <lholmqui at redhat.com> wrote:

> 
> On Feb 10, 2014, at 6:38 AM, Corinne Krych <corinnekrych at gmail.com> 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>
	<DB875886-BB14-4B2D-A135-4430D25CA7EA@redhat.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 <corinnekrych at gmail.com> 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 <lholmqui at redhat.com> wrote:
> 
>> 
>> On Feb 10, 2014, at 6:38 AM, Corinne Krych <corinnekrych at gmail.com> 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: <CAD_dpu04jDzSWr-O2n7o=P36k-ti2yZFesk3zWONp8pwObZ6oQ@mail.gmail.com>
References: <CAD_dpu1UmMicopDX9iH5ZKLufFnE3N7A5ZPjVjBQbSUviOm-SQ@mail.gmail.com>
	<CAAg5f2RjUhneG5o1_U3dZ-wWQWKgZj=jp74p_4cyBUn5ABjqcQ@mail.gmail.com>
	<CAD_dpu04jDzSWr-O2n7o=P36k-ti2yZFesk3zWONp8pwObZ6oQ@mail.gmail.com>
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 <scm.blanc at gmail.com> wrote:

> 
> 
> 
> On Sun, Feb 9, 2014 at 2:14 PM, Matthias Wessendorf <matzew at apache.org> wrote:
> 
> 
> 
> On Sun, Feb 9, 2014 at 12:06 PM, Sebastien Blanc <scm.blanc at gmail.com> 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: <CAD_dpu1UmMicopDX9iH5ZKLufFnE3N7A5ZPjVjBQbSUviOm-SQ@mail.gmail.com>
	<CAAg5f2RjUhneG5o1_U3dZ-wWQWKgZj=jp74p_4cyBUn5ABjqcQ@mail.gmail.com>
	<CAD_dpu04jDzSWr-O2n7o=P36k-ti2yZFesk3zWONp8pwObZ6oQ@mail.gmail.com>
	<3AD4DCCE-F0D6-4870-9632-EA3B83720B0A@redhat.com>
Message-ID: <CAD_dpu3hYW-YJBVXEX3Sk03YyPkGuWRhKHg5HND8UDMOhcoYcA@mail.gmail.com>

On Mon, Feb 10, 2014 at 2:23 PM, Lucas Holmquist <lholmqui at redhat.com>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 <scm.blanc at gmail.com> wrote:
>
>
>
>
> On Sun, Feb 9, 2014 at 2:14 PM, Matthias Wessendorf <matzew at apache.org>wrote:
>
>>
>>
>>
>> On Sun, Feb 9, 2014 at 12:06 PM, Sebastien Blanc <scm.blanc at gmail.com>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: <etPan.52d539ab.6b8b4567.44fe@Daniels-MacBook-Air.local>
	<996ACE2C-F429-4224-9E3D-E9836DFEB0DD@gmail.com>
Message-ID: <etPan.52f8e66a.79e2a9e3.13e00@Daniels-MacBook-Air.local>

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 <daniel at passos.me> 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>	<DB875886-BB14-4B2D-A135-4430D25CA7EA@redhat.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 <corinnekrych at gmail.com> 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 <lholmqui at redhat.com> wrote:
>>
>>> On Feb 10, 2014, at 6:38 AM, Corinne Krych <corinnekrych at gmail.com> 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: <CAFJm-3HCabmPt6740WiGafkAvAS9EQL1jmj3yL9XqzQL6DOKYQ@mail.gmail.com>
References: <CAFJm-3HCabmPt6740WiGafkAvAS9EQL1jmj3yL9XqzQL6DOKYQ@mail.gmail.com>
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<T, ID> {
>      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: <CAFJm-3HCabmPt6740WiGafkAvAS9EQL1jmj3yL9XqzQL6DOKYQ@mail.gmail.com>
	<52F8E70E.6000802@redhat.com>
Message-ID: <B02B8E9C-69DB-42D9-A39A-61728BF8BB91@gmail.com>


On 10 Feb 2014, at 15:49, Summers Pittman <supittma at redhat.com> 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<T, ID> {
>>     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: <B02B8E9C-69DB-42D9-A39A-61728BF8BB91@gmail.com>
References: <CAFJm-3HCabmPt6740WiGafkAvAS9EQL1jmj3yL9XqzQL6DOKYQ@mail.gmail.com>	<52F8E70E.6000802@redhat.com>
	<B02B8E9C-69DB-42D9-A39A-61728BF8BB91@gmail.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 <supittma at redhat.com> 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<T, ID> {
>>>      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>	<DB875886-BB14-4B2D-A135-4430D25CA7EA@redhat.com>	<7ED4C154-86DB-4E10-9AB0-2232A93F9800@gmail.com>
	<8EB9D831-421D-40B3-97BB-9F6FB1F968A1@redhat.com>
	<52F8E6BA.1030408@redhat.com>
Message-ID: <A39710C9-D14F-4A63-9AB2-630C444DF053@redhat.com>


On Feb 10, 2014, at 9:48 AM, Summers Pittman <supittma at redhat.com> wrote:

> On 02/10/2014 08:46 AM, Lucas Holmquist wrote:
>> On Feb 10, 2014, at 8:44 AM, Corinne Krych <corinnekrych at gmail.com> 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 <lholmqui at redhat.com> wrote:
>>> 
>>>> On Feb 10, 2014, at 6:38 AM, Corinne Krych <corinnekrych at gmail.com> 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: <CAFJm-3HCabmPt6740WiGafkAvAS9EQL1jmj3yL9XqzQL6DOKYQ@mail.gmail.com>	<52F8E70E.6000802@redhat.com>
	<B02B8E9C-69DB-42D9-A39A-61728BF8BB91@gmail.com>
	<52F8EB90.2020209@redhat.com>
Message-ID: <C70B695F-6427-45AE-8895-03626CD08D08@gmail.com>


On 10 Feb 2014, at 16:09, Summers Pittman <supittma at redhat.com> wrote:

> On 02/10/2014 10:06 AM, Corinne Krych wrote:
>> On 10 Feb 2014, at 15:49, Summers Pittman <supittma at redhat.com> 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<T, ID> {
>>>>     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: <A39710C9-D14F-4A63-9AB2-630C444DF053@redhat.com>
References: <49EB4088-E00E-40F2-A231-E294A8687171@gmail.com>	<DB875886-BB14-4B2D-A135-4430D25CA7EA@redhat.com>	<7ED4C154-86DB-4E10-9AB0-2232A93F9800@gmail.com>
	<8EB9D831-421D-40B3-97BB-9F6FB1F968A1@redhat.com>
	<52F8E6BA.1030408@redhat.com>
	<A39710C9-D14F-4A63-9AB2-630C444DF053@redhat.com>
Message-ID: <9323CFD7-059A-44AF-B35C-F1F422B34438@gmail.com>


On 10 Feb 2014, at 16:24, Lucas Holmquist <lholmqui at redhat.com> wrote:

> 
> On Feb 10, 2014, at 9:48 AM, Summers Pittman <supittma at redhat.com> wrote:
> 
>> On 02/10/2014 08:46 AM, Lucas Holmquist wrote:
>>> On Feb 10, 2014, at 8:44 AM, Corinne Krych <corinnekrych at gmail.com> 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 <lholmqui at redhat.com> wrote:
>>>> 
>>>>> On Feb 10, 2014, at 6:38 AM, Corinne Krych <corinnekrych at gmail.com> 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: <A39710C9-D14F-4A63-9AB2-630C444DF053@redhat.com>
References: <49EB4088-E00E-40F2-A231-E294A8687171@gmail.com>	<DB875886-BB14-4B2D-A135-4430D25CA7EA@redhat.com>	<7ED4C154-86DB-4E10-9AB0-2232A93F9800@gmail.com>	<8EB9D831-421D-40B3-97BB-9F6FB1F968A1@redhat.com>	<52F8E6BA.1030408@redhat.com>
	<A39710C9-D14F-4A63-9AB2-630C444DF053@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 <supittma at redhat.com> wrote:
>
>> On 02/10/2014 08:46 AM, Lucas Holmquist wrote:
>>> On Feb 10, 2014, at 8:44 AM, Corinne Krych <corinnekrych at gmail.com> 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 <lholmqui at redhat.com> wrote:
>>>>
>>>>> On Feb 10, 2014, at 6:38 AM, Corinne Krych <corinnekrych at gmail.com> 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: <CAD_dpu3hYW-YJBVXEX3Sk03YyPkGuWRhKHg5HND8UDMOhcoYcA@mail.gmail.com>
References: <CAD_dpu1UmMicopDX9iH5ZKLufFnE3N7A5ZPjVjBQbSUviOm-SQ@mail.gmail.com>
	<CAAg5f2RjUhneG5o1_U3dZ-wWQWKgZj=jp74p_4cyBUn5ABjqcQ@mail.gmail.com>
	<CAD_dpu04jDzSWr-O2n7o=P36k-ti2yZFesk3zWONp8pwObZ6oQ@mail.gmail.com>
	<3AD4DCCE-F0D6-4870-9632-EA3B83720B0A@redhat.com>
	<CAD_dpu3hYW-YJBVXEX3Sk03YyPkGuWRhKHg5HND8UDMOhcoYcA@mail.gmail.com>
Message-ID: <CAAg5f2RPZGxUkp46NTW-6O6BTsHgC4AxBKL3SCyWMbrG=Cj7=A@mail.gmail.com>

On Monday, February 10, 2014, Sebastien Blanc <scm.blanc at gmail.com> wrote:

>
>
>
> On Mon, Feb 10, 2014 at 2:23 PM, Lucas Holmquist <lholmqui at redhat.com<javascript:_e(%7B%7D,'cvml','lholmqui at redhat.com');>
> > 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 <scm.blanc at gmail.com> wrote:
>
>
>
>
> On Sun, Feb 9, 2014 at 2:14 PM, Matthias Wessendorf <matzew at apache.org>wrote:
>
>
>
>
> On Sun, Feb 9, 2014 at 12:06 PM, Sebastien Blanc <scm.blanc at gmail.com>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 <supittma at redhat.com> 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 <supittma at redhat.com> 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 <supittma at redhat.com> 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: <etPan.52f89596.2ae8944a.129c8@animus>
References: <etPan.52f89596.2ae8944a.129c8@animus>
Message-ID: <CAKVvow9+xCYFhzZhRq3enNVSqjdwt+MuUMersna4Bq9V-n0R9w@mail.gmail.com>

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 <bruno at abstractj.org>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: <BBF35459-3BB5-4D51-9365-E24562ACB006@gmail.com>

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: <BBF35459-3BB5-4D51-9365-E24562ACB006@gmail.com>
References: <BBF35459-3BB5-4D51-9365-E24562ACB006@gmail.com>
Message-ID: <etPan.52fa0a98.6b8b4567.36cc@animus>

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: <etPan.52fa0a98.6b8b4567.36cc@animus>
References: <BBF35459-3BB5-4D51-9365-E24562ACB006@gmail.com>
	<etPan.52fa0a98.6b8b4567.36cc@animus>
Message-ID: <678862A7-C3D0-4C35-A78D-BE6F2C817D23@gmail.com>

On Feb 11, 2014, at 1:33 PM, Bruno Oliveira <bruno at abstractj.org> 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: <BBF35459-3BB5-4D51-9365-E24562ACB006@gmail.com>
	<etPan.52fa0a98.6b8b4567.36cc@animus>
	<678862A7-C3D0-4C35-A78D-BE6F2C817D23@gmail.com>
Message-ID: <etPan.52fa146f.327b23c6.36cc@animus>

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: <CAL8vO=dJb=yp9ZXO=cdYZWuA1jGak+o9FP=r+UKg=S6Rws4uMw@mail.gmail.com>

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: <CAAg5f2RdD0hJgybRYo6VMoRqba9T_SLHD0Aab5tzok3RUbmmHA@mail.gmail.com>
References: <CAD_dpu2LGDXWLBffxNsUKR8yhwT=umZ0edgEnbxymV6tqdqmmw@mail.gmail.com>
	<CAAg5f2SXkuuvisvFVjtFATSSYxQuxt459mEFkRO17pzEuo3A6A@mail.gmail.com>
	<CAAg5f2Sb5wV2A=6wOEKCe_mn9Z=1_c_nOZo=26M20b4osgawzQ@mail.gmail.com>
	<CAD_dpu3P36tPJgawpdp5i3TQMuMkUg=NzdVLvvoZC24T6tzLtQ@mail.gmail.com>
	<CAAg5f2RdD0hJgybRYo6VMoRqba9T_SLHD0Aab5tzok3RUbmmHA@mail.gmail.com>
Message-ID: <CAD_dpu0ajLXXiX7ammBRhoc7rjEq0QuoWErR2M2T-Zkw7GO7fA@mail.gmail.com>

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 <matzew at apache.org>wrote:

>
>
>
> On Thu, Feb 6, 2014 at 3:11 PM, Sebastien Blanc <scm.blanc at gmail.com>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-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: <CAD_dpu0ajLXXiX7ammBRhoc7rjEq0QuoWErR2M2T-Zkw7GO7fA@mail.gmail.com>
References: <CAD_dpu2LGDXWLBffxNsUKR8yhwT=umZ0edgEnbxymV6tqdqmmw@mail.gmail.com>
	<CAAg5f2SXkuuvisvFVjtFATSSYxQuxt459mEFkRO17pzEuo3A6A@mail.gmail.com>
	<CAAg5f2Sb5wV2A=6wOEKCe_mn9Z=1_c_nOZo=26M20b4osgawzQ@mail.gmail.com>
	<CAD_dpu3P36tPJgawpdp5i3TQMuMkUg=NzdVLvvoZC24T6tzLtQ@mail.gmail.com>
	<CAAg5f2RdD0hJgybRYo6VMoRqba9T_SLHD0Aab5tzok3RUbmmHA@mail.gmail.com>
	<CAD_dpu0ajLXXiX7ammBRhoc7rjEq0QuoWErR2M2T-Zkw7GO7fA@mail.gmail.com>
Message-ID: <CAD_dpu3Y547vmyM_jM2dox=agD+_-eq_mi6zi9dSFpicCqSyiw@mail.gmail.com>

On Tue, Feb 11, 2014 at 7:15 PM, Sebastien Blanc <scm.blanc at gmail.com>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 <matzew at apache.org>wrote:
>
>>
>>
>>
>> On Thu, Feb 6, 2014 at 3:11 PM, Sebastien Blanc <scm.blanc at gmail.com>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
>>
>
>
-------------- 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: <CAD_dpu3Y547vmyM_jM2dox=agD+_-eq_mi6zi9dSFpicCqSyiw@mail.gmail.com>
References: <CAD_dpu2LGDXWLBffxNsUKR8yhwT=umZ0edgEnbxymV6tqdqmmw@mail.gmail.com>
	<CAAg5f2SXkuuvisvFVjtFATSSYxQuxt459mEFkRO17pzEuo3A6A@mail.gmail.com>
	<CAAg5f2Sb5wV2A=6wOEKCe_mn9Z=1_c_nOZo=26M20b4osgawzQ@mail.gmail.com>
	<CAD_dpu3P36tPJgawpdp5i3TQMuMkUg=NzdVLvvoZC24T6tzLtQ@mail.gmail.com>
	<CAAg5f2RdD0hJgybRYo6VMoRqba9T_SLHD0Aab5tzok3RUbmmHA@mail.gmail.com>
	<CAD_dpu0ajLXXiX7ammBRhoc7rjEq0QuoWErR2M2T-Zkw7GO7fA@mail.gmail.com>
	<CAD_dpu3Y547vmyM_jM2dox=agD+_-eq_mi6zi9dSFpicCqSyiw@mail.gmail.com>
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 <scm.blanc at gmail.com> wrote:

> 
> 
> 
> On Tue, Feb 11, 2014 at 7:15 PM, Sebastien Blanc <scm.blanc at gmail.com> 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 <matzew at apache.org> wrote:
> 
> 
> 
> On Thu, Feb 6, 2014 at 3:11 PM, Sebastien Blanc <scm.blanc at gmail.com> 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-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: <etPan.52fb820d.625558ec.36cc@animus>

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: <a binary stream or just plain 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:
		- 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: <CAD_dpu2LGDXWLBffxNsUKR8yhwT=umZ0edgEnbxymV6tqdqmmw@mail.gmail.com>
	<CAAg5f2SXkuuvisvFVjtFATSSYxQuxt459mEFkRO17pzEuo3A6A@mail.gmail.com>
	<CAAg5f2Sb5wV2A=6wOEKCe_mn9Z=1_c_nOZo=26M20b4osgawzQ@mail.gmail.com>
	<CAD_dpu3P36tPJgawpdp5i3TQMuMkUg=NzdVLvvoZC24T6tzLtQ@mail.gmail.com>
	<CAAg5f2RdD0hJgybRYo6VMoRqba9T_SLHD0Aab5tzok3RUbmmHA@mail.gmail.com>
	<CAD_dpu0ajLXXiX7ammBRhoc7rjEq0QuoWErR2M2T-Zkw7GO7fA@mail.gmail.com>
	<CAD_dpu3Y547vmyM_jM2dox=agD+_-eq_mi6zi9dSFpicCqSyiw@mail.gmail.com>
	<9B70BDB9-4774-4BF0-9FF7-5213185E4F52@redhat.com>
Message-ID: <CAAg5f2RBqvS+6n3=qBnciAmx_VGn5-2U31Y0+dJXd9bZCxrjvQ@mail.gmail.com>

What about using the encodeURIComponent() function ?


On Wed, Feb 12, 2014 at 2:30 PM, Lucas Holmquist <lholmqui at redhat.com>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 <scm.blanc at gmail.com> wrote:
>
>
>
>
> On Tue, Feb 11, 2014 at 7:15 PM, Sebastien Blanc <scm.blanc at gmail.com>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 <matzew at apache.org>wrote:
>>
>>>
>>>
>>>
>>> On Thu, Feb 6, 2014 at 3:11 PM, Sebastien Blanc <scm.blanc at gmail.com>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
-------------- 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: <CAAg5f2QGk-1h=Z9OgU3Z_-J2ouRr4woTMwZ66c9YCWasgSDebw@mail.gmail.com>

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: <CAAg5f2QGk-1h=Z9OgU3Z_-J2ouRr4woTMwZ66c9YCWasgSDebw@mail.gmail.com>
References: <CAAg5f2QGk-1h=Z9OgU3Z_-J2ouRr4woTMwZ66c9YCWasgSDebw@mail.gmail.com>
Message-ID: <CAD_dpu3sAYNDWCFBfE3VXgahcDFX2b3pMP6O+0hjQfnyneMK3g@mail.gmail.com>

+1


On Wed, Feb 12, 2014 at 5:19 PM, Matthias Wessendorf <matzew at apache.org>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: <CAAg5f2RBqvS+6n3=qBnciAmx_VGn5-2U31Y0+dJXd9bZCxrjvQ@mail.gmail.com>
References: <CAD_dpu2LGDXWLBffxNsUKR8yhwT=umZ0edgEnbxymV6tqdqmmw@mail.gmail.com>
	<CAAg5f2SXkuuvisvFVjtFATSSYxQuxt459mEFkRO17pzEuo3A6A@mail.gmail.com>
	<CAAg5f2Sb5wV2A=6wOEKCe_mn9Z=1_c_nOZo=26M20b4osgawzQ@mail.gmail.com>
	<CAD_dpu3P36tPJgawpdp5i3TQMuMkUg=NzdVLvvoZC24T6tzLtQ@mail.gmail.com>
	<CAAg5f2RdD0hJgybRYo6VMoRqba9T_SLHD0Aab5tzok3RUbmmHA@mail.gmail.com>
	<CAD_dpu0ajLXXiX7ammBRhoc7rjEq0QuoWErR2M2T-Zkw7GO7fA@mail.gmail.com>
	<CAD_dpu3Y547vmyM_jM2dox=agD+_-eq_mi6zi9dSFpicCqSyiw@mail.gmail.com>
	<9B70BDB9-4774-4BF0-9FF7-5213185E4F52@redhat.com>
	<CAAg5f2RBqvS+6n3=qBnciAmx_VGn5-2U31Y0+dJXd9bZCxrjvQ@mail.gmail.com>
Message-ID: <CAD_dpu3VJzGUPijka6rFv+QrKREUO=jG3vPz7i3evuo=yNhXmw@mail.gmail.com>

On Wed, Feb 12, 2014 at 4:56 PM, Matthias Wessendorf <matzew at apache.org>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 <lholmqui at redhat.com>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 <scm.blanc at gmail.com> wrote:
>>
>>
>>
>>
>> On Tue, Feb 11, 2014 at 7:15 PM, Sebastien Blanc <scm.blanc at gmail.com>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 <matzew at apache.org>wrote:
>>>
>>>>
>>>>
>>>>
>>>> On Thu, Feb 6, 2014 at 3:11 PM, Sebastien Blanc <scm.blanc at gmail.com>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: <CAAg5f2QGk-1h=Z9OgU3Z_-J2ouRr4woTMwZ66c9YCWasgSDebw@mail.gmail.com>
References: <CAAg5f2QGk-1h=Z9OgU3Z_-J2ouRr4woTMwZ66c9YCWasgSDebw@mail.gmail.com>
Message-ID: <BB6BAB54-A375-48E9-9863-0824EE585AF3@redhat.com>

+1 sounds reasonable 
On Feb 12, 2014, at 11:19 AM, Matthias Wessendorf <matzew at apache.org> 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: <CAAg5f2QGk-1h=Z9OgU3Z_-J2ouRr4woTMwZ66c9YCWasgSDebw@mail.gmail.com>
References: <CAAg5f2QGk-1h=Z9OgU3Z_-J2ouRr4woTMwZ66c9YCWasgSDebw@mail.gmail.com>
Message-ID: <20140213102036.0682df41@kapy-ntb-x220>

+1, makes perfect sense to me.

On Wed, 12 Feb 2014 17:19:15 +0100
Matthias Wessendorf <matzew at apache.org> 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: <CAL8vO=e9k+ZESnmfZJYxG5p89QhM_tiLPz7ghYWHdgZ3wZRkbg@mail.gmail.com>

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: <CAL8vO=e9k+ZESnmfZJYxG5p89QhM_tiLPz7ghYWHdgZ3wZRkbg@mail.gmail.com>
References: <CAL8vO=e9k+ZESnmfZJYxG5p89QhM_tiLPz7ghYWHdgZ3wZRkbg@mail.gmail.com>
Message-ID: <D0B29469-07BD-4944-BA3F-349707B55FC6@redhat.com>

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: <etPan.52f8d5af.625558ec.129c8@animus>
References: <etPan.52f8d5af.625558ec.129c8@animus>
Message-ID: <etPan.52fc9995.643c9869.5546@animus>

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: <D0B29469-07BD-4944-BA3F-349707B55FC6@redhat.com>
References: <CAL8vO=e9k+ZESnmfZJYxG5p89QhM_tiLPz7ghYWHdgZ3wZRkbg@mail.gmail.com>
	<D0B29469-07BD-4944-BA3F-349707B55FC6@redhat.com>
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 <edewit at redhat.com> 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: <CAL8vO=e9k+ZESnmfZJYxG5p89QhM_tiLPz7ghYWHdgZ3wZRkbg@mail.gmail.com>
	<D0B29469-07BD-4944-BA3F-349707B55FC6@redhat.com>
	<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 <kpiwko at redhat.com> 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 <edewit at redhat.com> 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: <CAAg5f2QwRM8FRzf3Rxrc7yuQJKRyzLwoh2ZQJ15vJ=BNJbrbJg@mail.gmail.com>

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: <CAAg5f2RNC3jWJDM-EEPCMfZPDv6+8NCjf15yWo8FVFqfuPZxJg@mail.gmail.com>

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: <CAD_dpu2LGDXWLBffxNsUKR8yhwT=umZ0edgEnbxymV6tqdqmmw@mail.gmail.com>
	<CAAg5f2SXkuuvisvFVjtFATSSYxQuxt459mEFkRO17pzEuo3A6A@mail.gmail.com>
	<CAAg5f2Sb5wV2A=6wOEKCe_mn9Z=1_c_nOZo=26M20b4osgawzQ@mail.gmail.com>
	<CAD_dpu3P36tPJgawpdp5i3TQMuMkUg=NzdVLvvoZC24T6tzLtQ@mail.gmail.com>
	<CAAg5f2RdD0hJgybRYo6VMoRqba9T_SLHD0Aab5tzok3RUbmmHA@mail.gmail.com>
	<CAD_dpu0ajLXXiX7ammBRhoc7rjEq0QuoWErR2M2T-Zkw7GO7fA@mail.gmail.com>
	<CAD_dpu3Y547vmyM_jM2dox=agD+_-eq_mi6zi9dSFpicCqSyiw@mail.gmail.com>
	<9B70BDB9-4774-4BF0-9FF7-5213185E4F52@redhat.com>
Message-ID: <CAD_dpu1rGm5ekEWydj-S4M4yOfnf+GcNfYeDJcso9SuMrM5qhA@mail.gmail.com>

On Wed, Feb 12, 2014 at 2:30 PM, Lucas Holmquist <lholmqui at redhat.com>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 <scm.blanc at gmail.com> wrote:
>
>
>
>
> On Tue, Feb 11, 2014 at 7:15 PM, Sebastien Blanc <scm.blanc at gmail.com>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 <matzew at apache.org>wrote:
>>
>>>
>>>
>>>
>>> On Thu, Feb 6, 2014 at 3:11 PM, Sebastien Blanc <scm.blanc at gmail.com>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
>
-------------- 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: <CAD_dpu1rGm5ekEWydj-S4M4yOfnf+GcNfYeDJcso9SuMrM5qhA@mail.gmail.com>
References: <CAD_dpu2LGDXWLBffxNsUKR8yhwT=umZ0edgEnbxymV6tqdqmmw@mail.gmail.com>
	<CAAg5f2SXkuuvisvFVjtFATSSYxQuxt459mEFkRO17pzEuo3A6A@mail.gmail.com>
	<CAAg5f2Sb5wV2A=6wOEKCe_mn9Z=1_c_nOZo=26M20b4osgawzQ@mail.gmail.com>
	<CAD_dpu3P36tPJgawpdp5i3TQMuMkUg=NzdVLvvoZC24T6tzLtQ@mail.gmail.com>
	<CAAg5f2RdD0hJgybRYo6VMoRqba9T_SLHD0Aab5tzok3RUbmmHA@mail.gmail.com>
	<CAD_dpu0ajLXXiX7ammBRhoc7rjEq0QuoWErR2M2T-Zkw7GO7fA@mail.gmail.com>
	<CAD_dpu3Y547vmyM_jM2dox=agD+_-eq_mi6zi9dSFpicCqSyiw@mail.gmail.com>
	<9B70BDB9-4774-4BF0-9FF7-5213185E4F52@redhat.com>
	<CAD_dpu1rGm5ekEWydj-S4M4yOfnf+GcNfYeDJcso9SuMrM5qhA@mail.gmail.com>
Message-ID: <51C9D854-0730-4B2A-9A92-9DC92649947D@redhat.com>

still exploring
On Feb 13, 2014, at 3:39 PM, Sebastien Blanc <scm.blanc at gmail.com> wrote:

> 
> 
> 
> On Wed, Feb 12, 2014 at 2:30 PM, Lucas Holmquist <lholmqui at redhat.com> 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 <scm.blanc at gmail.com> wrote:
> 
>> 
>> 
>> 
>> On Tue, Feb 11, 2014 at 7:15 PM, Sebastien Blanc <scm.blanc at gmail.com> 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 <matzew at apache.org> wrote:
>> 
>> 
>> 
>> On Thu, Feb 6, 2014 at 3:11 PM, Sebastien Blanc <scm.blanc at gmail.com> 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-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: <CAAg5f2SuC0GfNVy5S7M0eVv7hKqhxpaM7FvY8NFceXuTrO1mpg@mail.gmail.com>

+1


On Fri, Feb 14, 2014 at 2:35 PM, Christos Vasilakis <cvasilak at gmail.com>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: <etPan.52fe2c1f.327b23c6.86bf@animus>

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: <etPan.52fe2c1f.327b23c6.86bf@animus>
References: <9993ED20-E46D-4768-87D3-4EA65E92B4F0@redhat.com>
	<etPan.52fe2c1f.327b23c6.86bf@animus>
Message-ID: <CAFJm-3Fc5eTBGRYEdhR32Ma_1coBQDsfSe=yikmVdU_y2TEtXg@mail.gmail.com>

Thanks Qmx, and congrats to all of you!




On 14 February 2014 15:45, Bruno Oliveira <bruno at abstractj.org> 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" <jbalunas at redhat.com>
> To: "AeroGear Developer Mailing List" <aerogear-dev at lists.jboss.org>
> 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: <CAAg5f2RNC3jWJDM-EEPCMfZPDv6+8NCjf15yWo8FVFqfuPZxJg@mail.gmail.com>
References: <CAAg5f2RNC3jWJDM-EEPCMfZPDv6+8NCjf15yWo8FVFqfuPZxJg@mail.gmail.com>
Message-ID: <CAD_dpu0dc2YiMOUa_LZBkjy=am5Herft=tKHS52RBVgwidoVmw@mail.gmail.com>

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 <matzew at apache.org>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: <CAD_dpu0dc2YiMOUa_LZBkjy=am5Herft=tKHS52RBVgwidoVmw@mail.gmail.com>
References: <CAAg5f2RNC3jWJDM-EEPCMfZPDv6+8NCjf15yWo8FVFqfuPZxJg@mail.gmail.com>
	<CAD_dpu0dc2YiMOUa_LZBkjy=am5Herft=tKHS52RBVgwidoVmw@mail.gmail.com>
Message-ID: <CAAg5f2SGLMu_0XHKVPCKx+mfCj1QrQOFN3UH7urygx4+L87WRw@mail.gmail.com>

On Fri, Feb 14, 2014 at 6: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.
>

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 <matzew at apache.org>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: <CAD_dpu0dc2YiMOUa_LZBkjy=am5Herft=tKHS52RBVgwidoVmw@mail.gmail.com>
References: <CAAg5f2RNC3jWJDM-EEPCMfZPDv6+8NCjf15yWo8FVFqfuPZxJg@mail.gmail.com>
	<CAD_dpu0dc2YiMOUa_LZBkjy=am5Herft=tKHS52RBVgwidoVmw@mail.gmail.com>
Message-ID: <0A2DAF78-924D-4042-BC9C-5D72E4E0EEC1@redhat.com>


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


> Seb
> 
> 
> 
> On Thu, Feb 13, 2014 at 8:13 PM, Matthias Wessendorf <matzew at apache.org> 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: <CAAg5f2RNC3jWJDM-EEPCMfZPDv6+8NCjf15yWo8FVFqfuPZxJg@mail.gmail.com>
	<CAD_dpu0dc2YiMOUa_LZBkjy=am5Herft=tKHS52RBVgwidoVmw@mail.gmail.com>
	<0A2DAF78-924D-4042-BC9C-5D72E4E0EEC1@redhat.com>
Message-ID: <CAAg5f2R7NuodgEWQ_aNV4FdPvhqGOGQYEU6xU0nuFANeMsHfZA@mail.gmail.com>

On Fri, Feb 14, 2014 at 7:42 PM, Lucas Holmquist <lholmqui at redhat.com>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

-M



>
> Seb
>
>
>
> On Thu, Feb 13, 2014 at 8:13 PM, Matthias Wessendorf <matzew at apache.org>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: <CAAg5f2R7NuodgEWQ_aNV4FdPvhqGOGQYEU6xU0nuFANeMsHfZA@mail.gmail.com>
References: <CAAg5f2RNC3jWJDM-EEPCMfZPDv6+8NCjf15yWo8FVFqfuPZxJg@mail.gmail.com>
	<CAD_dpu0dc2YiMOUa_LZBkjy=am5Herft=tKHS52RBVgwidoVmw@mail.gmail.com>
	<0A2DAF78-924D-4042-BC9C-5D72E4E0EEC1@redhat.com>
	<CAAg5f2R7NuodgEWQ_aNV4FdPvhqGOGQYEU6xU0nuFANeMsHfZA@mail.gmail.com>
Message-ID: <5FF28062-F341-4818-B519-52F937D6AD79@redhat.com>


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 <lholmqui at redhat.com> 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 <matzew at apache.org> 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: <CAAg5f2RNC3jWJDM-EEPCMfZPDv6+8NCjf15yWo8FVFqfuPZxJg@mail.gmail.com>
	<CAD_dpu0dc2YiMOUa_LZBkjy=am5Herft=tKHS52RBVgwidoVmw@mail.gmail.com>
	<0A2DAF78-924D-4042-BC9C-5D72E4E0EEC1@redhat.com>
	<CAAg5f2R7NuodgEWQ_aNV4FdPvhqGOGQYEU6xU0nuFANeMsHfZA@mail.gmail.com>
	<5FF28062-F341-4818-B519-52F937D6AD79@redhat.com>
Message-ID: <CAD_dpu2kePv9qyhVvL2vRRQgiWCMvPcAVBCQ1Z9mXOrryXJU9Q@mail.gmail.com>

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 <lholmqui at redhat.com>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 <matzew at apache.org>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: <CAAg5f2SkM4Qabq37sKJyU0T-Q+9UOgHjSG0FzLc6p=kuYKWjmg@mail.gmail.com>

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 <lholmqui at redhat.com>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 <matzew at apache.org>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: <CAAg5f2RsPNXwu7DUVzG0dEz3X1qxsOnCMNQM=gowdky4vQsBYw@mail.gmail.com>

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: <CAAg5f2SkM4Qabq37sKJyU0T-Q+9UOgHjSG0FzLc6p=kuYKWjmg@mail.gmail.com>
References: <CAAg5f2SkM4Qabq37sKJyU0T-Q+9UOgHjSG0FzLc6p=kuYKWjmg@mail.gmail.com>
Message-ID: <CAD_dpu1D4NkkhdiE9fmN9-C7OFy_1vQjYECBv-8MguB22RG3Pg@mail.gmail.com>

+1 , deployed and tested !



On Sat, Feb 15, 2014 at 12:00 PM, Matthias Wessendorf <matzew at apache.org>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 <lholmqui at redhat.com>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 <matzew at apache.org
>>>> > 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: <CAAg5f2QwRM8FRzf3Rxrc7yuQJKRyzLwoh2ZQJ15vJ=BNJbrbJg@mail.gmail.com>
References: <CAAg5f2QwRM8FRzf3Rxrc7yuQJKRyzLwoh2ZQJ15vJ=BNJbrbJg@mail.gmail.com>
Message-ID: <CAD_dpu2wjcrFm3Vh8uVG4mm=R4ZH0WKi+DyafR84xb2uA_d6FA@mail.gmail.com>

+1
tested with AeroDoc



On Thu, Feb 13, 2014 at 5:13 PM, Matthias Wessendorf <matzew at apache.org>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: <CAAg5f2Se8Obfw1_4jR-moV3RcJ3WpaGsTu7FvCaDs9CXUi9J6g@mail.gmail.com>

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: <CADPUygcsnHihnAXfeKRTPmmZZWXf=GLJywe2k27kkF6bKu7CAQ@mail.gmail.com>
References: <CADPUygcsnHihnAXfeKRTPmmZZWXf=GLJywe2k27kkF6bKu7CAQ@mail.gmail.com>
Message-ID: <CAAg5f2QLdEsFOhZeAd0hFzrT4K4DpRKKOOi3X8bmeTAHxmswBQ@mail.gmail.com>

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 <miguel21op at gmail.com> 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: <CAAg5f2QLdEsFOhZeAd0hFzrT4K4DpRKKOOi3X8bmeTAHxmswBQ@mail.gmail.com>
References: <CADPUygcsnHihnAXfeKRTPmmZZWXf=GLJywe2k27kkF6bKu7CAQ@mail.gmail.com>
	<CAAg5f2QLdEsFOhZeAd0hFzrT4K4DpRKKOOi3X8bmeTAHxmswBQ@mail.gmail.com>
Message-ID: <CAAg5f2SSeo36iOpqVzi-VCoqtw5CBhejrjVoGYrreYeSpkutFg@mail.gmail.com>

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 <matzew at apache.org>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 <miguel21op at gmail.com>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: <CAAg5f2Se8Obfw1_4jR-moV3RcJ3WpaGsTu7FvCaDs9CXUi9J6g@mail.gmail.com>
References: <CAAg5f2Se8Obfw1_4jR-moV3RcJ3WpaGsTu7FvCaDs9CXUi9J6g@mail.gmail.com>
Message-ID: <C40E107B-F569-476E-B245-52727B404EBF@redhat.com>


On 16 Feb,2014, at 19:06 , Matthias Wessendorf <matzew at apache.org> 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: <C40E107B-F569-476E-B245-52727B404EBF@redhat.com>
References: <CAAg5f2Se8Obfw1_4jR-moV3RcJ3WpaGsTu7FvCaDs9CXUi9J6g@mail.gmail.com>
	<C40E107B-F569-476E-B245-52727B404EBF@redhat.com>
Message-ID: <CAAg5f2QK2oNgnCZEh2etJqQDkJWoa2P5PX_VM9X6W0z178Qy5g@mail.gmail.com>

On Mon, Feb 17, 2014 at 8:20 AM, Erik Jan de Wit <edewit at redhat.com> wrote:

>
> On 16 Feb,2014, at 19:06 , Matthias Wessendorf <matzew at apache.org> 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: <CAAg5f2QK2oNgnCZEh2etJqQDkJWoa2P5PX_VM9X6W0z178Qy5g@mail.gmail.com>
References: <CAAg5f2Se8Obfw1_4jR-moV3RcJ3WpaGsTu7FvCaDs9CXUi9J6g@mail.gmail.com>
	<C40E107B-F569-476E-B245-52727B404EBF@redhat.com>
	<CAAg5f2QK2oNgnCZEh2etJqQDkJWoa2P5PX_VM9X6W0z178Qy5g@mail.gmail.com>
Message-ID: <CAD_dpu0XqJ5WQ3cRsoWeG7a2997=UObpue7P7Au9XVjudSTvLg@mail.gmail.com>

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 <edewit at redhat.com>wrote:
>
>>
>> On 16 Feb,2014, at 19:06 , Matthias Wessendorf <matzew at apache.org> 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: <CAD_dpu0XqJ5WQ3cRsoWeG7a2997=UObpue7P7Au9XVjudSTvLg@mail.gmail.com>
References: <CAAg5f2Se8Obfw1_4jR-moV3RcJ3WpaGsTu7FvCaDs9CXUi9J6g@mail.gmail.com>
	<C40E107B-F569-476E-B245-52727B404EBF@redhat.com>
	<CAAg5f2QK2oNgnCZEh2etJqQDkJWoa2P5PX_VM9X6W0z178Qy5g@mail.gmail.com>
	<CAD_dpu0XqJ5WQ3cRsoWeG7a2997=UObpue7P7Au9XVjudSTvLg@mail.gmail.com>
Message-ID: <CAAg5f2Qyp0N5Aq9FiU22_QUmHOzWdecPwDJkoKmZC0B9vjXkjQ@mail.gmail.com>

On Mon, Feb 17, 2014 at 8:47 AM, Sebastien Blanc <scm.blanc at gmail.com>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 <edewit at redhat.com>wrote:
>>
>>>
>>> On 16 Feb,2014, at 19:06 , Matthias Wessendorf <matzew at apache.org>
>>> 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: <CAAg5f2Qyp0N5Aq9FiU22_QUmHOzWdecPwDJkoKmZC0B9vjXkjQ@mail.gmail.com>
References: <CAAg5f2Se8Obfw1_4jR-moV3RcJ3WpaGsTu7FvCaDs9CXUi9J6g@mail.gmail.com>
	<C40E107B-F569-476E-B245-52727B404EBF@redhat.com>
	<CAAg5f2QK2oNgnCZEh2etJqQDkJWoa2P5PX_VM9X6W0z178Qy5g@mail.gmail.com>
	<CAD_dpu0XqJ5WQ3cRsoWeG7a2997=UObpue7P7Au9XVjudSTvLg@mail.gmail.com>
	<CAAg5f2Qyp0N5Aq9FiU22_QUmHOzWdecPwDJkoKmZC0B9vjXkjQ@mail.gmail.com>
Message-ID: <CAD_dpu13LgPGD52OxZ1mQtKyzy2k9ah7JBS05k=x5i1+hq5yRA@mail.gmail.com>

On Mon, Feb 17, 2014 at 8:53 AM, Matthias Wessendorf <matzew at apache.org>wrote:

>
>
>
> On Mon, Feb 17, 2014 at 8:47 AM, Sebastien Blanc <scm.blanc at gmail.com>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 <edewit at redhat.com>wrote:
>>>
>>>>
>>>> On 16 Feb,2014, at 19:06 , Matthias Wessendorf <matzew at apache.org>
>>>> 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: <CAD_dpu13LgPGD52OxZ1mQtKyzy2k9ah7JBS05k=x5i1+hq5yRA@mail.gmail.com>
References: <CAAg5f2Se8Obfw1_4jR-moV3RcJ3WpaGsTu7FvCaDs9CXUi9J6g@mail.gmail.com>
	<C40E107B-F569-476E-B245-52727B404EBF@redhat.com>
	<CAAg5f2QK2oNgnCZEh2etJqQDkJWoa2P5PX_VM9X6W0z178Qy5g@mail.gmail.com>
	<CAD_dpu0XqJ5WQ3cRsoWeG7a2997=UObpue7P7Au9XVjudSTvLg@mail.gmail.com>
	<CAAg5f2Qyp0N5Aq9FiU22_QUmHOzWdecPwDJkoKmZC0B9vjXkjQ@mail.gmail.com>
	<CAD_dpu13LgPGD52OxZ1mQtKyzy2k9ah7JBS05k=x5i1+hq5yRA@mail.gmail.com>
Message-ID: <CAAg5f2RRSO46_DJu7eHSjqiKnx0VDzc0TH5OHXJvRV6wSNSEew@mail.gmail.com>

On Mon, Feb 17, 2014 at 8:57 AM, Sebastien Blanc <scm.blanc at gmail.com>wrote:

>
>
>
> On Mon, Feb 17, 2014 at 8:53 AM, Matthias Wessendorf <matzew at apache.org>wrote:
>
>>
>>
>>
>> On Mon, Feb 17, 2014 at 8:47 AM, Sebastien Blanc <scm.blanc at gmail.com>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 <edewit at redhat.com>wrote:
>>>>
>>>>>
>>>>> On 16 Feb,2014, at 19:06 , Matthias Wessendorf <matzew at apache.org>
>>>>> 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: <CAAg5f2RRSO46_DJu7eHSjqiKnx0VDzc0TH5OHXJvRV6wSNSEew@mail.gmail.com>
References: <CAAg5f2Se8Obfw1_4jR-moV3RcJ3WpaGsTu7FvCaDs9CXUi9J6g@mail.gmail.com>
	<C40E107B-F569-476E-B245-52727B404EBF@redhat.com>
	<CAAg5f2QK2oNgnCZEh2etJqQDkJWoa2P5PX_VM9X6W0z178Qy5g@mail.gmail.com>
	<CAD_dpu0XqJ5WQ3cRsoWeG7a2997=UObpue7P7Au9XVjudSTvLg@mail.gmail.com>
	<CAAg5f2Qyp0N5Aq9FiU22_QUmHOzWdecPwDJkoKmZC0B9vjXkjQ@mail.gmail.com>
	<CAD_dpu13LgPGD52OxZ1mQtKyzy2k9ah7JBS05k=x5i1+hq5yRA@mail.gmail.com>
	<CAAg5f2RRSO46_DJu7eHSjqiKnx0VDzc0TH5OHXJvRV6wSNSEew@mail.gmail.com>
Message-ID: <CAD_dpu3ociBv3cuFgfQyfwLA4fNWgpPtjUU7B2cKWCgsQWVYyQ@mail.gmail.com>

On Mon, Feb 17, 2014 at 9:00 AM, Matthias Wessendorf <matzew at apache.org>wrote:

>
>
>
> On Mon, Feb 17, 2014 at 8:57 AM, Sebastien Blanc <scm.blanc at gmail.com>wrote:
>
>>
>>
>>
>> On Mon, Feb 17, 2014 at 8:53 AM, Matthias Wessendorf <matzew at apache.org>wrote:
>>
>>>
>>>
>>>
>>> On Mon, Feb 17, 2014 at 8:47 AM, Sebastien Blanc <scm.blanc at gmail.com>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 <edewit at redhat.com>wrote:
>>>>>
>>>>>>
>>>>>> On 16 Feb,2014, at 19:06 , Matthias Wessendorf <matzew at apache.org>
>>>>>> 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: <CAD_dpu3ociBv3cuFgfQyfwLA4fNWgpPtjUU7B2cKWCgsQWVYyQ@mail.gmail.com>
References: <CAAg5f2Se8Obfw1_4jR-moV3RcJ3WpaGsTu7FvCaDs9CXUi9J6g@mail.gmail.com>
	<C40E107B-F569-476E-B245-52727B404EBF@redhat.com>
	<CAAg5f2QK2oNgnCZEh2etJqQDkJWoa2P5PX_VM9X6W0z178Qy5g@mail.gmail.com>
	<CAD_dpu0XqJ5WQ3cRsoWeG7a2997=UObpue7P7Au9XVjudSTvLg@mail.gmail.com>
	<CAAg5f2Qyp0N5Aq9FiU22_QUmHOzWdecPwDJkoKmZC0B9vjXkjQ@mail.gmail.com>
	<CAD_dpu13LgPGD52OxZ1mQtKyzy2k9ah7JBS05k=x5i1+hq5yRA@mail.gmail.com>
	<CAAg5f2RRSO46_DJu7eHSjqiKnx0VDzc0TH5OHXJvRV6wSNSEew@mail.gmail.com>
	<CAD_dpu3ociBv3cuFgfQyfwLA4fNWgpPtjUU7B2cKWCgsQWVYyQ@mail.gmail.com>
Message-ID: <CAAg5f2R721JCuDwjQ=C4Nbnh6vGicoC-uh+xV=AsUsrp3+c1_w@mail.gmail.com>

On Mon, Feb 17, 2014 at 9:07 AM, Sebastien Blanc <scm.blanc at gmail.com>wrote:

>
>
>
> On Mon, Feb 17, 2014 at 9:00 AM, Matthias Wessendorf <matzew at apache.org>wrote:
>
>>
>>
>>
>> On Mon, Feb 17, 2014 at 8:57 AM, Sebastien Blanc <scm.blanc at gmail.com>wrote:
>>
>>>
>>>
>>>
>>> On Mon, Feb 17, 2014 at 8:53 AM, Matthias Wessendorf <matzew at apache.org>wrote:
>>>
>>>>
>>>>
>>>>
>>>> On Mon, Feb 17, 2014 at 8:47 AM, Sebastien Blanc <scm.blanc at gmail.com>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 <edewit at redhat.com>wrote:
>>>>>>
>>>>>>>
>>>>>>> On 16 Feb,2014, at 19:06 , Matthias Wessendorf <matzew at apache.org>
>>>>>>> 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: <CAAg5f2SSeo36iOpqVzi-VCoqtw5CBhejrjVoGYrreYeSpkutFg@mail.gmail.com>
References: <CADPUygcsnHihnAXfeKRTPmmZZWXf=GLJywe2k27kkF6bKu7CAQ@mail.gmail.com>
	<CAAg5f2QLdEsFOhZeAd0hFzrT4K4DpRKKOOi3X8bmeTAHxmswBQ@mail.gmail.com>
	<CAAg5f2SSeo36iOpqVzi-VCoqtw5CBhejrjVoGYrreYeSpkutFg@mail.gmail.com>
Message-ID: <CAAg5f2TNk+opM8AEhAyfyVgWm_jAfdJxzkGReMdhpeQ5uX+ehA@mail.gmail.com>

Got a reply from Miguel:

<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.
</miguel>

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 <matzew at apache.org>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 <matzew at apache.org>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 <miguel21op at gmail.com>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: <CAAg5f2RsnBoKEU8fmVow134AON_Gyhi9nwRm6s=pKzzuYjq=uQ@mail.gmail.com>

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: <CAAg5f2RsnBoKEU8fmVow134AON_Gyhi9nwRm6s=pKzzuYjq=uQ@mail.gmail.com>
References: <CAAg5f2RsnBoKEU8fmVow134AON_Gyhi9nwRm6s=pKzzuYjq=uQ@mail.gmail.com>
Message-ID: <CAFJm-3Ew8fezscpd3+NbyhU2CAYY7xQ1CRW6kkVZ_GJdvRJ3NQ@mail.gmail.com>

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 <matzew at apache.org> 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: <CAFJm-3Ew8fezscpd3+NbyhU2CAYY7xQ1CRW6kkVZ_GJdvRJ3NQ@mail.gmail.com>
References: <CAAg5f2RsnBoKEU8fmVow134AON_Gyhi9nwRm6s=pKzzuYjq=uQ@mail.gmail.com>
	<CAFJm-3Ew8fezscpd3+NbyhU2CAYY7xQ1CRW6kkVZ_GJdvRJ3NQ@mail.gmail.com>
Message-ID: <CAFJm-3GjKjjJxwOd=0DsKTbU0MxFeO439dByEGAHpym5UQnO7w@mail.gmail.com>

Sorry, worked now.


On 17 February 2014 12:36, Daniel Bevenius <daniel.bevenius at gmail.com>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 <matzew at apache.org> 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: <CAAg5f2SkM4Qabq37sKJyU0T-Q+9UOgHjSG0FzLc6p=kuYKWjmg@mail.gmail.com>
References: <CAAg5f2SkM4Qabq37sKJyU0T-Q+9UOgHjSG0FzLc6p=kuYKWjmg@mail.gmail.com>
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 <matzew at apache.org> 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
> >> <lholmqui at redhat.com>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
> >>> <matzew at apache.org>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: <CAAg5f2RsPNXwu7DUVzG0dEz3X1qxsOnCMNQM=gowdky4vQsBYw@mail.gmail.com>
References: <CAAg5f2RsPNXwu7DUVzG0dEz3X1qxsOnCMNQM=gowdky4vQsBYw@mail.gmail.com>
Message-ID: <20140217132407.42e30968@kapy-ntb-x220>

On Sat, 15 Feb 2014 14:24:53 +0100
Matthias Wessendorf <matzew at apache.org> 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: <CAAg5f2SkM4Qabq37sKJyU0T-Q+9UOgHjSG0FzLc6p=kuYKWjmg@mail.gmail.com>
	<20140217132016.55245687@kapy-ntb-x220>
Message-ID: <CAAg5f2QbxFnB_Bu1jd5s9SKtHG1-gXLvpBw4PU5S4sd7By2WoA@mail.gmail.com>

On Mon, Feb 17, 2014 at 1:20 PM, Karel Piwko <kpiwko at redhat.com> 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 <matzew at apache.org> 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
> > >> <lholmqui at redhat.com>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
> > >>> <matzew at apache.org>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: <CAAg5f2RsPNXwu7DUVzG0dEz3X1qxsOnCMNQM=gowdky4vQsBYw@mail.gmail.com>
	<20140217132407.42e30968@kapy-ntb-x220>
Message-ID: <CAAg5f2Rd+yOGSk4YFw4bvJZ16oiaJUHF3OX9EXfobaFh4Zdx5w@mail.gmail.com>

On Mon, Feb 17, 2014 at 1:24 PM, Karel Piwko <kpiwko at redhat.com> wrote:

> On Sat, 15 Feb 2014 14:24:53 +0100
> Matthias Wessendorf <matzew at apache.org> 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: <CAAg5f2SuC0GfNVy5S7M0eVv7hKqhxpaM7FvY8NFceXuTrO1mpg@mail.gmail.com>
References: <4401DB10-0C2C-4DE1-9F5F-E9B0C51AE500@gmail.com>
	<CAAg5f2SuC0GfNVy5S7M0eVv7hKqhxpaM7FvY8NFceXuTrO1mpg@mail.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 <matzew at apache.org> wrote:

> +1
> 
> 
> On Fri, Feb 14, 2014 at 2:35 PM, Christos Vasilakis <cvasilak at gmail.com> 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: <CAAg5f2Rd+yOGSk4YFw4bvJZ16oiaJUHF3OX9EXfobaFh4Zdx5w@mail.gmail.com>
References: <CAAg5f2RsPNXwu7DUVzG0dEz3X1qxsOnCMNQM=gowdky4vQsBYw@mail.gmail.com>
	<20140217132407.42e30968@kapy-ntb-x220>
	<CAAg5f2Rd+yOGSk4YFw4bvJZ16oiaJUHF3OX9EXfobaFh4Zdx5w@mail.gmail.com>
Message-ID: <57CFD7FF-C17A-441F-913C-8135D1A19D84@redhat.com>


?
Tadeas Kriz
tkriz at redhat.com

On 17 Feb 2014, at 13:26, Matthias Wessendorf <matzew at apache.org> wrote:

> 
> 
> 
> On Mon, Feb 17, 2014 at 1:24 PM, Karel Piwko <kpiwko at redhat.com> wrote:
> On Sat, 15 Feb 2014 14:24:53 +0100
> Matthias Wessendorf <matzew at apache.org> 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: <CAAg5f2RsPNXwu7DUVzG0dEz3X1qxsOnCMNQM=gowdky4vQsBYw@mail.gmail.com>
	<20140217132407.42e30968@kapy-ntb-x220>
	<CAAg5f2Rd+yOGSk4YFw4bvJZ16oiaJUHF3OX9EXfobaFh4Zdx5w@mail.gmail.com>
	<57CFD7FF-C17A-441F-913C-8135D1A19D84@redhat.com>
Message-ID: <CAAg5f2QSTJ88j_f7bsk5TwXKDy7A=GYZeouCfFCZg6+uPAV5sg@mail.gmail.com>

On Mon, Feb 17, 2014 at 1:29 PM, Tadeas Kriz <tkriz at redhat.com> wrote:

>
> --
> Tadeas Kriz
> tkriz at redhat.com
>
> On 17 Feb 2014, at 13:26, Matthias Wessendorf <matzew at apache.org> wrote:
>
>
>
>
> On Mon, Feb 17, 2014 at 1:24 PM, Karel Piwko <kpiwko at redhat.com> wrote:
>
>> On Sat, 15 Feb 2014 14:24:53 +0100
>> Matthias Wessendorf <matzew at apache.org> 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: <CAAg5f2QbxFnB_Bu1jd5s9SKtHG1-gXLvpBw4PU5S4sd7By2WoA@mail.gmail.com>
References: <CAAg5f2SkM4Qabq37sKJyU0T-Q+9UOgHjSG0FzLc6p=kuYKWjmg@mail.gmail.com>
	<20140217132016.55245687@kapy-ntb-x220>
	<CAAg5f2QbxFnB_Bu1jd5s9SKtHG1-gXLvpBw4PU5S4sd7By2WoA@mail.gmail.com>
Message-ID: <20140217135037.0859170a@kapy-ntb-x220>

On Mon, 17 Feb 2014 13:24:37 +0100
Matthias Wessendorf <matzew at apache.org> wrote:

> On Mon, Feb 17, 2014 at 1:20 PM, Karel Piwko <kpiwko at redhat.com> 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 <matzew at apache.org> 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
> > > >> <lholmqui at redhat.com>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
> > > >>> <matzew at apache.org>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: <CAAg5f2RsPNXwu7DUVzG0dEz3X1qxsOnCMNQM=gowdky4vQsBYw@mail.gmail.com>
	<20140217132407.42e30968@kapy-ntb-x220>
	<CAAg5f2Rd+yOGSk4YFw4bvJZ16oiaJUHF3OX9EXfobaFh4Zdx5w@mail.gmail.com>
	<57CFD7FF-C17A-441F-913C-8135D1A19D84@redhat.com>
Message-ID: <A55A0D0A-F8EA-4C75-A62B-C48AF3215EAA@gmail.com>

Hi Tadeas,

On Feb 17, 2014, at 2:29 PM, Tadeas Kriz <tkriz at redhat.com> wrote:

> 
> ?
> Tadeas Kriz
> tkriz at redhat.com
> 
> On 17 Feb 2014, at 13:26, Matthias Wessendorf <matzew at apache.org> wrote:
> 
>> 
>> 
>> 
>> On Mon, Feb 17, 2014 at 1:24 PM, Karel Piwko <kpiwko at redhat.com> wrote:
>> On Sat, 15 Feb 2014 14:24:53 +0100
>> Matthias Wessendorf <matzew at apache.org> 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: <CAAg5f2SkM4Qabq37sKJyU0T-Q+9UOgHjSG0FzLc6p=kuYKWjmg@mail.gmail.com>
	<20140217132016.55245687@kapy-ntb-x220>
	<CAAg5f2QbxFnB_Bu1jd5s9SKtHG1-gXLvpBw4PU5S4sd7By2WoA@mail.gmail.com>
	<20140217135037.0859170a@kapy-ntb-x220>
Message-ID: <CAAg5f2RJsU5xtwdaOoJ6YqtS9sLAm6SZc6w7iy+bXEV-Ryy3SA@mail.gmail.com>

On Mon, Feb 17, 2014 at 1:50 PM, Karel Piwko <kpiwko at redhat.com> wrote:

> On Mon, 17 Feb 2014 13:24:37 +0100
> Matthias Wessendorf <matzew at apache.org> wrote:
>
> > On Mon, Feb 17, 2014 at 1:20 PM, Karel Piwko <kpiwko at redhat.com> 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 <matzew at apache.org> 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
> > > > >> <lholmqui at redhat.com>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
> > > > >>> <matzew at apache.org>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: <CAAg5f2R721JCuDwjQ=C4Nbnh6vGicoC-uh+xV=AsUsrp3+c1_w@mail.gmail.com>
References: <CAAg5f2Se8Obfw1_4jR-moV3RcJ3WpaGsTu7FvCaDs9CXUi9J6g@mail.gmail.com>
	<C40E107B-F569-476E-B245-52727B404EBF@redhat.com>
	<CAAg5f2QK2oNgnCZEh2etJqQDkJWoa2P5PX_VM9X6W0z178Qy5g@mail.gmail.com>
	<CAD_dpu0XqJ5WQ3cRsoWeG7a2997=UObpue7P7Au9XVjudSTvLg@mail.gmail.com>
	<CAAg5f2Qyp0N5Aq9FiU22_QUmHOzWdecPwDJkoKmZC0B9vjXkjQ@mail.gmail.com>
	<CAD_dpu13LgPGD52OxZ1mQtKyzy2k9ah7JBS05k=x5i1+hq5yRA@mail.gmail.com>
	<CAAg5f2RRSO46_DJu7eHSjqiKnx0VDzc0TH5OHXJvRV6wSNSEew@mail.gmail.com>
	<CAD_dpu3ociBv3cuFgfQyfwLA4fNWgpPtjUU7B2cKWCgsQWVYyQ@mail.gmail.com>
	<CAAg5f2R721JCuDwjQ=C4Nbnh6vGicoC-uh+xV=AsUsrp3+c1_w@mail.gmail.com>
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 <matzew at apache.org> wrote:

> On Mon, Feb 17, 2014 at 9:07 AM, Sebastien Blanc <scm.blanc at gmail.com>wrote:
> 
> >
> >
> >
> > On Mon, Feb 17, 2014 at 9:00 AM, Matthias Wessendorf
> > <matzew at apache.org>wrote:
> >
> >>
> >>
> >>
> >> On Mon, Feb 17, 2014 at 8:57 AM, Sebastien Blanc
> >> <scm.blanc at gmail.com>wrote:
> >>
> >>>
> >>>
> >>>
> >>> On Mon, Feb 17, 2014 at 8:53 AM, Matthias Wessendorf
> >>> <matzew at apache.org>wrote:
> >>>
> >>>>
> >>>>
> >>>>
> >>>> On Mon, Feb 17, 2014 at 8:47 AM, Sebastien Blanc
> >>>> <scm.blanc at gmail.com>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
> >>>>>> <edewit at redhat.com>wrote:
> >>>>>>
> >>>>>>>
> >>>>>>> On 16 Feb,2014, at 19:06 , Matthias Wessendorf <matzew at apache.org>
> >>>>>>> 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: <CAAg5f2Se8Obfw1_4jR-moV3RcJ3WpaGsTu7FvCaDs9CXUi9J6g@mail.gmail.com>
	<C40E107B-F569-476E-B245-52727B404EBF@redhat.com>
	<CAAg5f2QK2oNgnCZEh2etJqQDkJWoa2P5PX_VM9X6W0z178Qy5g@mail.gmail.com>
	<CAD_dpu0XqJ5WQ3cRsoWeG7a2997=UObpue7P7Au9XVjudSTvLg@mail.gmail.com>
	<CAAg5f2Qyp0N5Aq9FiU22_QUmHOzWdecPwDJkoKmZC0B9vjXkjQ@mail.gmail.com>
	<CAD_dpu13LgPGD52OxZ1mQtKyzy2k9ah7JBS05k=x5i1+hq5yRA@mail.gmail.com>
	<CAAg5f2RRSO46_DJu7eHSjqiKnx0VDzc0TH5OHXJvRV6wSNSEew@mail.gmail.com>
	<CAD_dpu3ociBv3cuFgfQyfwLA4fNWgpPtjUU7B2cKWCgsQWVYyQ@mail.gmail.com>
	<CAAg5f2R721JCuDwjQ=C4Nbnh6vGicoC-uh+xV=AsUsrp3+c1_w@mail.gmail.com>
	<20140217140219.754b2d3b@kapy-ntb-x220>
Message-ID: <etPan.53020d57.643c9869.13b96@animus>

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: <CAL8vO=dJb=yp9ZXO=cdYZWuA1jGak+o9FP=r+UKg=S6Rws4uMw@mail.gmail.com>
References: <CAL8vO=dJb=yp9ZXO=cdYZWuA1jGak+o9FP=r+UKg=S6Rws4uMw@mail.gmail.com>
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: <CAAg5f2RsnBoKEU8fmVow134AON_Gyhi9nwRm6s=pKzzuYjq=uQ@mail.gmail.com>
References: <CAAg5f2RsnBoKEU8fmVow134AON_Gyhi9nwRm6s=pKzzuYjq=uQ@mail.gmail.com>
Message-ID: <20140217151850.GL45949@rohan.local>

Here are the minutes:

[12:18:04]  <jbott>	 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]  <jbott>	 Minutes:
http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-02-17-14.49.html
[12:18:05]  <jbott>	 Minutes (text):
http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-02-17-14.49.txt
[12:18:05]  <jbott>	 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: <etPan.52fb820d.625558ec.36cc@animus>
References: <etPan.52fb820d.625558ec.36cc@animus>
Message-ID: <CAAg5f2T9m2UNzhySK9b_Gzc=5KDKe59x5omTR6XG+dMvz8ZtPQ@mail.gmail.com>

On Wed, Feb 12, 2014 at 3:15 PM, Bruno Oliveira <bruno at abstractj.org> 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: <a binary stream or just plain
> 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: <CAAg5f2T9m2UNzhySK9b_Gzc=5KDKe59x5omTR6XG+dMvz8ZtPQ@mail.gmail.com>
References: <etPan.52fb820d.625558ec.36cc@animus>
	<CAAg5f2T9m2UNzhySK9b_Gzc=5KDKe59x5omTR6XG+dMvz8ZtPQ@mail.gmail.com>
Message-ID: <etPan.53022cb5.19495cff.13b96@animus>



--  
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: <etPan.53022cb5.19495cff.13b96@animus>
References: <etPan.52fb820d.625558ec.36cc@animus>
	<CAAg5f2T9m2UNzhySK9b_Gzc=5KDKe59x5omTR6XG+dMvz8ZtPQ@mail.gmail.com>
	<etPan.53022cb5.19495cff.13b96@animus>
Message-ID: <CAAg5f2RH2NzCmPuKQkiMy_SwARdX7H5WSD8OHmMw5CjEppXEHw@mail.gmail.com>

On Mon, Feb 17, 2014 at 4:37 PM, Bruno Oliveira <bruno at abstractj.org> 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: <CAAg5f2RH2NzCmPuKQkiMy_SwARdX7H5WSD8OHmMw5CjEppXEHw@mail.gmail.com>
References: <etPan.52fb820d.625558ec.36cc@animus>
	<CAAg5f2T9m2UNzhySK9b_Gzc=5KDKe59x5omTR6XG+dMvz8ZtPQ@mail.gmail.com>
	<etPan.53022cb5.19495cff.13b96@animus>
	<CAAg5f2RH2NzCmPuKQkiMy_SwARdX7H5WSD8OHmMw5CjEppXEHw@mail.gmail.com>
Message-ID: <etPan.5302394d.2ae8944a.13b96@animus>

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: <etPan.5302394d.2ae8944a.13b96@animus>
References: <etPan.52fb820d.625558ec.36cc@animus>
	<CAAg5f2T9m2UNzhySK9b_Gzc=5KDKe59x5omTR6XG+dMvz8ZtPQ@mail.gmail.com>
	<etPan.53022cb5.19495cff.13b96@animus>
	<CAAg5f2RH2NzCmPuKQkiMy_SwARdX7H5WSD8OHmMw5CjEppXEHw@mail.gmail.com>
	<etPan.5302394d.2ae8944a.13b96@animus>
Message-ID: <CAAg5f2RLcN5n=3sem+=Pa3ROgr=hm=Eax8k68RnB48k3kypxNg@mail.gmail.com>

On Mon, Feb 17, 2014 at 5:31 PM, Bruno Oliveira <bruno at abstractj.org> 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: <CAAg5f2Q3n2DQitVn4w1xyG16kkWxD7-WmM2_KK3cZHuNDhvFkw@mail.gmail.com>

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: <CAAg5f2RsnBoKEU8fmVow134AON_Gyhi9nwRm6s=pKzzuYjq=uQ@mail.gmail.com>
	<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 <qmx at qmx.me> wrote:

> Here are the minutes:
> 
> [12:18:04]  <jbott>	 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]  <jbott>	 Minutes:
> http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-02-17-14.49.html
> [12:18:05]  <jbott>	 Minutes (text):
> http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-02-17-14.49.txt
> [12:18:05]  <jbott>	 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: <CAAg5f2Q3n2DQitVn4w1xyG16kkWxD7-WmM2_KK3cZHuNDhvFkw@mail.gmail.com>
References: <CAAg5f2Q3n2DQitVn4w1xyG16kkWxD7-WmM2_KK3cZHuNDhvFkw@mail.gmail.com>
Message-ID: <etPan.53025153.625558ec.13b96@animus>

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: <CAAg5f2RJsU5xtwdaOoJ6YqtS9sLAm6SZc6w7iy+bXEV-Ryy3SA@mail.gmail.com>
References: <CAAg5f2SkM4Qabq37sKJyU0T-Q+9UOgHjSG0FzLc6p=kuYKWjmg@mail.gmail.com>
	<20140217132016.55245687@kapy-ntb-x220>
	<CAAg5f2QbxFnB_Bu1jd5s9SKtHG1-gXLvpBw4PU5S4sd7By2WoA@mail.gmail.com>
	<20140217135037.0859170a@kapy-ntb-x220>
	<CAAg5f2RJsU5xtwdaOoJ6YqtS9sLAm6SZc6w7iy+bXEV-Ryy3SA@mail.gmail.com>
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 <matzew at apache.org> wrote:

> On Mon, Feb 17, 2014 at 1:50 PM, Karel Piwko <kpiwko at redhat.com> wrote:
> 
> > On Mon, 17 Feb 2014 13:24:37 +0100
> > Matthias Wessendorf <matzew at apache.org> wrote:
> >
> > > On Mon, Feb 17, 2014 at 1:20 PM, Karel Piwko <kpiwko at redhat.com> 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 <matzew at apache.org> 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
> > > > > >> <lholmqui at redhat.com>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
> > > > > >>> <matzew at apache.org>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: <B8484FC3-AB4E-41DD-A2FF-4379B5F8929B@gmail.com>

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: <B8484FC3-AB4E-41DD-A2FF-4379B5F8929B@gmail.com>
References: <B8484FC3-AB4E-41DD-A2FF-4379B5F8929B@gmail.com>
Message-ID: <1392739734983.7eb8e9a@Nodemailer>

Huzzah! Congratulations!?
abstractj

On Tue, Feb 18, 2014 at 1:07 PM, Christos Vasilakis <cvasilak at gmail.com>
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: <B8484FC3-AB4E-41DD-A2FF-4379B5F8929B@gmail.com>
	<1392739734983.7eb8e9a@Nodemailer>
Message-ID: <CAAg5f2TU+_o2u54YBA7eNn+MNGeq9wutD+r3iZcVTWps73Ad=w@mail.gmail.com>

great work, guys!

Congratulations!!!


On Tue, Feb 18, 2014 at 5:08 PM, Bruno Oliveira <bruno at abstractj.org> wrote:

> Huzzah! Congratulations!
> --
> abstractj
>
>
> On Tue, Feb 18, 2014 at 1:07 PM, Christos Vasilakis <cvasilak at gmail.com>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<http://cvasilak.blogspot.gr/2014/02/aerogear-ios-lib-140-release.html>
>> .
>>
>> 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: <CAAg5f2TU+_o2u54YBA7eNn+MNGeq9wutD+r3iZcVTWps73Ad=w@mail.gmail.com>
References: <B8484FC3-AB4E-41DD-A2FF-4379B5F8929B@gmail.com>
	<1392739734983.7eb8e9a@Nodemailer>
	<CAAg5f2TU+_o2u54YBA7eNn+MNGeq9wutD+r3iZcVTWps73Ad=w@mail.gmail.com>
Message-ID: <CAFJm-3H0gP8+qgr2zS18fYJL1LEde0CnOsjsu0TVNDoZwFNUCQ@mail.gmail.com>

Very nice, great job!

tisdagen den 18:e februari 2014 skrev Matthias Wessendorf <matzew at apache.org
>:

> great work, guys!
>
> Congratulations!!!
>
>
> On Tue, Feb 18, 2014 at 5:08 PM, Bruno Oliveira <bruno at abstractj.org<javascript:_e(%7B%7D,'cvml','bruno at abstractj.org');>
> > wrote:
>
>> Huzzah! Congratulations!
>> --
>> abstractj
>>
>>
>> On Tue, Feb 18, 2014 at 1:07 PM, Christos Vasilakis <cvasilak at gmail.com<javascript:_e(%7B%7D,'cvml','cvasilak at gmail.com');>
>> > 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<http://cvasilak.blogspot.gr/2014/02/aerogear-ios-lib-140-release.html>
>>> .
>>>
>>> Congratulations to the team, and to our community contributors and users!
>>>
>>> Have fun!
>>>
>>> -
>>> Christos
>>>
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org<javascript:_e(%7B%7D,'cvml','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: <CAD_dpu0N+F5C78OF=meS9n7gs1P6qnJi-0r8-ocTvGnQDFtFgw@mail.gmail.com>

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: <CAD_dpu0N+F5C78OF=meS9n7gs1P6qnJi-0r8-ocTvGnQDFtFgw@mail.gmail.com>
References: <CAD_dpu0N+F5C78OF=meS9n7gs1P6qnJi-0r8-ocTvGnQDFtFgw@mail.gmail.com>
Message-ID: <96636ABC-EE3E-461D-A5F0-0BFBB4B79694@gmail.com>


On 18 Feb 2014, at 18:05, Sebastien Blanc <scm.blanc at gmail.com> 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: <CAD_dpu0N+F5C78OF=meS9n7gs1P6qnJi-0r8-ocTvGnQDFtFgw@mail.gmail.com>
	<96636ABC-EE3E-461D-A5F0-0BFBB4B79694@gmail.com>
Message-ID: <CAD_dpu3+4SuiQEEgjotYUXdNtQTpKp5YCoQAx-KxXL8W5E88CQ@mail.gmail.com>

On Wed, Feb 19, 2014 at 9:11 AM, Corinne Krych <corinnekrych at gmail.com>wrote:

>
> On 18 Feb 2014, at 18:05, Sebastien Blanc <scm.blanc at gmail.com> 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: <CADPUygeFVLtskRVAqJ8o8o2Zu5Jtu64cyyAODdja=gCdbTJwsQ@mail.gmail.com>

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: <CADPUygeFVLtskRVAqJ8o8o2Zu5Jtu64cyyAODdja=gCdbTJwsQ@mail.gmail.com>
References: <CADPUygeFVLtskRVAqJ8o8o2Zu5Jtu64cyyAODdja=gCdbTJwsQ@mail.gmail.com>
Message-ID: <CAD_dpu0MnENNhUA2srMAgLeSPJRw8ufTB3M6Fr0CF23CJLNwzg@mail.gmail.com>

Hi,
Some questions and remarks inline

On Wed, Feb 19, 2014 at 9:58 AM, Miguel Lemos <miguel21op at gmail.com> 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: <CADPUygeFVLtskRVAqJ8o8o2Zu5Jtu64cyyAODdja=gCdbTJwsQ@mail.gmail.com>
References: <CADPUygeFVLtskRVAqJ8o8o2Zu5Jtu64cyyAODdja=gCdbTJwsQ@mail.gmail.com>
Message-ID: <CAAg5f2ThUAYRPe8wfW2qERWy3m7YeRXRWHDkWYrJf+F42EOMww@mail.gmail.com>

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 <miguel21op at gmail.com> 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: <CAD_dpu0MnENNhUA2srMAgLeSPJRw8ufTB3M6Fr0CF23CJLNwzg@mail.gmail.com>
References: <CADPUygeFVLtskRVAqJ8o8o2Zu5Jtu64cyyAODdja=gCdbTJwsQ@mail.gmail.com>
	<CAD_dpu0MnENNhUA2srMAgLeSPJRw8ufTB3M6Fr0CF23CJLNwzg@mail.gmail.com>
Message-ID: <CADPUyge8EPKVAnT4fh6Lccgiyvt4d-1J8hP=7kNaXmGGCKAyMg@mail.gmail.com>

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: <CADPUyge8EPKVAnT4fh6Lccgiyvt4d-1J8hP=7kNaXmGGCKAyMg@mail.gmail.com>
References: <CADPUygeFVLtskRVAqJ8o8o2Zu5Jtu64cyyAODdja=gCdbTJwsQ@mail.gmail.com>
	<CAD_dpu0MnENNhUA2srMAgLeSPJRw8ufTB3M6Fr0CF23CJLNwzg@mail.gmail.com>
	<CADPUyge8EPKVAnT4fh6Lccgiyvt4d-1J8hP=7kNaXmGGCKAyMg@mail.gmail.com>
Message-ID: <CAAg5f2QcXHA1V7vC5VqJ8Ns=4MKgAU=Cx4CHS1u+kgqFNVenNw@mail.gmail.com>

On Wed, Feb 19, 2014 at 10:53 AM, Miguel Lemos <miguel21op at gmail.com> 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: <CAAg5f2QcXHA1V7vC5VqJ8Ns=4MKgAU=Cx4CHS1u+kgqFNVenNw@mail.gmail.com>
References: <CADPUygeFVLtskRVAqJ8o8o2Zu5Jtu64cyyAODdja=gCdbTJwsQ@mail.gmail.com>
	<CAD_dpu0MnENNhUA2srMAgLeSPJRw8ufTB3M6Fr0CF23CJLNwzg@mail.gmail.com>
	<CADPUyge8EPKVAnT4fh6Lccgiyvt4d-1J8hP=7kNaXmGGCKAyMg@mail.gmail.com>
	<CAAg5f2QcXHA1V7vC5VqJ8Ns=4MKgAU=Cx4CHS1u+kgqFNVenNw@mail.gmail.com>
Message-ID: <CAD_dpu3HJ0jri8MGcE3rFgY5YWwpdsJ8-U6HUf42QEoq_aEo-Q@mail.gmail.com>

On Wed, Feb 19, 2014 at 11:08 AM, Matthias Wessendorf <matzew at apache.org>wrote:

>
>
>
> On Wed, Feb 19, 2014 at 10:53 AM, Miguel Lemos <miguel21op at gmail.com>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: <CAAg5f2TGzP=Ffh9sGTV0DhXYQXp_S=FC-3zX5z_Mr8ckP-eUvA@mail.gmail.com>

Hello Vivek,

thanks for the interest in our project


On Wed, Feb 19, 2014 at 11:34 AM, Vivek Pandey <vivek.pandey at pinelabs.com>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: <CAAg5f2TGzP=Ffh9sGTV0DhXYQXp_S=FC-3zX5z_Mr8ckP-eUvA@mail.gmail.com>
References: <02c501cf2d5e$2b757f10$82607d30$@pinelabs.com>
	<CAAg5f2TGzP=Ffh9sGTV0DhXYQXp_S=FC-3zX5z_Mr8ckP-eUvA@mail.gmail.com>
Message-ID: <CAAg5f2T=8nnd67_RYwujaA08q9Ctk+o_OJ+ufjWd2CxFeJZyhQ@mail.gmail.com>

On Wed, Feb 19, 2014 at 11:41 AM, Matthias Wessendorf <matzew at apache.org>wrote:

> Hello Vivek,
>
> thanks for the interest in our project
>
>
> On Wed, Feb 19, 2014 at 11:34 AM, Vivek Pandey <vivek.pandey at pinelabs.com>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: <CAAg5f2S2sf5Qwu0p0LZGyK+z=8PEeP3hZ0vjYTRBV3u8_q58sA@mail.gmail.com>

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: <CAD_dpu3HJ0jri8MGcE3rFgY5YWwpdsJ8-U6HUf42QEoq_aEo-Q@mail.gmail.com>
References: <CADPUygeFVLtskRVAqJ8o8o2Zu5Jtu64cyyAODdja=gCdbTJwsQ@mail.gmail.com>
	<CAD_dpu0MnENNhUA2srMAgLeSPJRw8ufTB3M6Fr0CF23CJLNwzg@mail.gmail.com>
	<CADPUyge8EPKVAnT4fh6Lccgiyvt4d-1J8hP=7kNaXmGGCKAyMg@mail.gmail.com>
	<CAAg5f2QcXHA1V7vC5VqJ8Ns=4MKgAU=Cx4CHS1u+kgqFNVenNw@mail.gmail.com>
	<CAD_dpu3HJ0jri8MGcE3rFgY5YWwpdsJ8-U6HUf42QEoq_aEo-Q@mail.gmail.com>
Message-ID: <CAL8vO=cF3SBQP7ZohdERQBqoX78ZFxAS_dx2wQB+o76UsBGDHw@mail.gmail.com>

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 <scm.blanc at gmail.com> wrote:

>
>
>
> On Wed, Feb 19, 2014 at 11:08 AM, Matthias Wessendorf <matzew at apache.org>wrote:
>
>>
>>
>>
>> On Wed, Feb 19, 2014 at 10:53 AM, Miguel Lemos <miguel21op at gmail.com>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: <CAAg5f2S2sf5Qwu0p0LZGyK+z=8PEeP3hZ0vjYTRBV3u8_q58sA@mail.gmail.com>
References: <CAAg5f2S2sf5Qwu0p0LZGyK+z=8PEeP3hZ0vjYTRBV3u8_q58sA@mail.gmail.com>
Message-ID: <etPan.5304a0bc.6b8b4567.1f77@animus>

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: <CAL8vO=cF3SBQP7ZohdERQBqoX78ZFxAS_dx2wQB+o76UsBGDHw@mail.gmail.com>
References: <CADPUygeFVLtskRVAqJ8o8o2Zu5Jtu64cyyAODdja=gCdbTJwsQ@mail.gmail.com>
	<CAD_dpu0MnENNhUA2srMAgLeSPJRw8ufTB3M6Fr0CF23CJLNwzg@mail.gmail.com>
	<CADPUyge8EPKVAnT4fh6Lccgiyvt4d-1J8hP=7kNaXmGGCKAyMg@mail.gmail.com>
	<CAAg5f2QcXHA1V7vC5VqJ8Ns=4MKgAU=Cx4CHS1u+kgqFNVenNw@mail.gmail.com>
	<CAD_dpu3HJ0jri8MGcE3rFgY5YWwpdsJ8-U6HUf42QEoq_aEo-Q@mail.gmail.com>
	<CAL8vO=cF3SBQP7ZohdERQBqoX78ZFxAS_dx2wQB+o76UsBGDHw@mail.gmail.com>
Message-ID: <CADPUygcLFKeFsQz9F4Yvi1FphJw_B0deRTt3YqTXHqUts9QEZw@mail.gmail.com>

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: <CADPUygcLFKeFsQz9F4Yvi1FphJw_B0deRTt3YqTXHqUts9QEZw@mail.gmail.com>
References: <CADPUygeFVLtskRVAqJ8o8o2Zu5Jtu64cyyAODdja=gCdbTJwsQ@mail.gmail.com>
	<CAD_dpu0MnENNhUA2srMAgLeSPJRw8ufTB3M6Fr0CF23CJLNwzg@mail.gmail.com>
	<CADPUyge8EPKVAnT4fh6Lccgiyvt4d-1J8hP=7kNaXmGGCKAyMg@mail.gmail.com>
	<CAAg5f2QcXHA1V7vC5VqJ8Ns=4MKgAU=Cx4CHS1u+kgqFNVenNw@mail.gmail.com>
	<CAD_dpu3HJ0jri8MGcE3rFgY5YWwpdsJ8-U6HUf42QEoq_aEo-Q@mail.gmail.com>
	<CAL8vO=cF3SBQP7ZohdERQBqoX78ZFxAS_dx2wQB+o76UsBGDHw@mail.gmail.com>
	<CADPUygcLFKeFsQz9F4Yvi1FphJw_B0deRTt3YqTXHqUts9QEZw@mail.gmail.com>
Message-ID: <CAAg5f2RtBWFfFs7-Ahiovj=2nzrCU3-mjzVbY+SVL5zW_axFfw@mail.gmail.com>

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
-------------- 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: <CAAg5f2RtBWFfFs7-Ahiovj=2nzrCU3-mjzVbY+SVL5zW_axFfw@mail.gmail.com>
References: <CADPUygeFVLtskRVAqJ8o8o2Zu5Jtu64cyyAODdja=gCdbTJwsQ@mail.gmail.com>
	<CAD_dpu0MnENNhUA2srMAgLeSPJRw8ufTB3M6Fr0CF23CJLNwzg@mail.gmail.com>
	<CADPUyge8EPKVAnT4fh6Lccgiyvt4d-1J8hP=7kNaXmGGCKAyMg@mail.gmail.com>
	<CAAg5f2QcXHA1V7vC5VqJ8Ns=4MKgAU=Cx4CHS1u+kgqFNVenNw@mail.gmail.com>
	<CAD_dpu3HJ0jri8MGcE3rFgY5YWwpdsJ8-U6HUf42QEoq_aEo-Q@mail.gmail.com>
	<CAL8vO=cF3SBQP7ZohdERQBqoX78ZFxAS_dx2wQB+o76UsBGDHw@mail.gmail.com>
	<CADPUygcLFKeFsQz9F4Yvi1FphJw_B0deRTt3YqTXHqUts9QEZw@mail.gmail.com>
	<CAAg5f2RtBWFfFs7-Ahiovj=2nzrCU3-mjzVbY+SVL5zW_axFfw@mail.gmail.com>
Message-ID: <CADPUygdtuUsnGgvZ6B8bjFrX7t=UVUFy6p7_oJzu5cU3S=pYcQ@mail.gmail.com>

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 <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
>
-------------- 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: <CADPUygdtuUsnGgvZ6B8bjFrX7t=UVUFy6p7_oJzu5cU3S=pYcQ@mail.gmail.com>
References: <CADPUygeFVLtskRVAqJ8o8o2Zu5Jtu64cyyAODdja=gCdbTJwsQ@mail.gmail.com>
	<CAD_dpu0MnENNhUA2srMAgLeSPJRw8ufTB3M6Fr0CF23CJLNwzg@mail.gmail.com>
	<CADPUyge8EPKVAnT4fh6Lccgiyvt4d-1J8hP=7kNaXmGGCKAyMg@mail.gmail.com>
	<CAAg5f2QcXHA1V7vC5VqJ8Ns=4MKgAU=Cx4CHS1u+kgqFNVenNw@mail.gmail.com>
	<CAD_dpu3HJ0jri8MGcE3rFgY5YWwpdsJ8-U6HUf42QEoq_aEo-Q@mail.gmail.com>
	<CAL8vO=cF3SBQP7ZohdERQBqoX78ZFxAS_dx2wQB+o76UsBGDHw@mail.gmail.com>
	<CADPUygcLFKeFsQz9F4Yvi1FphJw_B0deRTt3YqTXHqUts9QEZw@mail.gmail.com>
	<CAAg5f2RtBWFfFs7-Ahiovj=2nzrCU3-mjzVbY+SVL5zW_axFfw@mail.gmail.com>
	<CADPUygdtuUsnGgvZ6B8bjFrX7t=UVUFy6p7_oJzu5cU3S=pYcQ@mail.gmail.com>
Message-ID: <CAAg5f2QTqNi3uB4ZwLg-HEDZVgM2oJqxZyB2=QUq_d7srJe1ng@mail.gmail.com>

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
-------------- 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: <CAAg5f2QTqNi3uB4ZwLg-HEDZVgM2oJqxZyB2=QUq_d7srJe1ng@mail.gmail.com>
References: <CADPUygeFVLtskRVAqJ8o8o2Zu5Jtu64cyyAODdja=gCdbTJwsQ@mail.gmail.com>
	<CAD_dpu0MnENNhUA2srMAgLeSPJRw8ufTB3M6Fr0CF23CJLNwzg@mail.gmail.com>
	<CADPUyge8EPKVAnT4fh6Lccgiyvt4d-1J8hP=7kNaXmGGCKAyMg@mail.gmail.com>
	<CAAg5f2QcXHA1V7vC5VqJ8Ns=4MKgAU=Cx4CHS1u+kgqFNVenNw@mail.gmail.com>
	<CAD_dpu3HJ0jri8MGcE3rFgY5YWwpdsJ8-U6HUf42QEoq_aEo-Q@mail.gmail.com>
	<CAL8vO=cF3SBQP7ZohdERQBqoX78ZFxAS_dx2wQB+o76UsBGDHw@mail.gmail.com>
	<CADPUygcLFKeFsQz9F4Yvi1FphJw_B0deRTt3YqTXHqUts9QEZw@mail.gmail.com>
	<CAAg5f2RtBWFfFs7-Ahiovj=2nzrCU3-mjzVbY+SVL5zW_axFfw@mail.gmail.com>
	<CADPUygdtuUsnGgvZ6B8bjFrX7t=UVUFy6p7_oJzu5cU3S=pYcQ@mail.gmail.com>
	<CAAg5f2QTqNi3uB4ZwLg-HEDZVgM2oJqxZyB2=QUq_d7srJe1ng@mail.gmail.com>
Message-ID: <CADPUygdtnHe455OK==c1B94EfEQkkT9k_Jz4ceU+-VRqo=Y=jQ@mail.gmail.com>

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
>
-------------- 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: <CADPUygdtnHe455OK==c1B94EfEQkkT9k_Jz4ceU+-VRqo=Y=jQ@mail.gmail.com>
References: <CADPUygeFVLtskRVAqJ8o8o2Zu5Jtu64cyyAODdja=gCdbTJwsQ@mail.gmail.com>
	<CAD_dpu0MnENNhUA2srMAgLeSPJRw8ufTB3M6Fr0CF23CJLNwzg@mail.gmail.com>
	<CADPUyge8EPKVAnT4fh6Lccgiyvt4d-1J8hP=7kNaXmGGCKAyMg@mail.gmail.com>
	<CAAg5f2QcXHA1V7vC5VqJ8Ns=4MKgAU=Cx4CHS1u+kgqFNVenNw@mail.gmail.com>
	<CAD_dpu3HJ0jri8MGcE3rFgY5YWwpdsJ8-U6HUf42QEoq_aEo-Q@mail.gmail.com>
	<CAL8vO=cF3SBQP7ZohdERQBqoX78ZFxAS_dx2wQB+o76UsBGDHw@mail.gmail.com>
	<CADPUygcLFKeFsQz9F4Yvi1FphJw_B0deRTt3YqTXHqUts9QEZw@mail.gmail.com>
	<CAAg5f2RtBWFfFs7-Ahiovj=2nzrCU3-mjzVbY+SVL5zW_axFfw@mail.gmail.com>
	<CADPUygdtuUsnGgvZ6B8bjFrX7t=UVUFy6p7_oJzu5cU3S=pYcQ@mail.gmail.com>
	<CAAg5f2QTqNi3uB4ZwLg-HEDZVgM2oJqxZyB2=QUq_d7srJe1ng@mail.gmail.com>
	<CADPUygdtnHe455OK==c1B94EfEQkkT9k_Jz4ceU+-VRqo=Y=jQ@mail.gmail.com>
Message-ID: <CAAg5f2Tp0wJ0uORQ6mRnHSQtvBAMrewcj5g4B7N3Y_-3=Jjuzw@mail.gmail.com>

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
-------------- 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: <CAAg5f2Tp0wJ0uORQ6mRnHSQtvBAMrewcj5g4B7N3Y_-3=Jjuzw@mail.gmail.com>
References: <CADPUygeFVLtskRVAqJ8o8o2Zu5Jtu64cyyAODdja=gCdbTJwsQ@mail.gmail.com>
	<CAD_dpu0MnENNhUA2srMAgLeSPJRw8ufTB3M6Fr0CF23CJLNwzg@mail.gmail.com>
	<CADPUyge8EPKVAnT4fh6Lccgiyvt4d-1J8hP=7kNaXmGGCKAyMg@mail.gmail.com>
	<CAAg5f2QcXHA1V7vC5VqJ8Ns=4MKgAU=Cx4CHS1u+kgqFNVenNw@mail.gmail.com>
	<CAD_dpu3HJ0jri8MGcE3rFgY5YWwpdsJ8-U6HUf42QEoq_aEo-Q@mail.gmail.com>
	<CAL8vO=cF3SBQP7ZohdERQBqoX78ZFxAS_dx2wQB+o76UsBGDHw@mail.gmail.com>
	<CADPUygcLFKeFsQz9F4Yvi1FphJw_B0deRTt3YqTXHqUts9QEZw@mail.gmail.com>
	<CAAg5f2RtBWFfFs7-Ahiovj=2nzrCU3-mjzVbY+SVL5zW_axFfw@mail.gmail.com>
	<CADPUygdtuUsnGgvZ6B8bjFrX7t=UVUFy6p7_oJzu5cU3S=pYcQ@mail.gmail.com>
	<CAAg5f2QTqNi3uB4ZwLg-HEDZVgM2oJqxZyB2=QUq_d7srJe1ng@mail.gmail.com>
	<CADPUygdtnHe455OK==c1B94EfEQkkT9k_Jz4ceU+-VRqo=Y=jQ@mail.gmail.com>
	<CAAg5f2Tp0wJ0uORQ6mRnHSQtvBAMrewcj5g4B7N3Y_-3=Jjuzw@mail.gmail.com>
Message-ID: <CADPUygeiExOFXdLEJRDGP1Ug8D0sE3tndCa+t17J_dJ96pbTYA@mail.gmail.com>

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 <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
>
-------------- 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: <CADPUygeiExOFXdLEJRDGP1Ug8D0sE3tndCa+t17J_dJ96pbTYA@mail.gmail.com>
References: <CADPUygeFVLtskRVAqJ8o8o2Zu5Jtu64cyyAODdja=gCdbTJwsQ@mail.gmail.com>
	<CAD_dpu0MnENNhUA2srMAgLeSPJRw8ufTB3M6Fr0CF23CJLNwzg@mail.gmail.com>
	<CADPUyge8EPKVAnT4fh6Lccgiyvt4d-1J8hP=7kNaXmGGCKAyMg@mail.gmail.com>
	<CAAg5f2QcXHA1V7vC5VqJ8Ns=4MKgAU=Cx4CHS1u+kgqFNVenNw@mail.gmail.com>
	<CAD_dpu3HJ0jri8MGcE3rFgY5YWwpdsJ8-U6HUf42QEoq_aEo-Q@mail.gmail.com>
	<CAL8vO=cF3SBQP7ZohdERQBqoX78ZFxAS_dx2wQB+o76UsBGDHw@mail.gmail.com>
	<CADPUygcLFKeFsQz9F4Yvi1FphJw_B0deRTt3YqTXHqUts9QEZw@mail.gmail.com>
	<CAAg5f2RtBWFfFs7-Ahiovj=2nzrCU3-mjzVbY+SVL5zW_axFfw@mail.gmail.com>
	<CADPUygdtuUsnGgvZ6B8bjFrX7t=UVUFy6p7_oJzu5cU3S=pYcQ@mail.gmail.com>
	<CAAg5f2QTqNi3uB4ZwLg-HEDZVgM2oJqxZyB2=QUq_d7srJe1ng@mail.gmail.com>
	<CADPUygdtnHe455OK==c1B94EfEQkkT9k_Jz4ceU+-VRqo=Y=jQ@mail.gmail.com>
	<CAAg5f2Tp0wJ0uORQ6mRnHSQtvBAMrewcj5g4B7N3Y_-3=Jjuzw@mail.gmail.com>
	<CADPUygeiExOFXdLEJRDGP1Ug8D0sE3tndCa+t17J_dJ96pbTYA@mail.gmail.com>
Message-ID: <CAAg5f2Sd5XB8dhPeRPjyNKpLQD3inPk9YjhhhHugYDuqDBZPbw@mail.gmail.com>

On Wed, Feb 19, 2014 at 3:43 PM, Miguel Lemos <miguel21op at gmail.com> 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
-------------- 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: <CAAg5f2Sd5XB8dhPeRPjyNKpLQD3inPk9YjhhhHugYDuqDBZPbw@mail.gmail.com>
References: <CADPUygeFVLtskRVAqJ8o8o2Zu5Jtu64cyyAODdja=gCdbTJwsQ@mail.gmail.com>
	<CAD_dpu0MnENNhUA2srMAgLeSPJRw8ufTB3M6Fr0CF23CJLNwzg@mail.gmail.com>
	<CADPUyge8EPKVAnT4fh6Lccgiyvt4d-1J8hP=7kNaXmGGCKAyMg@mail.gmail.com>
	<CAAg5f2QcXHA1V7vC5VqJ8Ns=4MKgAU=Cx4CHS1u+kgqFNVenNw@mail.gmail.com>
	<CAD_dpu3HJ0jri8MGcE3rFgY5YWwpdsJ8-U6HUf42QEoq_aEo-Q@mail.gmail.com>
	<CAL8vO=cF3SBQP7ZohdERQBqoX78ZFxAS_dx2wQB+o76UsBGDHw@mail.gmail.com>
	<CADPUygcLFKeFsQz9F4Yvi1FphJw_B0deRTt3YqTXHqUts9QEZw@mail.gmail.com>
	<CAAg5f2RtBWFfFs7-Ahiovj=2nzrCU3-mjzVbY+SVL5zW_axFfw@mail.gmail.com>
	<CADPUygdtuUsnGgvZ6B8bjFrX7t=UVUFy6p7_oJzu5cU3S=pYcQ@mail.gmail.com>
	<CAAg5f2QTqNi3uB4ZwLg-HEDZVgM2oJqxZyB2=QUq_d7srJe1ng@mail.gmail.com>
	<CADPUygdtnHe455OK==c1B94EfEQkkT9k_Jz4ceU+-VRqo=Y=jQ@mail.gmail.com>
	<CAAg5f2Tp0wJ0uORQ6mRnHSQtvBAMrewcj5g4B7N3Y_-3=Jjuzw@mail.gmail.com>
	<CADPUygeiExOFXdLEJRDGP1Ug8D0sE3tndCa+t17J_dJ96pbTYA@mail.gmail.com>
	<CAAg5f2Sd5XB8dhPeRPjyNKpLQD3inPk9YjhhhHugYDuqDBZPbw@mail.gmail.com>
Message-ID: <CADPUygfyVm56Tf58qJxUw=q658=xstRuJj0A8OY1+V=nEkrGMA@mail.gmail.com>

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 <miguel21op at gmail.com>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
>
-------------- 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: <CADPUygfyVm56Tf58qJxUw=q658=xstRuJj0A8OY1+V=nEkrGMA@mail.gmail.com>
References: <CADPUygeFVLtskRVAqJ8o8o2Zu5Jtu64cyyAODdja=gCdbTJwsQ@mail.gmail.com>
	<CAD_dpu0MnENNhUA2srMAgLeSPJRw8ufTB3M6Fr0CF23CJLNwzg@mail.gmail.com>
	<CADPUyge8EPKVAnT4fh6Lccgiyvt4d-1J8hP=7kNaXmGGCKAyMg@mail.gmail.com>
	<CAAg5f2QcXHA1V7vC5VqJ8Ns=4MKgAU=Cx4CHS1u+kgqFNVenNw@mail.gmail.com>
	<CAD_dpu3HJ0jri8MGcE3rFgY5YWwpdsJ8-U6HUf42QEoq_aEo-Q@mail.gmail.com>
	<CAL8vO=cF3SBQP7ZohdERQBqoX78ZFxAS_dx2wQB+o76UsBGDHw@mail.gmail.com>
	<CADPUygcLFKeFsQz9F4Yvi1FphJw_B0deRTt3YqTXHqUts9QEZw@mail.gmail.com>
	<CAAg5f2RtBWFfFs7-Ahiovj=2nzrCU3-mjzVbY+SVL5zW_axFfw@mail.gmail.com>
	<CADPUygdtuUsnGgvZ6B8bjFrX7t=UVUFy6p7_oJzu5cU3S=pYcQ@mail.gmail.com>
	<CAAg5f2QTqNi3uB4ZwLg-HEDZVgM2oJqxZyB2=QUq_d7srJe1ng@mail.gmail.com>
	<CADPUygdtnHe455OK==c1B94EfEQkkT9k_Jz4ceU+-VRqo=Y=jQ@mail.gmail.com>
	<CAAg5f2Tp0wJ0uORQ6mRnHSQtvBAMrewcj5g4B7N3Y_-3=Jjuzw@mail.gmail.com>
	<CADPUygeiExOFXdLEJRDGP1Ug8D0sE3tndCa+t17J_dJ96pbTYA@mail.gmail.com>
	<CAAg5f2Sd5XB8dhPeRPjyNKpLQD3inPk9YjhhhHugYDuqDBZPbw@mail.gmail.com>
	<CADPUygfyVm56Tf58qJxUw=q658=xstRuJj0A8OY1+V=nEkrGMA@mail.gmail.com>
Message-ID: <CADPUygeCTcMoW1HFUZbJtxzy2O-HfMxeY23VhSPevf+f=vdm9g@mail.gmail.com>

A small souvenir ;-)

Thanks again




On Wed, Feb 19, 2014 at 3:20 PM, Miguel Lemos <miguel21op at gmail.com> 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 <miguel21op at gmail.com>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
>>
>
>
-------------- 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: <CADPUygeCTcMoW1HFUZbJtxzy2O-HfMxeY23VhSPevf+f=vdm9g@mail.gmail.com>
References: <CADPUygeFVLtskRVAqJ8o8o2Zu5Jtu64cyyAODdja=gCdbTJwsQ@mail.gmail.com>
	<CAD_dpu0MnENNhUA2srMAgLeSPJRw8ufTB3M6Fr0CF23CJLNwzg@mail.gmail.com>
	<CADPUyge8EPKVAnT4fh6Lccgiyvt4d-1J8hP=7kNaXmGGCKAyMg@mail.gmail.com>
	<CAAg5f2QcXHA1V7vC5VqJ8Ns=4MKgAU=Cx4CHS1u+kgqFNVenNw@mail.gmail.com>
	<CAD_dpu3HJ0jri8MGcE3rFgY5YWwpdsJ8-U6HUf42QEoq_aEo-Q@mail.gmail.com>
	<CAL8vO=cF3SBQP7ZohdERQBqoX78ZFxAS_dx2wQB+o76UsBGDHw@mail.gmail.com>
	<CADPUygcLFKeFsQz9F4Yvi1FphJw_B0deRTt3YqTXHqUts9QEZw@mail.gmail.com>
	<CAAg5f2RtBWFfFs7-Ahiovj=2nzrCU3-mjzVbY+SVL5zW_axFfw@mail.gmail.com>
	<CADPUygdtuUsnGgvZ6B8bjFrX7t=UVUFy6p7_oJzu5cU3S=pYcQ@mail.gmail.com>
	<CAAg5f2QTqNi3uB4ZwLg-HEDZVgM2oJqxZyB2=QUq_d7srJe1ng@mail.gmail.com>
	<CADPUygdtnHe455OK==c1B94EfEQkkT9k_Jz4ceU+-VRqo=Y=jQ@mail.gmail.com>
	<CAAg5f2Tp0wJ0uORQ6mRnHSQtvBAMrewcj5g4B7N3Y_-3=Jjuzw@mail.gmail.com>
	<CADPUygeiExOFXdLEJRDGP1Ug8D0sE3tndCa+t17J_dJ96pbTYA@mail.gmail.com>
	<CAAg5f2Sd5XB8dhPeRPjyNKpLQD3inPk9YjhhhHugYDuqDBZPbw@mail.gmail.com>
	<CADPUygfyVm56Tf58qJxUw=q658=xstRuJj0A8OY1+V=nEkrGMA@mail.gmail.com>
	<CADPUygeCTcMoW1HFUZbJtxzy2O-HfMxeY23VhSPevf+f=vdm9g@mail.gmail.com>
Message-ID: <CAAg5f2Tw4FPMKLHqXo9WDkxsiHFsKg=p5ZK=nvPuXwx+eWK2hw@mail.gmail.com>

Nice!

Glad you are all set!

-Matthias


On Wed, Feb 19, 2014 at 4:38 PM, Miguel Lemos <miguel21op at gmail.com> wrote:

> A small souvenir ;-)
>
> Thanks again
>
>
>
>
> On Wed, Feb 19, 2014 at 3:20 PM, Miguel Lemos <miguel21op at gmail.com>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 <miguel21op at gmail.com>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
-------------- 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: <CAAg5f2Tw4FPMKLHqXo9WDkxsiHFsKg=p5ZK=nvPuXwx+eWK2hw@mail.gmail.com>
References: <CADPUygeFVLtskRVAqJ8o8o2Zu5Jtu64cyyAODdja=gCdbTJwsQ@mail.gmail.com>
	<CAD_dpu0MnENNhUA2srMAgLeSPJRw8ufTB3M6Fr0CF23CJLNwzg@mail.gmail.com>
	<CADPUyge8EPKVAnT4fh6Lccgiyvt4d-1J8hP=7kNaXmGGCKAyMg@mail.gmail.com>
	<CAAg5f2QcXHA1V7vC5VqJ8Ns=4MKgAU=Cx4CHS1u+kgqFNVenNw@mail.gmail.com>
	<CAD_dpu3HJ0jri8MGcE3rFgY5YWwpdsJ8-U6HUf42QEoq_aEo-Q@mail.gmail.com>
	<CAL8vO=cF3SBQP7ZohdERQBqoX78ZFxAS_dx2wQB+o76UsBGDHw@mail.gmail.com>
	<CADPUygcLFKeFsQz9F4Yvi1FphJw_B0deRTt3YqTXHqUts9QEZw@mail.gmail.com>
	<CAAg5f2RtBWFfFs7-Ahiovj=2nzrCU3-mjzVbY+SVL5zW_axFfw@mail.gmail.com>
	<CADPUygdtuUsnGgvZ6B8bjFrX7t=UVUFy6p7_oJzu5cU3S=pYcQ@mail.gmail.com>
	<CAAg5f2QTqNi3uB4ZwLg-HEDZVgM2oJqxZyB2=QUq_d7srJe1ng@mail.gmail.com>
	<CADPUygdtnHe455OK==c1B94EfEQkkT9k_Jz4ceU+-VRqo=Y=jQ@mail.gmail.com>
	<CAAg5f2Tp0wJ0uORQ6mRnHSQtvBAMrewcj5g4B7N3Y_-3=Jjuzw@mail.gmail.com>
	<CADPUygeiExOFXdLEJRDGP1Ug8D0sE3tndCa+t17J_dJ96pbTYA@mail.gmail.com>
	<CAAg5f2Sd5XB8dhPeRPjyNKpLQD3inPk9YjhhhHugYDuqDBZPbw@mail.gmail.com>
	<CADPUygfyVm56Tf58qJxUw=q658=xstRuJj0A8OY1+V=nEkrGMA@mail.gmail.com>
	<CADPUygeCTcMoW1HFUZbJtxzy2O-HfMxeY23VhSPevf+f=vdm9g@mail.gmail.com>
	<CAAg5f2Tw4FPMKLHqXo9WDkxsiHFsKg=p5ZK=nvPuXwx+eWK2hw@mail.gmail.com>
Message-ID: <D00391E3-0041-4E20-AD72-5C669BE991F4@gmail.com>

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 <matzew at apache.org> escreveu:

> Nice!
> 
> Glad you are all set!
> 
> -Matthias
> 
> 
>> On Wed, Feb 19, 2014 at 4:38 PM, Miguel Lemos <miguel21op at gmail.com> wrote:
>> A small souvenir ;-)
>> 
>> Thanks again
>> 
>> 
>> 
>> 
>>> On Wed, Feb 19, 2014 at 3:20 PM, Miguel Lemos <miguel21op at gmail.com> 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 <miguel21op at gmail.com> 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
-------------- 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: <D00391E3-0041-4E20-AD72-5C669BE991F4@gmail.com>
References: <CADPUygeFVLtskRVAqJ8o8o2Zu5Jtu64cyyAODdja=gCdbTJwsQ@mail.gmail.com>
	<CAD_dpu0MnENNhUA2srMAgLeSPJRw8ufTB3M6Fr0CF23CJLNwzg@mail.gmail.com>
	<CADPUyge8EPKVAnT4fh6Lccgiyvt4d-1J8hP=7kNaXmGGCKAyMg@mail.gmail.com>
	<CAAg5f2QcXHA1V7vC5VqJ8Ns=4MKgAU=Cx4CHS1u+kgqFNVenNw@mail.gmail.com>
	<CAD_dpu3HJ0jri8MGcE3rFgY5YWwpdsJ8-U6HUf42QEoq_aEo-Q@mail.gmail.com>
	<CAL8vO=cF3SBQP7ZohdERQBqoX78ZFxAS_dx2wQB+o76UsBGDHw@mail.gmail.com>
	<CADPUygcLFKeFsQz9F4Yvi1FphJw_B0deRTt3YqTXHqUts9QEZw@mail.gmail.com>
	<CAAg5f2RtBWFfFs7-Ahiovj=2nzrCU3-mjzVbY+SVL5zW_axFfw@mail.gmail.com>
	<CADPUygdtuUsnGgvZ6B8bjFrX7t=UVUFy6p7_oJzu5cU3S=pYcQ@mail.gmail.com>
	<CAAg5f2QTqNi3uB4ZwLg-HEDZVgM2oJqxZyB2=QUq_d7srJe1ng@mail.gmail.com>
	<CADPUygdtnHe455OK==c1B94EfEQkkT9k_Jz4ceU+-VRqo=Y=jQ@mail.gmail.com>
	<CAAg5f2Tp0wJ0uORQ6mRnHSQtvBAMrewcj5g4B7N3Y_-3=Jjuzw@mail.gmail.com>
	<CADPUygeiExOFXdLEJRDGP1Ug8D0sE3tndCa+t17J_dJ96pbTYA@mail.gmail.com>
	<CAAg5f2Sd5XB8dhPeRPjyNKpLQD3inPk9YjhhhHugYDuqDBZPbw@mail.gmail.com>
	<CADPUygfyVm56Tf58qJxUw=q658=xstRuJj0A8OY1+V=nEkrGMA@mail.gmail.com>
	<CADPUygeCTcMoW1HFUZbJtxzy2O-HfMxeY23VhSPevf+f=vdm9g@mail.gmail.com>
	<CAAg5f2Tw4FPMKLHqXo9WDkxsiHFsKg=p5ZK=nvPuXwx+eWK2hw@mail.gmail.com>
	<D00391E3-0041-4E20-AD72-5C669BE991F4@gmail.com>
Message-ID: <CAD_dpu1_6eVjBDa+++QvKqQ+=cjevMb=juxtEsHWnPo5g1en5Q@mail.gmail.com>

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 <miguel21op at gmail.com> 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 <matzew at apache.org>
> escreveu:
>
> Nice!
>
> Glad you are all set!
>
> -Matthias
>
>
> On Wed, Feb 19, 2014 at 4:38 PM, Miguel Lemos <miguel21op at gmail.com>wrote:
>
>> A small souvenir ;-)
>>
>> Thanks again
>>
>>
>>
>>
>> On Wed, Feb 19, 2014 at 3:20 PM, Miguel Lemos <miguel21op at gmail.com>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 <miguel21op at gmail.com>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
>
-------------- 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: <etPan.53025153.625558ec.13b96@animus>
References: <CAAg5f2Q3n2DQitVn4w1xyG16kkWxD7-WmM2_KK3cZHuNDhvFkw@mail.gmail.com>
	<etPan.53025153.625558ec.13b96@animus>
Message-ID: <CAAg5f2RO27qATW994p6mLGzZn+Jsd+YAaOv=5rPJ8OX86qL9+g@mail.gmail.com>

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 <bruno at abstractj.org> 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: <CAL8vO=f12i8Ya8mjNsHwAodXEzYynkJxWgs4zJJDnH9Zk_hEZw@mail.gmail.com>

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 <cvasilak at gmail.com> 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: <CAD_dpu3+4SuiQEEgjotYUXdNtQTpKp5YCoQAx-KxXL8W5E88CQ@mail.gmail.com>
References: <CAD_dpu0N+F5C78OF=meS9n7gs1P6qnJi-0r8-ocTvGnQDFtFgw@mail.gmail.com>
	<96636ABC-EE3E-461D-A5F0-0BFBB4B79694@gmail.com>
	<CAD_dpu3+4SuiQEEgjotYUXdNtQTpKp5YCoQAx-KxXL8W5E88CQ@mail.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: <CAD_dpu0N+F5C78OF=meS9n7gs1P6qnJi-0r8-ocTvGnQDFtFgw@mail.gmail.com>
	<96636ABC-EE3E-461D-A5F0-0BFBB4B79694@gmail.com>
	<CAD_dpu3+4SuiQEEgjotYUXdNtQTpKp5YCoQAx-KxXL8W5E88CQ@mail.gmail.com>
	<349C158E-D1DE-4C35-BC31-1CEAF4395491@redhat.com>
Message-ID: <CAD_dpu3K5vgiGtrGin4nmWEvvq5tYHH66EiVW_cXO5geJsA9ng@mail.gmail.com>

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 <edewit at redhat.com> 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: <CAL8vO=f12i8Ya8mjNsHwAodXEzYynkJxWgs4zJJDnH9Zk_hEZw@mail.gmail.com>
References: <1911A638-4EBF-4C8C-8E33-1F08D6715BC3@gmail.com>
	<CAL8vO=f12i8Ya8mjNsHwAodXEzYynkJxWgs4zJJDnH9Zk_hEZw@mail.gmail.com>
Message-ID: <1B84AA5E-DAA5-4300-AE54-4FF5B8A17204@gmail.com>


On Feb 20, 2014, at 12:03 PM, Corinne Krych <corinnekrych at gmail.com> 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 <cvasilak at gmail.com> 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: <CAD_dpu0N+F5C78OF=meS9n7gs1P6qnJi-0r8-ocTvGnQDFtFgw@mail.gmail.com>
	<96636ABC-EE3E-461D-A5F0-0BFBB4B79694@gmail.com>
	<CAD_dpu3+4SuiQEEgjotYUXdNtQTpKp5YCoQAx-KxXL8W5E88CQ@mail.gmail.com>
	<349C158E-D1DE-4C35-BC31-1CEAF4395491@redhat.com>
Message-ID: <CAL8vO=eo1iSsZCrj4CmDe3nmwGa8B9wrZ5KRAfRad7KCOGZoZQ@mail.gmail.com>

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 <edewit at redhat.com> 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: <CAD_dpu1_6eVjBDa+++QvKqQ+=cjevMb=juxtEsHWnPo5g1en5Q@mail.gmail.com>
References: <CADPUygeFVLtskRVAqJ8o8o2Zu5Jtu64cyyAODdja=gCdbTJwsQ@mail.gmail.com>
	<CAD_dpu0MnENNhUA2srMAgLeSPJRw8ufTB3M6Fr0CF23CJLNwzg@mail.gmail.com>
	<CADPUyge8EPKVAnT4fh6Lccgiyvt4d-1J8hP=7kNaXmGGCKAyMg@mail.gmail.com>
	<CAAg5f2QcXHA1V7vC5VqJ8Ns=4MKgAU=Cx4CHS1u+kgqFNVenNw@mail.gmail.com>
	<CAD_dpu3HJ0jri8MGcE3rFgY5YWwpdsJ8-U6HUf42QEoq_aEo-Q@mail.gmail.com>
	<CAL8vO=cF3SBQP7ZohdERQBqoX78ZFxAS_dx2wQB+o76UsBGDHw@mail.gmail.com>
	<CADPUygcLFKeFsQz9F4Yvi1FphJw_B0deRTt3YqTXHqUts9QEZw@mail.gmail.com>
	<CAAg5f2RtBWFfFs7-Ahiovj=2nzrCU3-mjzVbY+SVL5zW_axFfw@mail.gmail.com>
	<CADPUygdtuUsnGgvZ6B8bjFrX7t=UVUFy6p7_oJzu5cU3S=pYcQ@mail.gmail.com>
	<CAAg5f2QTqNi3uB4ZwLg-HEDZVgM2oJqxZyB2=QUq_d7srJe1ng@mail.gmail.com>
	<CADPUygdtnHe455OK==c1B94EfEQkkT9k_Jz4ceU+-VRqo=Y=jQ@mail.gmail.com>
	<CAAg5f2Tp0wJ0uORQ6mRnHSQtvBAMrewcj5g4B7N3Y_-3=Jjuzw@mail.gmail.com>
	<CADPUygeiExOFXdLEJRDGP1Ug8D0sE3tndCa+t17J_dJ96pbTYA@mail.gmail.com>
	<CAAg5f2Sd5XB8dhPeRPjyNKpLQD3inPk9YjhhhHugYDuqDBZPbw@mail.gmail.com>
	<CADPUygfyVm56Tf58qJxUw=q658=xstRuJj0A8OY1+V=nEkrGMA@mail.gmail.com>
	<CADPUygeCTcMoW1HFUZbJtxzy2O-HfMxeY23VhSPevf+f=vdm9g@mail.gmail.com>
	<CAAg5f2Tw4FPMKLHqXo9WDkxsiHFsKg=p5ZK=nvPuXwx+eWK2hw@mail.gmail.com>
	<D00391E3-0041-4E20-AD72-5C669BE991F4@gmail.com>
	<CAD_dpu1_6eVjBDa+++QvKqQ+=cjevMb=juxtEsHWnPo5g1en5Q@mail.gmail.com>
Message-ID: <CADPUygcS-XkqfC4SUSjvC4qxQMF3wAwFo1etWh5w8Pf5bpzWCA@mail.gmail.com>

I'll be back ;-)
Em 20/02/2014 08:48, "Sebastien Blanc" <scm.blanc at gmail.com> 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 <miguel21op at gmail.com>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 <matzew at apache.org>
>> escreveu:
>>
>> Nice!
>>
>> Glad you are all set!
>>
>> -Matthias
>>
>>
>> On Wed, Feb 19, 2014 at 4:38 PM, Miguel Lemos <miguel21op at gmail.com>wrote:
>>
>>> A small souvenir ;-)
>>>
>>> Thanks again
>>>
>>>
>>>
>>>
>>> On Wed, Feb 19, 2014 at 3:20 PM, Miguel Lemos <miguel21op at gmail.com>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 <miguel21op at gmail.com>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
>
-------------- 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: <etPan.53063610.79e2a9e3.1f77@animus>

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 <hbons at redhat.com> 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: <etPan.53063c8d.7545e146.1f77@animus>

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: <CAD0N6pxDO8mxTG-z1E277hSPkKm+0Juh=1Ua5g6PknVv5hUMPw@mail.gmail.com>

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: <CAD0N6pxDO8mxTG-z1E277hSPkKm+0Juh=1Ua5g6PknVv5hUMPw@mail.gmail.com>
References: <CAD0N6pxDO8mxTG-z1E277hSPkKm+0Juh=1Ua5g6PknVv5hUMPw@mail.gmail.com>
Message-ID: <CAAg5f2S5TCfyLTGmHkYPpb=xHu4ixxQV=sjwOo5UzwWSsaYagg@mail.gmail.com>

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
<viktor.gamov at gmail.com<javascript:_e(%7B%7D,'cvml','viktor.gamov at gmail.com');>>
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: <CAD0N6pxDO8mxTG-z1E277hSPkKm+0Juh=1Ua5g6PknVv5hUMPw@mail.gmail.com>
References: <CAD0N6pxDO8mxTG-z1E277hSPkKm+0Juh=1Ua5g6PknVv5hUMPw@mail.gmail.com>
Message-ID: <E997285D-F2F4-488F-9890-D3C106DDAD49@redhat.com>

when you said small question,  did you mean the text size?  :)
On Feb 20, 2014, at 1:04 PM, Viktor Gamov <viktor.gamov at gmail.com> 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: <CAAg5f2Q=krkMe0U2Ra51PyZTQi_qCiO1RZ0DyYYCZtUE8RDgKA@mail.gmail.com>
References: <52EA3687.2050601@redhat.com>
	<CAAg5f2S2fQCA_LYf9kdTvUPmrgRD=PUHsFbu5-d-FrZ9LzQN4g@mail.gmail.com>
	<52EA39C6.8020607@redhat.com>
	<CAAg5f2S-E=dLWiqCQS7Vj0sw9+_C=2yrW2Fbiiph6iis7KP9-w@mail.gmail.com>
	<52EF9D46.6000306@redhat.com>
	<953401D5-1AA2-44BB-8240-859183299450@redhat.com>
	<CAAg5f2Q=krkMe0U2Ra51PyZTQi_qCiO1RZ0DyYYCZtUE8RDgKA@mail.gmail.com>
Message-ID: <79297C6E-D46C-468B-97E3-F3F8C3396F76@redhat.com>


On Feb 3, 2014, at 8:56 AM, Matthias Wessendorf <matzew at apache.org> wrote:

> 
> 
> 
> On Mon, Feb 3, 2014 at 2:52 PM, Lucas Holmquist <lholmqui at redhat.com> wrote:
> 
> On Feb 3, 2014, at 8:44 AM, Hylke Bons <hbons at redhat.com> 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 <hbons at redhat.com> 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 <hbons at redhat.com> 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>
	<CAAg5f2S2fQCA_LYf9kdTvUPmrgRD=PUHsFbu5-d-FrZ9LzQN4g@mail.gmail.com>
	<52EA39C6.8020607@redhat.com>
	<CAAg5f2S-E=dLWiqCQS7Vj0sw9+_C=2yrW2Fbiiph6iis7KP9-w@mail.gmail.com>
	<52EF9D46.6000306@redhat.com>
	<953401D5-1AA2-44BB-8240-859183299450@redhat.com>
	<CAAg5f2Q=krkMe0U2Ra51PyZTQi_qCiO1RZ0DyYYCZtUE8RDgKA@mail.gmail.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>
	<CAAg5f2S2fQCA_LYf9kdTvUPmrgRD=PUHsFbu5-d-FrZ9LzQN4g@mail.gmail.com>
	<52EA39C6.8020607@redhat.com>
	<CAAg5f2S-E=dLWiqCQS7Vj0sw9+_C=2yrW2Fbiiph6iis7KP9-w@mail.gmail.com>
	<52EF9D46.6000306@redhat.com>
	<953401D5-1AA2-44BB-8240-859183299450@redhat.com>
	<CAAg5f2Q=krkMe0U2Ra51PyZTQi_qCiO1RZ0DyYYCZtUE8RDgKA@mail.gmail.com>
	<79297C6E-D46C-468B-97E3-F3F8C3396F76@redhat.com>
	<20140220210758.GW51006@rohan.local>
Message-ID: <CAAg5f2TzcMBiozkvEv+3FFR=3q9i-1YWi9=pND7fCDUPY=KNPA@mail.gmail.com>

@__aerogear or @_aerogear ?




On Thu, Feb 20, 2014 at 10:07 PM, Douglas Campos <qmx at qmx.me> 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: <CAAg5f2TzcMBiozkvEv+3FFR=3q9i-1YWi9=pND7fCDUPY=KNPA@mail.gmail.com>
References: <52EA3687.2050601@redhat.com>
	<CAAg5f2S2fQCA_LYf9kdTvUPmrgRD=PUHsFbu5-d-FrZ9LzQN4g@mail.gmail.com>
	<52EA39C6.8020607@redhat.com>
	<CAAg5f2S-E=dLWiqCQS7Vj0sw9+_C=2yrW2Fbiiph6iis7KP9-w@mail.gmail.com>
	<52EF9D46.6000306@redhat.com>
	<953401D5-1AA2-44BB-8240-859183299450@redhat.com>
	<CAAg5f2Q=krkMe0U2Ra51PyZTQi_qCiO1RZ0DyYYCZtUE8RDgKA@mail.gmail.com>
	<79297C6E-D46C-468B-97E3-F3F8C3396F76@redhat.com>
	<20140220210758.GW51006@rohan.local>
	<CAAg5f2TzcMBiozkvEv+3FFR=3q9i-1YWi9=pND7fCDUPY=KNPA@mail.gmail.com>
Message-ID: <CAAg5f2Te=pPpj7cP0su6wyN18X9tN5x-S6wn+Nvs05Hc9cskDg@mail.gmail.com>

Actually, @aerogear_project makes sense (see @netty_project)


On Thu, Feb 20, 2014 at 10:35 PM, Matthias Wessendorf <matzew at apache.org>wrote:

> @__aerogear or @_aerogear ?
>
>
>
>
> On Thu, Feb 20, 2014 at 10:07 PM, Douglas Campos <qmx at qmx.me> 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: <CAAg5f2Te=pPpj7cP0su6wyN18X9tN5x-S6wn+Nvs05Hc9cskDg@mail.gmail.com>
References: <52EA3687.2050601@redhat.com>
	<CAAg5f2S2fQCA_LYf9kdTvUPmrgRD=PUHsFbu5-d-FrZ9LzQN4g@mail.gmail.com>
	<52EA39C6.8020607@redhat.com>
	<CAAg5f2S-E=dLWiqCQS7Vj0sw9+_C=2yrW2Fbiiph6iis7KP9-w@mail.gmail.com>
	<52EF9D46.6000306@redhat.com>
	<953401D5-1AA2-44BB-8240-859183299450@redhat.com>
	<CAAg5f2Q=krkMe0U2Ra51PyZTQi_qCiO1RZ0DyYYCZtUE8RDgKA@mail.gmail.com>
	<79297C6E-D46C-468B-97E3-F3F8C3396F76@redhat.com>
	<20140220210758.GW51006@rohan.local>
	<CAAg5f2TzcMBiozkvEv+3FFR=3q9i-1YWi9=pND7fCDUPY=KNPA@mail.gmail.com>
	<CAAg5f2Te=pPpj7cP0su6wyN18X9tN5x-S6wn+Nvs05Hc9cskDg@mail.gmail.com>
Message-ID: <CAM5SUC4v-PTAniT4P18WWQ3gD3=-DR4oYR5-do6NdZF_q6Ne0w@mail.gmail.com>

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 <matzew at apache.org>wrote:

> Actually, @aerogear_project makes sense (see @netty_project)
>
>
> On Thu, Feb 20, 2014 at 10:35 PM, Matthias Wessendorf <matzew at apache.org>wrote:
>
>> @__aerogear or @_aerogear ?
>>
>>
>>
>>
>> On Thu, Feb 20, 2014 at 10:07 PM, Douglas Campos <qmx at qmx.me> 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: <CAAg5f2Q3n2DQitVn4w1xyG16kkWxD7-WmM2_KK3cZHuNDhvFkw@mail.gmail.com>
References: <CAAg5f2Q3n2DQitVn4w1xyG16kkWxD7-WmM2_KK3cZHuNDhvFkw@mail.gmail.com>
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: <CAM5SUC4v-PTAniT4P18WWQ3gD3=-DR4oYR5-do6NdZF_q6Ne0w@mail.gmail.com>
References: <52EA3687.2050601@redhat.com>
	<CAAg5f2S2fQCA_LYf9kdTvUPmrgRD=PUHsFbu5-d-FrZ9LzQN4g@mail.gmail.com>
	<52EA39C6.8020607@redhat.com>
	<CAAg5f2S-E=dLWiqCQS7Vj0sw9+_C=2yrW2Fbiiph6iis7KP9-w@mail.gmail.com>
	<52EF9D46.6000306@redhat.com>
	<953401D5-1AA2-44BB-8240-859183299450@redhat.com>
	<CAAg5f2Q=krkMe0U2Ra51PyZTQi_qCiO1RZ0DyYYCZtUE8RDgKA@mail.gmail.com>
	<79297C6E-D46C-468B-97E3-F3F8C3396F76@redhat.com>
	<20140220210758.GW51006@rohan.local>
	<CAAg5f2TzcMBiozkvEv+3FFR=3q9i-1YWi9=pND7fCDUPY=KNPA@mail.gmail.com>
	<CAAg5f2Te=pPpj7cP0su6wyN18X9tN5x-S6wn+Nvs05Hc9cskDg@mail.gmail.com>
	<CAM5SUC4v-PTAniT4P18WWQ3gD3=-DR4oYR5-do6NdZF_q6Ne0w@mail.gmail.com>
Message-ID: <CAAg5f2T=4Hg0tOG_mzDHna8nhzXoTF6r+6Uumhv1pGVzuwFutw@mail.gmail.com>

On Thu, Feb 20, 2014 at 11:17 PM, Bruno Oliveira <bruno at abstractj.org>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 <matzew at apache.org>wrote:
>
>> Actually, @aerogear_project makes sense (see @netty_project)
>>
>>
>> On Thu, Feb 20, 2014 at 10:35 PM, Matthias Wessendorf <matzew at apache.org>wrote:
>>
>>> @__aerogear or @_aerogear ?
>>>
>>>
>>>
>>>
>>> On Thu, Feb 20, 2014 at 10:07 PM, Douglas Campos <qmx at qmx.me> 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: <CAAg5f2Q3n2DQitVn4w1xyG16kkWxD7-WmM2_KK3cZHuNDhvFkw@mail.gmail.com>
	<1392942475423-6377.post@n5.nabble.com>
Message-ID: <CAAg5f2R6bRHRuY2U7VHoJRZW5Spw1y_cz-1jzdVc6CSVvmH8Zw@mail.gmail.com>

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 <ted.goddard at icesoft.com> 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: <etPan.53063c8d.7545e146.1f77@animus>
References: <5306382D.5040306@redhat.com>
	<421D8587-C2F4-4484-A8A9-F0DB3395031A@redhat.com>
	<etPan.53063c8d.7545e146.1f77@animus>
Message-ID: <CAAg5f2QsFm2fZtxxEGE2WB-FnEbypEvw67YN3W=6Nk2Ptg2XGw@mail.gmail.com>

On Thu, Feb 20, 2014 at 6:34 PM, Bruno Oliveira <bruno at abstractj.org> 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: <CAAg5f2SODzgWzD56h9eF5kAgBVWS2HYVrAxCh1z7V2FSuyFp+A@mail.gmail.com>

looks really cool, Hylke!


On Thu, Feb 20, 2014 at 6:15 PM, Hylke Bons <hbons at redhat.com> 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: <CAAg5f2SODzgWzD56h9eF5kAgBVWS2HYVrAxCh1z7V2FSuyFp+A@mail.gmail.com>
References: <5306382D.5040306@redhat.com>
	<CAAg5f2SODzgWzD56h9eF5kAgBVWS2HYVrAxCh1z7V2FSuyFp+A@mail.gmail.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 <matzew at apache.org> wrote:

> looks really cool, Hylke!
> 
> 
> On Thu, Feb 20, 2014 at 6:15 PM, Hylke Bons <hbons at redhat.com> 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: <CAD_dpu1_6eVjBDa+++QvKqQ+=cjevMb=juxtEsHWnPo5g1en5Q@mail.gmail.com>
References: <CADPUygeFVLtskRVAqJ8o8o2Zu5Jtu64cyyAODdja=gCdbTJwsQ@mail.gmail.com>
	<CAD_dpu0MnENNhUA2srMAgLeSPJRw8ufTB3M6Fr0CF23CJLNwzg@mail.gmail.com>
	<CADPUyge8EPKVAnT4fh6Lccgiyvt4d-1J8hP=7kNaXmGGCKAyMg@mail.gmail.com>
	<CAAg5f2QcXHA1V7vC5VqJ8Ns=4MKgAU=Cx4CHS1u+kgqFNVenNw@mail.gmail.com>
	<CAD_dpu3HJ0jri8MGcE3rFgY5YWwpdsJ8-U6HUf42QEoq_aEo-Q@mail.gmail.com>
	<CAL8vO=cF3SBQP7ZohdERQBqoX78ZFxAS_dx2wQB+o76UsBGDHw@mail.gmail.com>
	<CADPUygcLFKeFsQz9F4Yvi1FphJw_B0deRTt3YqTXHqUts9QEZw@mail.gmail.com>
	<CAAg5f2RtBWFfFs7-Ahiovj=2nzrCU3-mjzVbY+SVL5zW_axFfw@mail.gmail.com>
	<CADPUygdtuUsnGgvZ6B8bjFrX7t=UVUFy6p7_oJzu5cU3S=pYcQ@mail.gmail.com>
	<CAAg5f2QTqNi3uB4ZwLg-HEDZVgM2oJqxZyB2=QUq_d7srJe1ng@mail.gmail.com>
	<CADPUygdtnHe455OK==c1B94EfEQkkT9k_Jz4ceU+-VRqo=Y=jQ@mail.gmail.com>
	<CAAg5f2Tp0wJ0uORQ6mRnHSQtvBAMrewcj5g4B7N3Y_-3=Jjuzw@mail.gmail.com>
	<CADPUygeiExOFXdLEJRDGP1Ug8D0sE3tndCa+t17J_dJ96pbTYA@mail.gmail.com>
	<CAAg5f2Sd5XB8dhPeRPjyNKpLQD3inPk9YjhhhHugYDuqDBZPbw@mail.gmail.com>
	<CADPUygfyVm56Tf58qJxUw=q658=xstRuJj0A8OY1+V=nEkrGMA@mail.gmail.com>
	<CADPUygeCTcMoW1HFUZbJtxzy2O-HfMxeY23VhSPevf+f=vdm9g@mail.gmail.com>
	<CAAg5f2Tw4FPMKLHqXo9WDkxsiHFsKg=p5ZK=nvPuXwx+eWK2hw@mail.gmail.com>
	<D00391E3-0041-4E20-AD72-5C669BE991F4@gmail.com>
	<CAD_dpu1_6eVjBDa+++QvKqQ+=cjevMb=juxtEsHWnPo5g1en5Q@mail.gmail.com>
Message-ID: <CADPUygeGPf7KdQpEQ3b7RVJ4vPHHN5fQfpwNiAoxeoEdcPEDiA@mail.gmail.com>

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 <scm.blanc at gmail.com>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 <miguel21op at gmail.com>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 <matzew at apache.org>
>> escreveu:
>>
>> Nice!
>>
>> Glad you are all set!
>>
>> -Matthias
>>
>>
>> On Wed, Feb 19, 2014 at 4:38 PM, Miguel Lemos <miguel21op at gmail.com>wrote:
>>
>>> A small souvenir ;-)
>>>
>>> Thanks again
>>>
>>>
>>>
>>>
>>> On Wed, Feb 19, 2014 at 3:20 PM, Miguel Lemos <miguel21op at gmail.com>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 <miguel21op at gmail.com>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
>
-------------- 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: <CADPUygeGPf7KdQpEQ3b7RVJ4vPHHN5fQfpwNiAoxeoEdcPEDiA@mail.gmail.com>
References: <CADPUygeFVLtskRVAqJ8o8o2Zu5Jtu64cyyAODdja=gCdbTJwsQ@mail.gmail.com>
	<CAD_dpu0MnENNhUA2srMAgLeSPJRw8ufTB3M6Fr0CF23CJLNwzg@mail.gmail.com>
	<CADPUyge8EPKVAnT4fh6Lccgiyvt4d-1J8hP=7kNaXmGGCKAyMg@mail.gmail.com>
	<CAAg5f2QcXHA1V7vC5VqJ8Ns=4MKgAU=Cx4CHS1u+kgqFNVenNw@mail.gmail.com>
	<CAD_dpu3HJ0jri8MGcE3rFgY5YWwpdsJ8-U6HUf42QEoq_aEo-Q@mail.gmail.com>
	<CAL8vO=cF3SBQP7ZohdERQBqoX78ZFxAS_dx2wQB+o76UsBGDHw@mail.gmail.com>
	<CADPUygcLFKeFsQz9F4Yvi1FphJw_B0deRTt3YqTXHqUts9QEZw@mail.gmail.com>
	<CAAg5f2RtBWFfFs7-Ahiovj=2nzrCU3-mjzVbY+SVL5zW_axFfw@mail.gmail.com>
	<CADPUygdtuUsnGgvZ6B8bjFrX7t=UVUFy6p7_oJzu5cU3S=pYcQ@mail.gmail.com>
	<CAAg5f2QTqNi3uB4ZwLg-HEDZVgM2oJqxZyB2=QUq_d7srJe1ng@mail.gmail.com>
	<CADPUygdtnHe455OK==c1B94EfEQkkT9k_Jz4ceU+-VRqo=Y=jQ@mail.gmail.com>
	<CAAg5f2Tp0wJ0uORQ6mRnHSQtvBAMrewcj5g4B7N3Y_-3=Jjuzw@mail.gmail.com>
	<CADPUygeiExOFXdLEJRDGP1Ug8D0sE3tndCa+t17J_dJ96pbTYA@mail.gmail.com>
	<CAAg5f2Sd5XB8dhPeRPjyNKpLQD3inPk9YjhhhHugYDuqDBZPbw@mail.gmail.com>
	<CADPUygfyVm56Tf58qJxUw=q658=xstRuJj0A8OY1+V=nEkrGMA@mail.gmail.com>
	<CADPUygeCTcMoW1HFUZbJtxzy2O-HfMxeY23VhSPevf+f=vdm9g@mail.gmail.com>
	<CAAg5f2Tw4FPMKLHqXo9WDkxsiHFsKg=p5ZK=nvPuXwx+eWK2hw@mail.gmail.com>
	<D00391E3-0041-4E20-AD72-5C669BE991F4@gmail.com>
	<CAD_dpu1_6eVjBDa+++QvKqQ+=cjevMb=juxtEsHWnPo5g1en5Q@mail.gmail.com>
	<CADPUygeGPf7KdQpEQ3b7RVJ4vPHHN5fQfpwNiAoxeoEdcPEDiA@mail.gmail.com>
Message-ID: <CAAg5f2TTtHfJVoSrWNq6oPDbFswX9aGubdxR3cG9P79JsbNaNA@mail.gmail.com>

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 <miguel21op at gmail.com> 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 <scm.blanc at gmail.com>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 <miguel21op at gmail.com>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 <matzew at apache.org>
>>> escreveu:
>>>
>>> Nice!
>>>
>>> Glad you are all set!
>>>
>>> -Matthias
>>>
>>>
>>> On Wed, Feb 19, 2014 at 4:38 PM, Miguel Lemos <miguel21op at gmail.com>wrote:
>>>
>>>> A small souvenir ;-)
>>>>
>>>> Thanks again
>>>>
>>>>
>>>>
>>>>
>>>> On Wed, Feb 19, 2014 at 3:20 PM, Miguel Lemos <miguel21op at gmail.com>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 <miguel21op at gmail.com>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
-------------- 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: <CAAg5f2TTtHfJVoSrWNq6oPDbFswX9aGubdxR3cG9P79JsbNaNA@mail.gmail.com>
References: <CADPUygeFVLtskRVAqJ8o8o2Zu5Jtu64cyyAODdja=gCdbTJwsQ@mail.gmail.com>
	<CAD_dpu0MnENNhUA2srMAgLeSPJRw8ufTB3M6Fr0CF23CJLNwzg@mail.gmail.com>
	<CADPUyge8EPKVAnT4fh6Lccgiyvt4d-1J8hP=7kNaXmGGCKAyMg@mail.gmail.com>
	<CAAg5f2QcXHA1V7vC5VqJ8Ns=4MKgAU=Cx4CHS1u+kgqFNVenNw@mail.gmail.com>
	<CAD_dpu3HJ0jri8MGcE3rFgY5YWwpdsJ8-U6HUf42QEoq_aEo-Q@mail.gmail.com>
	<CAL8vO=cF3SBQP7ZohdERQBqoX78ZFxAS_dx2wQB+o76UsBGDHw@mail.gmail.com>
	<CADPUygcLFKeFsQz9F4Yvi1FphJw_B0deRTt3YqTXHqUts9QEZw@mail.gmail.com>
	<CAAg5f2RtBWFfFs7-Ahiovj=2nzrCU3-mjzVbY+SVL5zW_axFfw@mail.gmail.com>
	<CADPUygdtuUsnGgvZ6B8bjFrX7t=UVUFy6p7_oJzu5cU3S=pYcQ@mail.gmail.com>
	<CAAg5f2QTqNi3uB4ZwLg-HEDZVgM2oJqxZyB2=QUq_d7srJe1ng@mail.gmail.com>
	<CADPUygdtnHe455OK==c1B94EfEQkkT9k_Jz4ceU+-VRqo=Y=jQ@mail.gmail.com>
	<CAAg5f2Tp0wJ0uORQ6mRnHSQtvBAMrewcj5g4B7N3Y_-3=Jjuzw@mail.gmail.com>
	<CADPUygeiExOFXdLEJRDGP1Ug8D0sE3tndCa+t17J_dJ96pbTYA@mail.gmail.com>
	<CAAg5f2Sd5XB8dhPeRPjyNKpLQD3inPk9YjhhhHugYDuqDBZPbw@mail.gmail.com>
	<CADPUygfyVm56Tf58qJxUw=q658=xstRuJj0A8OY1+V=nEkrGMA@mail.gmail.com>
	<CADPUygeCTcMoW1HFUZbJtxzy2O-HfMxeY23VhSPevf+f=vdm9g@mail.gmail.com>
	<CAAg5f2Tw4FPMKLHqXo9WDkxsiHFsKg=p5ZK=nvPuXwx+eWK2hw@mail.gmail.com>
	<D00391E3-0041-4E20-AD72-5C669BE991F4@gmail.com>
	<CAD_dpu1_6eVjBDa+++QvKqQ+=cjevMb=juxtEsHWnPo5g1en5Q@mail.gmail.com>
	<CADPUygeGPf7KdQpEQ3b7RVJ4vPHHN5fQfpwNiAoxeoEdcPEDiA@mail.gmail.com>
	<CAAg5f2TTtHfJVoSrWNq6oPDbFswX9aGubdxR3cG9P79JsbNaNA@mail.gmail.com>
Message-ID: <CAD_dpu0kXCNu-baWH=WcY-hPVJMqNQTQtSC+DXY3wmQqGSpj4Q@mail.gmail.com>

On Fri, Feb 21, 2014 at 10:01 AM, Matthias Wessendorf <matzew at apache.org>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 <miguel21op at gmail.com>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 <scm.blanc at gmail.com>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 <miguel21op at gmail.com>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 <matzew at apache.org>
>>>> escreveu:
>>>>
>>>> Nice!
>>>>
>>>> Glad you are all set!
>>>>
>>>> -Matthias
>>>>
>>>>
>>>> On Wed, Feb 19, 2014 at 4:38 PM, Miguel Lemos <miguel21op at gmail.com>wrote:
>>>>
>>>>> A small souvenir ;-)
>>>>>
>>>>> Thanks again
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Wed, Feb 19, 2014 at 3:20 PM, Miguel Lemos <miguel21op at gmail.com>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 <miguel21op at gmail.com>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: <CAAg5f2TTtHfJVoSrWNq6oPDbFswX9aGubdxR3cG9P79JsbNaNA@mail.gmail.com>
References: <CADPUygeFVLtskRVAqJ8o8o2Zu5Jtu64cyyAODdja=gCdbTJwsQ@mail.gmail.com>
	<CAD_dpu0MnENNhUA2srMAgLeSPJRw8ufTB3M6Fr0CF23CJLNwzg@mail.gmail.com>
	<CADPUyge8EPKVAnT4fh6Lccgiyvt4d-1J8hP=7kNaXmGGCKAyMg@mail.gmail.com>
	<CAAg5f2QcXHA1V7vC5VqJ8Ns=4MKgAU=Cx4CHS1u+kgqFNVenNw@mail.gmail.com>
	<CAD_dpu3HJ0jri8MGcE3rFgY5YWwpdsJ8-U6HUf42QEoq_aEo-Q@mail.gmail.com>
	<CAL8vO=cF3SBQP7ZohdERQBqoX78ZFxAS_dx2wQB+o76UsBGDHw@mail.gmail.com>
	<CADPUygcLFKeFsQz9F4Yvi1FphJw_B0deRTt3YqTXHqUts9QEZw@mail.gmail.com>
	<CAAg5f2RtBWFfFs7-Ahiovj=2nzrCU3-mjzVbY+SVL5zW_axFfw@mail.gmail.com>
	<CADPUygdtuUsnGgvZ6B8bjFrX7t=UVUFy6p7_oJzu5cU3S=pYcQ@mail.gmail.com>
	<CAAg5f2QTqNi3uB4ZwLg-HEDZVgM2oJqxZyB2=QUq_d7srJe1ng@mail.gmail.com>
	<CADPUygdtnHe455OK==c1B94EfEQkkT9k_Jz4ceU+-VRqo=Y=jQ@mail.gmail.com>
	<CAAg5f2Tp0wJ0uORQ6mRnHSQtvBAMrewcj5g4B7N3Y_-3=Jjuzw@mail.gmail.com>
	<CADPUygeiExOFXdLEJRDGP1Ug8D0sE3tndCa+t17J_dJ96pbTYA@mail.gmail.com>
	<CAAg5f2Sd5XB8dhPeRPjyNKpLQD3inPk9YjhhhHugYDuqDBZPbw@mail.gmail.com>
	<CADPUygfyVm56Tf58qJxUw=q658=xstRuJj0A8OY1+V=nEkrGMA@mail.gmail.com>
	<CADPUygeCTcMoW1HFUZbJtxzy2O-HfMxeY23VhSPevf+f=vdm9g@mail.gmail.com>
	<CAAg5f2Tw4FPMKLHqXo9WDkxsiHFsKg=p5ZK=nvPuXwx+eWK2hw@mail.gmail.com>
	<D00391E3-0041-4E20-AD72-5C669BE991F4@gmail.com>
	<CAD_dpu1_6eVjBDa+++QvKqQ+=cjevMb=juxtEsHWnPo5g1en5Q@mail.gmail.com>
	<CADPUygeGPf7KdQpEQ3b7RVJ4vPHHN5fQfpwNiAoxeoEdcPEDiA@mail.gmail.com>
	<CAAg5f2TTtHfJVoSrWNq6oPDbFswX9aGubdxR3cG9P79JsbNaNA@mail.gmail.com>
Message-ID: <CADPUygdHmfiKrTwFvdN2p+CP6GffOX0jCRsp45+B6s8oaY2dXg@mail.gmail.com>

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 <matzew at apache.org>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 <miguel21op at gmail.com>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 <scm.blanc at gmail.com>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 <miguel21op at gmail.com>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 <matzew at apache.org>
>>>> escreveu:
>>>>
>>>> Nice!
>>>>
>>>> Glad you are all set!
>>>>
>>>> -Matthias
>>>>
>>>>
>>>> On Wed, Feb 19, 2014 at 4:38 PM, Miguel Lemos <miguel21op at gmail.com>wrote:
>>>>
>>>>> A small souvenir ;-)
>>>>>
>>>>> Thanks again
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Wed, Feb 19, 2014 at 3:20 PM, Miguel Lemos <miguel21op at gmail.com>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 <miguel21op at gmail.com>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: <CADPUygdHmfiKrTwFvdN2p+CP6GffOX0jCRsp45+B6s8oaY2dXg@mail.gmail.com>
References: <CADPUygeFVLtskRVAqJ8o8o2Zu5Jtu64cyyAODdja=gCdbTJwsQ@mail.gmail.com>
	<CAD_dpu0MnENNhUA2srMAgLeSPJRw8ufTB3M6Fr0CF23CJLNwzg@mail.gmail.com>
	<CADPUyge8EPKVAnT4fh6Lccgiyvt4d-1J8hP=7kNaXmGGCKAyMg@mail.gmail.com>
	<CAAg5f2QcXHA1V7vC5VqJ8Ns=4MKgAU=Cx4CHS1u+kgqFNVenNw@mail.gmail.com>
	<CAD_dpu3HJ0jri8MGcE3rFgY5YWwpdsJ8-U6HUf42QEoq_aEo-Q@mail.gmail.com>
	<CAL8vO=cF3SBQP7ZohdERQBqoX78ZFxAS_dx2wQB+o76UsBGDHw@mail.gmail.com>
	<CADPUygcLFKeFsQz9F4Yvi1FphJw_B0deRTt3YqTXHqUts9QEZw@mail.gmail.com>
	<CAAg5f2RtBWFfFs7-Ahiovj=2nzrCU3-mjzVbY+SVL5zW_axFfw@mail.gmail.com>
	<CADPUygdtuUsnGgvZ6B8bjFrX7t=UVUFy6p7_oJzu5cU3S=pYcQ@mail.gmail.com>
	<CAAg5f2QTqNi3uB4ZwLg-HEDZVgM2oJqxZyB2=QUq_d7srJe1ng@mail.gmail.com>
	<CADPUygdtnHe455OK==c1B94EfEQkkT9k_Jz4ceU+-VRqo=Y=jQ@mail.gmail.com>
	<CAAg5f2Tp0wJ0uORQ6mRnHSQtvBAMrewcj5g4B7N3Y_-3=Jjuzw@mail.gmail.com>
	<CADPUygeiExOFXdLEJRDGP1Ug8D0sE3tndCa+t17J_dJ96pbTYA@mail.gmail.com>
	<CAAg5f2Sd5XB8dhPeRPjyNKpLQD3inPk9YjhhhHugYDuqDBZPbw@mail.gmail.com>
	<CADPUygfyVm56Tf58qJxUw=q658=xstRuJj0A8OY1+V=nEkrGMA@mail.gmail.com>
	<CADPUygeCTcMoW1HFUZbJtxzy2O-HfMxeY23VhSPevf+f=vdm9g@mail.gmail.com>
	<CAAg5f2Tw4FPMKLHqXo9WDkxsiHFsKg=p5ZK=nvPuXwx+eWK2hw@mail.gmail.com>
	<D00391E3-0041-4E20-AD72-5C669BE991F4@gmail.com>
	<CAD_dpu1_6eVjBDa+++QvKqQ+=cjevMb=juxtEsHWnPo5g1en5Q@mail.gmail.com>
	<CADPUygeGPf7KdQpEQ3b7RVJ4vPHHN5fQfpwNiAoxeoEdcPEDiA@mail.gmail.com>
	<CAAg5f2TTtHfJVoSrWNq6oPDbFswX9aGubdxR3cG9P79JsbNaNA@mail.gmail.com>
	<CADPUygdHmfiKrTwFvdN2p+CP6GffOX0jCRsp45+B6s8oaY2dXg@mail.gmail.com>
Message-ID: <CAAg5f2QRKPiGiAE3xuHxzPh2ka5tY_qNiTQDXe1RwP86VbSkTw@mail.gmail.com>

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 <miguel21op at gmail.com> 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 <matzew at apache.org>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 <miguel21op at gmail.com>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 <scm.blanc at gmail.com>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 <miguel21op at gmail.com>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 <matzew at apache.org>
>>>>> escreveu:
>>>>>
>>>>> Nice!
>>>>>
>>>>> Glad you are all set!
>>>>>
>>>>> -Matthias
>>>>>
>>>>>
>>>>> On Wed, Feb 19, 2014 at 4:38 PM, Miguel Lemos <miguel21op at gmail.com>wrote:
>>>>>
>>>>>> A small souvenir ;-)
>>>>>>
>>>>>> Thanks again
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Feb 19, 2014 at 3:20 PM, Miguel Lemos <miguel21op at gmail.com>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 <miguel21op at gmail.com
>>>>>>>> > 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: <CAAg5f2QRKPiGiAE3xuHxzPh2ka5tY_qNiTQDXe1RwP86VbSkTw@mail.gmail.com>
References: <CADPUygeFVLtskRVAqJ8o8o2Zu5Jtu64cyyAODdja=gCdbTJwsQ@mail.gmail.com>
	<CAD_dpu0MnENNhUA2srMAgLeSPJRw8ufTB3M6Fr0CF23CJLNwzg@mail.gmail.com>
	<CADPUyge8EPKVAnT4fh6Lccgiyvt4d-1J8hP=7kNaXmGGCKAyMg@mail.gmail.com>
	<CAAg5f2QcXHA1V7vC5VqJ8Ns=4MKgAU=Cx4CHS1u+kgqFNVenNw@mail.gmail.com>
	<CAD_dpu3HJ0jri8MGcE3rFgY5YWwpdsJ8-U6HUf42QEoq_aEo-Q@mail.gmail.com>
	<CAL8vO=cF3SBQP7ZohdERQBqoX78ZFxAS_dx2wQB+o76UsBGDHw@mail.gmail.com>
	<CADPUygcLFKeFsQz9F4Yvi1FphJw_B0deRTt3YqTXHqUts9QEZw@mail.gmail.com>
	<CAAg5f2RtBWFfFs7-Ahiovj=2nzrCU3-mjzVbY+SVL5zW_axFfw@mail.gmail.com>
	<CADPUygdtuUsnGgvZ6B8bjFrX7t=UVUFy6p7_oJzu5cU3S=pYcQ@mail.gmail.com>
	<CAAg5f2QTqNi3uB4ZwLg-HEDZVgM2oJqxZyB2=QUq_d7srJe1ng@mail.gmail.com>
	<CADPUygdtnHe455OK==c1B94EfEQkkT9k_Jz4ceU+-VRqo=Y=jQ@mail.gmail.com>
	<CAAg5f2Tp0wJ0uORQ6mRnHSQtvBAMrewcj5g4B7N3Y_-3=Jjuzw@mail.gmail.com>
	<CADPUygeiExOFXdLEJRDGP1Ug8D0sE3tndCa+t17J_dJ96pbTYA@mail.gmail.com>
	<CAAg5f2Sd5XB8dhPeRPjyNKpLQD3inPk9YjhhhHugYDuqDBZPbw@mail.gmail.com>
	<CADPUygfyVm56Tf58qJxUw=q658=xstRuJj0A8OY1+V=nEkrGMA@mail.gmail.com>
	<CADPUygeCTcMoW1HFUZbJtxzy2O-HfMxeY23VhSPevf+f=vdm9g@mail.gmail.com>
	<CAAg5f2Tw4FPMKLHqXo9WDkxsiHFsKg=p5ZK=nvPuXwx+eWK2hw@mail.gmail.com>
	<D00391E3-0041-4E20-AD72-5C669BE991F4@gmail.com>
	<CAD_dpu1_6eVjBDa+++QvKqQ+=cjevMb=juxtEsHWnPo5g1en5Q@mail.gmail.com>
	<CADPUygeGPf7KdQpEQ3b7RVJ4vPHHN5fQfpwNiAoxeoEdcPEDiA@mail.gmail.com>
	<CAAg5f2TTtHfJVoSrWNq6oPDbFswX9aGubdxR3cG9P79JsbNaNA@mail.gmail.com>
	<CADPUygdHmfiKrTwFvdN2p+CP6GffOX0jCRsp45+B6s8oaY2dXg@mail.gmail.com>
	<CAAg5f2QRKPiGiAE3xuHxzPh2ka5tY_qNiTQDXe1RwP86VbSkTw@mail.gmail.com>
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 <matzew at apache.org> 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 <miguel21op at gmail.com> 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 <matzew at apache.org> 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 <miguel21op at gmail.com> 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 <scm.blanc at gmail.com> 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 <miguel21op at gmail.com> 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 <matzew at apache.org> escreveu:
>>>>>> 
>>>>>>> Nice!
>>>>>>> 
>>>>>>> Glad you are all set!
>>>>>>> 
>>>>>>> -Matthias
>>>>>>> 
>>>>>>> 
>>>>>>>> On Wed, Feb 19, 2014 at 4:38 PM, Miguel Lemos <miguel21op at gmail.com> wrote:
>>>>>>>> A small souvenir ;-)
>>>>>>>> 
>>>>>>>> Thanks again
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> On Wed, Feb 19, 2014 at 3:20 PM, Miguel Lemos <miguel21op at gmail.com> 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 <miguel21op at gmail.com> 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
> _______________________________________________
> 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: <CAAg5f2QRKPiGiAE3xuHxzPh2ka5tY_qNiTQDXe1RwP86VbSkTw@mail.gmail.com>
References: <CADPUygeFVLtskRVAqJ8o8o2Zu5Jtu64cyyAODdja=gCdbTJwsQ@mail.gmail.com>
	<CAD_dpu0MnENNhUA2srMAgLeSPJRw8ufTB3M6Fr0CF23CJLNwzg@mail.gmail.com>
	<CADPUyge8EPKVAnT4fh6Lccgiyvt4d-1J8hP=7kNaXmGGCKAyMg@mail.gmail.com>
	<CAAg5f2QcXHA1V7vC5VqJ8Ns=4MKgAU=Cx4CHS1u+kgqFNVenNw@mail.gmail.com>
	<CAD_dpu3HJ0jri8MGcE3rFgY5YWwpdsJ8-U6HUf42QEoq_aEo-Q@mail.gmail.com>
	<CAL8vO=cF3SBQP7ZohdERQBqoX78ZFxAS_dx2wQB+o76UsBGDHw@mail.gmail.com>
	<CADPUygcLFKeFsQz9F4Yvi1FphJw_B0deRTt3YqTXHqUts9QEZw@mail.gmail.com>
	<CAAg5f2RtBWFfFs7-Ahiovj=2nzrCU3-mjzVbY+SVL5zW_axFfw@mail.gmail.com>
	<CADPUygdtuUsnGgvZ6B8bjFrX7t=UVUFy6p7_oJzu5cU3S=pYcQ@mail.gmail.com>
	<CAAg5f2QTqNi3uB4ZwLg-HEDZVgM2oJqxZyB2=QUq_d7srJe1ng@mail.gmail.com>
	<CADPUygdtnHe455OK==c1B94EfEQkkT9k_Jz4ceU+-VRqo=Y=jQ@mail.gmail.com>
	<CAAg5f2Tp0wJ0uORQ6mRnHSQtvBAMrewcj5g4B7N3Y_-3=Jjuzw@mail.gmail.com>
	<CADPUygeiExOFXdLEJRDGP1Ug8D0sE3tndCa+t17J_dJ96pbTYA@mail.gmail.com>
	<CAAg5f2Sd5XB8dhPeRPjyNKpLQD3inPk9YjhhhHugYDuqDBZPbw@mail.gmail.com>
	<CADPUygfyVm56Tf58qJxUw=q658=xstRuJj0A8OY1+V=nEkrGMA@mail.gmail.com>
	<CADPUygeCTcMoW1HFUZbJtxzy2O-HfMxeY23VhSPevf+f=vdm9g@mail.gmail.com>
	<CAAg5f2Tw4FPMKLHqXo9WDkxsiHFsKg=p5ZK=nvPuXwx+eWK2hw@mail.gmail.com>
	<D00391E3-0041-4E20-AD72-5C669BE991F4@gmail.com>
	<CAD_dpu1_6eVjBDa+++QvKqQ+=cjevMb=juxtEsHWnPo5g1en5Q@mail.gmail.com>
	<CADPUygeGPf7KdQpEQ3b7RVJ4vPHHN5fQfpwNiAoxeoEdcPEDiA@mail.gmail.com>
	<CAAg5f2TTtHfJVoSrWNq6oPDbFswX9aGubdxR3cG9P79JsbNaNA@mail.gmail.com>
	<CADPUygdHmfiKrTwFvdN2p+CP6GffOX0jCRsp45+B6s8oaY2dXg@mail.gmail.com>
	<CAAg5f2QRKPiGiAE3xuHxzPh2ka5tY_qNiTQDXe1RwP86VbSkTw@mail.gmail.com>
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 <matzew at apache.org> 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 <miguel21op at gmail.com> 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 <matzew at apache.org> 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
>>>