From cvasilak at gmail.com  Mon May  4 02:47:43 2015
From: cvasilak at gmail.com (Christos Vasilakis)
Date: Mon, 4 May 2015 09:47:43 +0300
Subject: [aerogear-dev] Team Meeting
Message-ID: <CAKVvow_=mvEfjf+Liirb4tZYsEOf3XgATespTo4+t3aENb+dYQ@mail.gmail.com>

agenda:

http://oksoclap.com/p/aerogear-team-mgt-05.04.2015
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20150504/dd49daba/attachment.html 

From corinnekrych at gmail.com  Mon May  4 04:21:50 2015
From: corinnekrych at gmail.com (Corinne Krych)
Date: Mon, 4 May 2015 10:21:50 +0200
Subject: [aerogear-dev] Advanced Analtyics,
 new PR and call to the client tech leads
In-Reply-To: <CAD_dpu2LPTTYefjbpqt4TF2jUwhxmNzg2zpqcTDh7tPcjKtGQA@mail.gmail.com>
References: <CAD_dpu2LPTTYefjbpqt4TF2jUwhxmNzg2zpqcTDh7tPcjKtGQA@mail.gmail.com>
Message-ID: <CAL8vO=f49cuKORAahQhE45DEANBLTcn4x_+yMjBxbfMfpSkTTg@mail.gmail.com>

Yeap
on it.

On 30 April 2015 at 15:43, Sebastien Blanc <scm.blanc at gmail.com> wrote:

> Hi,
>
> The Advanced Analytics task[1] has a new PR[2] that has been rebased on
> the latest master and got a lot of polishing.
>
> Could the Client Tech Leads take a look at it [3] and review ? The only
> "breaking" change is the rename of the header's name that identifies a Push
> Notification, it's called now "aerogear-push-id"
>
> Seb
>
>
>
> [1] https://issues.jboss.org/browse/AGPUSH-971
> [2] https://github.com/aerogear/aerogear-unifiedpush-server/pull/540
> [3] Subtasks of https://issues.jboss.org/browse/AGPUSH-971
>
>
>
> _______________________________________________
> 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/20150504/cacf9006/attachment.html 

From corinnekrych at gmail.com  Mon May  4 04:24:21 2015
From: corinnekrych at gmail.com (Corinne Krych)
Date: Mon, 4 May 2015 10:24:21 +0200
Subject: [aerogear-dev] OAuth2 with native Broswer in Android
In-Reply-To: <CAKVvow89YcTDxSTFwVtZ=4z8b47y7_J7Q=p3EYdDpdgkxp7B6w@mail.gmail.com>
References: <CAEQz2CvfzppPnnohN=SP0pcopYtvzaY_qf6JhhSy8Qx-zOJOKw@mail.gmail.com>
	<CAKVvow89YcTDxSTFwVtZ=4z8b47y7_J7Q=p3EYdDpdgkxp7B6w@mail.gmail.com>
Message-ID: <CAL8vO=dvi=avic=TbezqeHnYTL_2Tm7rR2wRxty7ZBv9yoRqKA@mail.gmail.com>

+1

On 30 April 2015 at 19:25, Christos Vasilakis <cvasilak at gmail.com> wrote:

>
>
> On Thu, Apr 30, 2015 at 6:04 PM, Summers Pittman <supittma at redhat.com>
> wrote:
>
>> In Android I have a solution for using the native browser to perform an
>> OAuth2 sign in.  There are some limititions however.
>>
>> In general to use this you need an activity which has an intent filter to
>> consume the redirect URL.  This works best if you use a custom URI scheme.
>> Google, Yahoo, and Facebook (as well as other I'm sure) only allow
>> redirects to http or https.  This means that unless you are using a third
>> party to redirect a custom schema the browser my preempt your application
>> and consume the redirect.  Other services such as KeyCloak and Spotify
>> allow custom schemas and these work perfectly with my solution.
>>
>> If we document the limitations of the Intent and when using an Intent vs
>> using a WebView is appropriate, is a solution with these limitations
>> adequate? I think it is.
>>
>
> +1
>
> since generic OAuth2 provider is the goal, the intricacies of some should
> not interfere with the ?correct? spec flow.
>
> btw
> interesting enough, in the iOS side of things the Bundle_ID can be used as
> the prefix in the redirect_uri registration and works correctly. Now why
> the Android 'Package name? can?t be used similarly here is a mystery. Oh
> well..
>
> -
> Christos
>
>
>> Thoughts?
>>
>> Summers
>>
>> PS: a link to my poc :
>> https://github.com/secondsun/aerogear-android-authz/tree/AGDROID-319/
>> PPS:  You can use this on the KeyCloakHelper in Shoot and Share by adding
>> `setWithIntent(true)` to the configuration in that class.
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.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/20150504/db404c62/attachment.html 

From matzew at apache.org  Mon May  4 05:34:16 2015
From: matzew at apache.org (Matthias Wessendorf)
Date: Mon, 4 May 2015 11:34:16 +0200
Subject: [aerogear-dev] Release is out (was: Re: UnifiedPush Server
	1.1.0-alpha.2)
Message-ID: <CAAg5f2QYma4fMiZ0XLro3mxKNy-6w4v+aLMFQFDuzCHM567MuA@mail.gmail.com>

Hi,

thanks for testing - alpha.2 is out:
https://github.com/aerogear/aerogear-unifiedpush-server/releases/tag/1.1.0-alpha.2

That said we are already in the middle of beta.1 release :-)

Greetings,
Matthias

On Tue, Apr 28, 2015 at 9:45 AM, Luk?? Fry? <lukas.fryc at gmail.com> wrote:

> I have tested with EAP 6.4 and MySQL, and successfully sent message to
> Android emulator.
>
> During that testing I've found one issue, that should not IMO block the
> release:
> https://issues.jboss.org/browse/AGPUSH-1375
>
>
> I'm +1
>
> po 27. 4. 2015 v 17:22 odes?latel Christos Vasilakis <cvasilak at gmail.com>
> napsal:
>
> registered Android/iOS variants and successfully sent/receive
>> notifications with the activity log being updated accordingly.
>>
>> great work!
>>
>> +1
>>
>>
>> ?
>>
>> On Mon, Apr 27, 2015 at 4:19 PM, Luk?? Fry? <lukas.fryc at gmail.com> wrote:
>>
>>> ad) Testing new UI:
>>>
>>> When testing, please bear in mind, that there are still lot of UI
>>> leftovers (such as wrong links). Some of them we already know of.
>>>
>>> The main functionality/paths should be available though:
>>>
>>> - creating apps
>>> - creating variants
>>> - sending push messages
>>> - reading activity log
>>>
>>> Andres and myself already put together a list items that needs to be
>>> fixed for Beta, but none of them are anyhow critical to have in Alpha
>>> release.
>>>
>>>
>>> Thanks,
>>>
>>> ~ Lukas
>>>
>>> On Mon, Apr 27, 2015 at 9:45 AM, Matthias Wessendorf <matzew at apache.org>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> after month of work, here is the second alpha release for the UPS
>>>> 1.1.0. It contains an all new UI, JMS for enhanced scalability and a lot of
>>>> other improvements:
>>>> https://issues.jboss.org/browse/AGPUSH/fixforversion/12326455
>>>>
>>>>
>>>> Please test the staged release:
>>>>
>>>> https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-5398/
>>>>
>>>> Since we now have JMS hooks, please make sure you use a full profile
>>>> WildFly or EAP server for tests
>>>>
>>>> By Wednesday I'd like to press the button to release it to the wild.
>>>>
>>>> PS: Since this is an alhpa release we won't yet be updating our
>>>> Openshift cartridge - that will stay on 1.0.3 (stable) for a little longer
>>>> time. For the next release (beta.1) in a few weeks we may get to this
>>>> Openshift update
>>>>
>>>> Thanks,
>>>> 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
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.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/20150504/b143ec90/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: UPS-alpha.2.png
Type: image/png
Size: 167968 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/aerogear-dev/attachments/20150504/b143ec90/attachment-0001.png 

From lukas.fryc at gmail.com  Mon May  4 05:42:01 2015
From: lukas.fryc at gmail.com (=?UTF-8?B?THVrw6HFoSBGcnnEjQ==?=)
Date: Mon, 04 May 2015 09:42:01 +0000
Subject: [aerogear-dev] Sync examples : Ionic/Angular and canvas
In-Reply-To: <CAAk_PPXtWDhvNKE68P2oX__jmA4wUMv2xA=A4-3zSkw4ihp+rg@mail.gmail.com>
References: <CAAk_PPXtWDhvNKE68P2oX__jmA4wUMv2xA=A4-3zSkw4ihp+rg@mail.gmail.com>
Message-ID: <CAEroY35wVqc6vtOdnaE9wK2SrbeNa-waJtjaEXtNds_uhLZ7vw@mail.gmail.com>

Thanks Ali!

I really like recipes that include screencasts, perfect showcase!

Onwards!

~ Lukas

p? 1. 5. 2015 v 0:35 odes?latel Ali Ok <aliok at apache.org> napsal:

> Hi all,
>
> I prepared 2 Sync examples for AeroGear JS cookbook:
> * Ionic/Angular :
> https://github.com/aerogear/aerogear-js-cookbook/tree/master/diff-sync-ionic
> --> Demonstrating Sync's real-time updates with an Ionic application.
> Compatible with Sync example applications of other platforms.
> * Canvas :
> https://github.com/aerogear/aerogear-js-cookbook/tree/master/diff-sync-canvas
> --> Demonstrating a very very simple collaborative drawing application
>
> For the lazy: see the screencasts in both pages :)
>
> Thanks Luk?? Fry? for the code review and Lucas Holmquist for the PR merge.
>
> Cheers,
> Ali
>
> --
> My Blog: http://blog.aliok.com.tr
> Twitter: http://twitter.com/aliok_tr
>  _______________________________________________
> 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/20150504/ad9c9c11/attachment.html 

From matzew at apache.org  Mon May  4 06:08:15 2015
From: matzew at apache.org (Matthias Wessendorf)
Date: Mon, 4 May 2015 12:08:15 +0200
Subject: [aerogear-dev] UPS: Java Sender for alpha.2
Message-ID: <CAAg5f2Tm8mg36R5nT71yAxQDy=2H3kO9Ecqf69qTHv1L4vLC9g@mail.gmail.com>

Hi,

w/ the release of the server, I think we should release the sender as well:
https://github.com/aerogear/aerogear-unifiedpush-java-client/blob/master/pom.xml#L23

Just wondering, is it up-to-date regarding push payload?

-- 
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/20150504/4028a25f/attachment.html 

From scm.blanc at gmail.com  Mon May  4 06:31:04 2015
From: scm.blanc at gmail.com (=?utf-8?Q?S=C3=A9bastien_Blanc?=)
Date: Mon, 4 May 2015 12:31:04 +0200
Subject: [aerogear-dev] UPS: Java Sender for alpha.2
In-Reply-To: <CAAg5f2Tm8mg36R5nT71yAxQDy=2H3kO9Ecqf69qTHv1L4vLC9g@mail.gmail.com>
References: <CAAg5f2Tm8mg36R5nT71yAxQDy=2H3kO9Ecqf69qTHv1L4vLC9g@mail.gmail.com>
Message-ID: <1D09DF31-D2B4-4C36-A273-54AEE1E4B2F1@gmail.com>

Yes master is up to date with the latest push payload, should be good to release.

Envoy? de mon iPhone

> Le 4 mai 2015 ? 12:08, Matthias Wessendorf <matzew at apache.org> a ?crit :
> 
> Hi,
> 
> w/ the release of the server, I think we should release the sender as well:
> https://github.com/aerogear/aerogear-unifiedpush-java-client/blob/master/pom.xml#L23
> 
> Just wondering, is it up-to-date regarding push payload?
> 
> -- 
> Matthias Wessendorf 
> 
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/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/20150504/c362eab3/attachment.html 

From matzew at apache.org  Mon May  4 06:39:22 2015
From: matzew at apache.org (Matthias Wessendorf)
Date: Mon, 4 May 2015 12:39:22 +0200
Subject: [aerogear-dev] UPS: Java Sender for alpha.2
In-Reply-To: <1D09DF31-D2B4-4C36-A273-54AEE1E4B2F1@gmail.com>
References: <CAAg5f2Tm8mg36R5nT71yAxQDy=2H3kO9Ecqf69qTHv1L4vLC9g@mail.gmail.com>
	<1D09DF31-D2B4-4C36-A273-54AEE1E4B2F1@gmail.com>
Message-ID: <CAAg5f2TZZk_P-V2nRhRhkVY0yEeyUd+SmMGKwT0iH6pdfR0NPw@mail.gmail.com>

thanks for the heads up - I will give it a spin

On Mon, May 4, 2015 at 12:31 PM, S?bastien Blanc <scm.blanc at gmail.com>
wrote:

> Yes master is up to date with the latest push payload, should be good to
> release.
>
> Envoy? de mon iPhone
>
> Le 4 mai 2015 ? 12:08, Matthias Wessendorf <matzew at apache.org> a ?crit :
>
> Hi,
>
> w/ the release of the server, I think we should release the sender as well:
>
> https://github.com/aerogear/aerogear-unifiedpush-java-client/blob/master/pom.xml#L23
>
> Just wondering, is it up-to-date regarding push payload?
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.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/20150504/2f9d8294/attachment.html 

From lukas.fryc at gmail.com  Mon May  4 06:42:10 2015
From: lukas.fryc at gmail.com (=?UTF-8?B?THVrw6HFoSBGcnnEjQ==?=)
Date: Mon, 04 May 2015 10:42:10 +0000
Subject: [aerogear-dev] UPS: Java Sender for alpha.2
In-Reply-To: <CAAg5f2TZZk_P-V2nRhRhkVY0yEeyUd+SmMGKwT0iH6pdfR0NPw@mail.gmail.com>
References: <CAAg5f2Tm8mg36R5nT71yAxQDy=2H3kO9Ecqf69qTHv1L4vLC9g@mail.gmail.com>
	<1D09DF31-D2B4-4C36-A273-54AEE1E4B2F1@gmail.com>
	<CAAg5f2TZZk_P-V2nRhRhkVY0yEeyUd+SmMGKwT0iH6pdfR0NPw@mail.gmail.com>
Message-ID: <CAEroY35LnKbQ7Dr_OyXPR93gYS=sgWP6k+x1AYkoESRkOSjF=Q@mail.gmail.com>

If we release Sender Java Client alpha2, we should also fix
https://issues.jboss.org/browse/AGPUSH-1377

po 4. 5. 2015 v 12:39 odes?latel Matthias Wessendorf <matzew at apache.org>
napsal:

> thanks for the heads up - I will give it a spin
>
> On Mon, May 4, 2015 at 12:31 PM, S?bastien Blanc <scm.blanc at gmail.com>
> wrote:
>
>> Yes master is up to date with the latest push payload, should be good to
>> release.
>>
>> Envoy? de mon iPhone
>>
>> Le 4 mai 2015 ? 12:08, Matthias Wessendorf <matzew at apache.org> a ?crit :
>>
>> Hi,
>>
>> w/ the release of the server, I think we should release the sender as
>> well:
>>
>> https://github.com/aerogear/aerogear-unifiedpush-java-client/blob/master/pom.xml#L23
>>
>> Just wondering, is it up-to-date regarding push payload?
>>
>> --
>> Matthias Wessendorf
>>
>> blog: http://matthiaswessendorf.wordpress.com/
>> sessions: http://www.slideshare.net/mwessendorf
>> twitter: http://twitter.com/mwessendorf
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/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/20150504/cdc39fef/attachment.html 

From matzew at apache.org  Mon May  4 06:49:23 2015
From: matzew at apache.org (Matthias Wessendorf)
Date: Mon, 4 May 2015 12:49:23 +0200
Subject: [aerogear-dev] UPS: Java Sender for alpha.2
In-Reply-To: <CAEroY35LnKbQ7Dr_OyXPR93gYS=sgWP6k+x1AYkoESRkOSjF=Q@mail.gmail.com>
References: <CAAg5f2Tm8mg36R5nT71yAxQDy=2H3kO9Ecqf69qTHv1L4vLC9g@mail.gmail.com>
	<1D09DF31-D2B4-4C36-A273-54AEE1E4B2F1@gmail.com>
	<CAAg5f2TZZk_P-V2nRhRhkVY0yEeyUd+SmMGKwT0iH6pdfR0NPw@mail.gmail.com>
	<CAEroY35LnKbQ7Dr_OyXPR93gYS=sgWP6k+x1AYkoESRkOSjF=Q@mail.gmail.com>
Message-ID: <CAAg5f2TsOPT6AKmyBaHG3-eL1HWgfszwoSerKr2PaFtVD601wA@mail.gmail.com>

+1
let me do it

On Mon, May 4, 2015 at 12:42 PM, Luk?? Fry? <lukas.fryc at gmail.com> wrote:

> If we release Sender Java Client alpha2, we should also fix
> https://issues.jboss.org/browse/AGPUSH-1377
>
> po 4. 5. 2015 v 12:39 odes?latel Matthias Wessendorf <matzew at apache.org>
> napsal:
>
> thanks for the heads up - I will give it a spin
>>
>> On Mon, May 4, 2015 at 12:31 PM, S?bastien Blanc <scm.blanc at gmail.com>
>> wrote:
>>
>>> Yes master is up to date with the latest push payload, should be good to
>>> release.
>>>
>>> Envoy? de mon iPhone
>>>
>>> Le 4 mai 2015 ? 12:08, Matthias Wessendorf <matzew at apache.org> a ?crit :
>>>
>>> Hi,
>>>
>>> w/ the release of the server, I think we should release the sender as
>>> well:
>>>
>>> https://github.com/aerogear/aerogear-unifiedpush-java-client/blob/master/pom.xml#L23
>>>
>>> Just wondering, is it up-to-date regarding push payload?
>>>
>>> --
>>> Matthias Wessendorf
>>>
>>> blog: http://matthiaswessendorf.wordpress.com/
>>> sessions: http://www.slideshare.net/mwessendorf
>>> twitter: http://twitter.com/mwessendorf
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>
>>
>>
>> --
>> Matthias Wessendorf
>>
>> blog: http://matthiaswessendorf.wordpress.com/
>> sessions: http://www.slideshare.net/mwessendorf
>> twitter: http://twitter.com/mwessendorf
>>  _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.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/20150504/9c14ff64/attachment-0001.html 

From bruno at abstractj.org  Mon May  4 08:19:16 2015
From: bruno at abstractj.org (Bruno Oliveira)
Date: Mon, 4 May 2015 09:19:16 -0300
Subject: [aerogear-dev] OAuth2 with native Broswer in Android
In-Reply-To: <CAEQz2CvfzppPnnohN=SP0pcopYtvzaY_qf6JhhSy8Qx-zOJOKw@mail.gmail.com>
References: <CAEQz2CvfzppPnnohN=SP0pcopYtvzaY_qf6JhhSy8Qx-zOJOKw@mail.gmail.com>
Message-ID: <20150504121916.GA50253@abstractj.org>

On 2015-04-30, Summers Pittman wrote:
> In Android I have a solution for using the native browser to perform an
> OAuth2 sign in.  There are some limititions however.
>
> In general to use this you need an activity which has an intent filter to
> consume the redirect URL.  This works best if you use a custom URI scheme.
> Google, Yahoo, and Facebook (as well as other I'm sure) only allow
> redirects to http or https.  This means that unless you are using a third
> party to redirect a custom schema the browser my preempt your application
> and consume the redirect.  Other services such as KeyCloak and Spotify
> allow custom schemas and these work perfectly with my solution.
>
> If we document the limitations of the Intent and when using an Intent vs
> using a WebView is appropriate, is a solution with these limitations
> adequate? I think it is.

+1

>
> Thoughts?
>
> Summers
>
> PS: a link to my poc :
> https://github.com/secondsun/aerogear-android-authz/tree/AGDROID-319/
> PPS:  You can use this on the KeyCloakHelper in Shoot and Share by adding
> `setWithIntent(true)` to the configuration in that class.

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


--

abstractj
PGP: 0x84DC9914

From matzew at apache.org  Mon May  4 08:45:38 2015
From: matzew at apache.org (Matthias Wessendorf)
Date: Mon, 4 May 2015 14:45:38 +0200
Subject: [aerogear-dev] UPS: Java Sender for alpha.2
In-Reply-To: <CAAg5f2TsOPT6AKmyBaHG3-eL1HWgfszwoSerKr2PaFtVD601wA@mail.gmail.com>
References: <CAAg5f2Tm8mg36R5nT71yAxQDy=2H3kO9Ecqf69qTHv1L4vLC9g@mail.gmail.com>
	<1D09DF31-D2B4-4C36-A273-54AEE1E4B2F1@gmail.com>
	<CAAg5f2TZZk_P-V2nRhRhkVY0yEeyUd+SmMGKwT0iH6pdfR0NPw@mail.gmail.com>
	<CAEroY35LnKbQ7Dr_OyXPR93gYS=sgWP6k+x1AYkoESRkOSjF=Q@mail.gmail.com>
	<CAAg5f2TsOPT6AKmyBaHG3-eL1HWgfszwoSerKr2PaFtVD601wA@mail.gmail.com>
Message-ID: <CAAg5f2RFYoqtr_ok=c95s-J2YOz6wbDH1c=7q2bycHQ5wZ6RcQ@mail.gmail.com>

Ok, folks here is the staging repo:

https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-5450/

-Matthias

On Mon, May 4, 2015 at 12:49 PM, Matthias Wessendorf <matzew at apache.org>
wrote:

> +1
> let me do it
>
> On Mon, May 4, 2015 at 12:42 PM, Luk?? Fry? <lukas.fryc at gmail.com> wrote:
>
>> If we release Sender Java Client alpha2, we should also fix
>> https://issues.jboss.org/browse/AGPUSH-1377
>>
>> po 4. 5. 2015 v 12:39 odes?latel Matthias Wessendorf <matzew at apache.org>
>> napsal:
>>
>> thanks for the heads up - I will give it a spin
>>>
>>> On Mon, May 4, 2015 at 12:31 PM, S?bastien Blanc <scm.blanc at gmail.com>
>>> wrote:
>>>
>>>> Yes master is up to date with the latest push payload, should be good
>>>> to release.
>>>>
>>>> Envoy? de mon iPhone
>>>>
>>>> Le 4 mai 2015 ? 12:08, Matthias Wessendorf <matzew at apache.org> a
>>>> ?crit :
>>>>
>>>> Hi,
>>>>
>>>> w/ the release of the server, I think we should release the sender as
>>>> well:
>>>>
>>>> https://github.com/aerogear/aerogear-unifiedpush-java-client/blob/master/pom.xml#L23
>>>>
>>>> Just wondering, is it up-to-date regarding push payload?
>>>>
>>>> --
>>>> Matthias Wessendorf
>>>>
>>>> blog: http://matthiaswessendorf.wordpress.com/
>>>> sessions: http://www.slideshare.net/mwessendorf
>>>> twitter: http://twitter.com/mwessendorf
>>>>
>>>> _______________________________________________
>>>> aerogear-dev mailing list
>>>> aerogear-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>
>>>>
>>>> _______________________________________________
>>>> aerogear-dev mailing list
>>>> aerogear-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>
>>>
>>>
>>>
>>> --
>>> Matthias Wessendorf
>>>
>>> blog: http://matthiaswessendorf.wordpress.com/
>>> sessions: http://www.slideshare.net/mwessendorf
>>> twitter: http://twitter.com/mwessendorf
>>>  _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.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/20150504/58f753ef/attachment.html 

From cvasilak at gmail.com  Mon May  4 10:16:58 2015
From: cvasilak at gmail.com (Christos Vasilakis)
Date: Mon, 4 May 2015 17:16:58 +0300
Subject: [aerogear-dev] Team Meeting
In-Reply-To: <CAKVvow_=mvEfjf+Liirb4tZYsEOf3XgATespTo4+t3aENb+dYQ@mail.gmail.com>
References: <CAKVvow_=mvEfjf+Liirb4tZYsEOf3XgATespTo4+t3aENb+dYQ@mail.gmail.com>
Message-ID: <CAKVvow81dn5fzhuwSu1AEGGGRB9apEHXjxWPHFR8uVSDZDVnGg@mail.gmail.com>

fyi,
meeting minutes:

<jbott> Meeting ended Mon May  4 14:14:47 2015 UTC.  Information about
MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
<jbott> Minutes:
http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2015/aerogear.2015-05-04-14.00.html
<jbott> Minutes (text):
http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2015/aerogear.2015-05-04-14.00.txt
<jbott> Log:
http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2015/aerogear.2015-05-04-14.00.log.html

On Mon, May 4, 2015 at 9:47 AM, Christos Vasilakis <cvasilak at gmail.com>
wrote:

> agenda:
>
> http://oksoclap.com/p/aerogear-team-mgt-05.04.2015
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20150504/f04ecfcf/attachment.html 

From corinnekrych at gmail.com  Mon May  4 11:53:04 2015
From: corinnekrych at gmail.com (Corinne Krych)
Date: Mon, 4 May 2015 17:53:04 +0200
Subject: [aerogear-dev] Advanced Analtyics,
 new PR and call to the client tech leads
In-Reply-To: <CAL8vO=f49cuKORAahQhE45DEANBLTcn4x_+yMjBxbfMfpSkTTg@mail.gmail.com>
References: <CAD_dpu2LPTTYefjbpqt4TF2jUwhxmNzg2zpqcTDh7tPcjKtGQA@mail.gmail.com>
	<CAL8vO=f49cuKORAahQhE45DEANBLTcn4x_+yMjBxbfMfpSkTTg@mail.gmail.com>
Message-ID: <CAL8vO=eLktLpMMdU=5tgu4U5uoKHmRFNjZY2O4VOb1tmFLwY3Q@mail.gmail.com>

Hello Sebi,

After giving it a closer look, I've got a question for you: do we want to
collect metrics only when an app is opened via push notification or do we
also want to collect metrics when an app is brought to foreground by a push
notification?

++
Corinne


On 4 May 2015 at 10:21, Corinne Krych <corinnekrych at gmail.com> wrote:

> Yeap
> on it.
>
> On 30 April 2015 at 15:43, Sebastien Blanc <scm.blanc at gmail.com> wrote:
>
>> Hi,
>>
>> The Advanced Analytics task[1] has a new PR[2] that has been rebased on
>> the latest master and got a lot of polishing.
>>
>> Could the Client Tech Leads take a look at it [3] and review ? The only
>> "breaking" change is the rename of the header's name that identifies a Push
>> Notification, it's called now "aerogear-push-id"
>>
>> Seb
>>
>>
>>
>> [1] https://issues.jboss.org/browse/AGPUSH-971
>> [2] https://github.com/aerogear/aerogear-unifiedpush-server/pull/540
>> [3] Subtasks of https://issues.jboss.org/browse/AGPUSH-971
>>
>>
>>
>> _______________________________________________
>> 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/20150504/4f0c2e9d/attachment.html 

From scm.blanc at gmail.com  Mon May  4 13:07:09 2015
From: scm.blanc at gmail.com (=?utf-8?Q?S=C3=A9bastien_Blanc?=)
Date: Mon, 4 May 2015 19:07:09 +0200
Subject: [aerogear-dev] Advanced Analtyics,
	new PR and call to the client tech leads
In-Reply-To: <CAL8vO=eLktLpMMdU=5tgu4U5uoKHmRFNjZY2O4VOb1tmFLwY3Q@mail.gmail.com>
References: <CAD_dpu2LPTTYefjbpqt4TF2jUwhxmNzg2zpqcTDh7tPcjKtGQA@mail.gmail.com>
	<CAL8vO=f49cuKORAahQhE45DEANBLTcn4x_+yMjBxbfMfpSkTTg@mail.gmail.com>
	<CAL8vO=eLktLpMMdU=5tgu4U5uoKHmRFNjZY2O4VOb1tmFLwY3Q@mail.gmail.com>
Message-ID: <C36F5B92-74F3-4A2B-BAF5-6A50018ECC1D@gmail.com>

Hi Corinne !
We want to collect for both situations you described :)

Envoy? de mon iPhone

> Le 4 mai 2015 ? 17:53, Corinne Krych <corinnekrych at gmail.com> a ?crit :
> 
> Hello Sebi,
> 
> After giving it a closer look, I've got a question for you: do we want to collect metrics only when an app is opened via push notification or do we also want to collect metrics when an app is brought to foreground by a push notification?
> 
> ++
> Corinne
> 
> 
>> On 4 May 2015 at 10:21, Corinne Krych <corinnekrych at gmail.com> wrote:
>> Yeap
>> on it.
>> 
>>> On 30 April 2015 at 15:43, Sebastien Blanc <scm.blanc at gmail.com> wrote:
>>> Hi,
>>> 
>>> The Advanced Analytics task[1] has a new PR[2] that has been rebased on the latest master and got a lot of polishing.
>>> 
>>> Could the Client Tech Leads take a look at it [3] and review ? The only "breaking" change is the rename of the header's name that identifies a Push Notification, it's called now "aerogear-push-id" 
>>> 
>>> Seb
>>> 
>>> 
>>> 
>>> [1] https://issues.jboss.org/browse/AGPUSH-971
>>> [2] https://github.com/aerogear/aerogear-unifiedpush-server/pull/540
>>> [3] Subtasks of https://issues.jboss.org/browse/AGPUSH-971
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev at lists.jboss.org
>>> https://lists.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/20150504/8b469092/attachment-0001.html 

From corinnekrych at gmail.com  Tue May  5 03:26:39 2015
From: corinnekrych at gmail.com (Corinne Krych)
Date: Tue, 5 May 2015 09:26:39 +0200
Subject: [aerogear-dev] Advanced Analtyics,
 new PR and call to the client tech leads
In-Reply-To: <C36F5B92-74F3-4A2B-BAF5-6A50018ECC1D@gmail.com>
References: <CAD_dpu2LPTTYefjbpqt4TF2jUwhxmNzg2zpqcTDh7tPcjKtGQA@mail.gmail.com>
	<CAL8vO=f49cuKORAahQhE45DEANBLTcn4x_+yMjBxbfMfpSkTTg@mail.gmail.com>
	<CAL8vO=eLktLpMMdU=5tgu4U5uoKHmRFNjZY2O4VOb1tmFLwY3Q@mail.gmail.com>
	<C36F5B92-74F3-4A2B-BAF5-6A50018ECC1D@gmail.com>
Message-ID: <CAL8vO=c-22FWacpRzqjR+y2fobAXUNqsM5HhnFY_gHR-h8_8Sw@mail.gmail.com>

Hello Sebi,


I've done an initial work on aerogear-ios-push [swift branch], adding a new
parameter when doing the registration to pass the ag-push-id. See:

https://github.com/aerogear/aerogear-ios-push/compare/aerogear:master...corinnekrych:AGPUSH-1232.analytics.push.notification?expand=1

This client could be tested with HelloWorld. See:


https://github.com/jboss-mobile/unified-push-helloworld/compare/jboss-mobile:swift...corinnekrych:AGPUSH-1232.analytics.push.notification?expand=1

What is not covered is the background app coming to foreground through a
push notification. If you look at HelloWorld:

https://github.com/jboss-mobile/unified-push-helloworld/blob/f7d0a7e093327f9a84041910c4c2892280c88ffb/ios-swift/HelloWorldSwift/AppDelegate.swift#L152

In iOS, when we go from background to foreground we don't go through
registration API. The iOS push lib doesn't store locally (as opposed to
windows sdk for ex) the device information. So i can't really make another
call to registration API. What i'd suggest is to have a separate endpoint
for metrics instead of having it coupled with registration endpoint. wdyt?

++
Corinne

On 4 May 2015 at 19:07, S?bastien Blanc <scm.blanc at gmail.com> wrote:

> Hi Corinne !
> We want to collect for both situations you described :)
>
> Envoy? de mon iPhone
>
> Le 4 mai 2015 ? 17:53, Corinne Krych <corinnekrych at gmail.com> a ?crit :
>
> Hello Sebi,
>
> After giving it a closer look, I've got a question for you: do we want to
> collect metrics only when an app is opened via push notification or do we
> also want to collect metrics when an app is brought to foreground by a push
> notification?
>
> ++
> Corinne
>
>
> On 4 May 2015 at 10:21, Corinne Krych <corinnekrych at gmail.com> wrote:
>
>> Yeap
>> on it.
>>
>> On 30 April 2015 at 15:43, Sebastien Blanc <scm.blanc at gmail.com> wrote:
>>
>>> Hi,
>>>
>>> The Advanced Analytics task[1] has a new PR[2] that has been rebased on
>>> the latest master and got a lot of polishing.
>>>
>>> Could the Client Tech Leads take a look at it [3] and review ? The only
>>> "breaking" change is the rename of the header's name that identifies a Push
>>> Notification, it's called now "aerogear-push-id"
>>>
>>> Seb
>>>
>>>
>>>
>>> [1] https://issues.jboss.org/browse/AGPUSH-971
>>> [2] https://github.com/aerogear/aerogear-unifiedpush-server/pull/540
>>> [3] Subtasks of https://issues.jboss.org/browse/AGPUSH-971
>>>
>>>
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev at lists.jboss.org
>>> https://lists.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/20150505/90d9da06/attachment.html 

From edewit at redhat.com  Tue May  5 04:39:13 2015
From: edewit at redhat.com (Erik Jan de Wit)
Date: Tue, 5 May 2015 10:39:13 +0200
Subject: [aerogear-dev] Advanced Analtyics,
 new PR and call to the client tech leads
In-Reply-To: <CAL8vO=c-22FWacpRzqjR+y2fobAXUNqsM5HhnFY_gHR-h8_8Sw@mail.gmail.com>
References: <CAD_dpu2LPTTYefjbpqt4TF2jUwhxmNzg2zpqcTDh7tPcjKtGQA@mail.gmail.com>
	<CAL8vO=f49cuKORAahQhE45DEANBLTcn4x_+yMjBxbfMfpSkTTg@mail.gmail.com>
	<CAL8vO=eLktLpMMdU=5tgu4U5uoKHmRFNjZY2O4VOb1tmFLwY3Q@mail.gmail.com>
	<C36F5B92-74F3-4A2B-BAF5-6A50018ECC1D@gmail.com>
	<CAL8vO=c-22FWacpRzqjR+y2fobAXUNqsM5HhnFY_gHR-h8_8Sw@mail.gmail.com>
Message-ID: <CAO2B-faqA+WKx1CfikVpaERGiS3HJQAeB+mbVQTb9GQfg2mHKA@mail.gmail.com>

I agree with this and maybe we want even more functionality moved,
because also updating the categories is strange in a 'register'
method. Say for instance you want to change the categories your
interested in a developer has to call register again? And if I
understand Corinnes mail that will currently not even work on iOS.

For cordova I store the device info, because the lifecycle is
different, but that is okay it's an integration problem.

So updating the installation details should be a separate method that
also contains updating the categories. That way we have a better split
between a device that registers itself with UPS and updating the
subscription data.


On Tue, May 5, 2015 at 9:26 AM, Corinne Krych <corinnekrych at gmail.com> wrote:
> Hello Sebi,
>
>
> I've done an initial work on aerogear-ios-push [swift branch], adding a new
> parameter when doing the registration to pass the ag-push-id. See:
>
> https://github.com/aerogear/aerogear-ios-push/compare/aerogear:master...corinnekrych:AGPUSH-1232.analytics.push.notification?expand=1
>
> This client could be tested with HelloWorld. See:
>
> https://github.com/jboss-mobile/unified-push-helloworld/compare/jboss-mobile:swift...corinnekrych:AGPUSH-1232.analytics.push.notification?expand=1
>
> What is not covered is the background app coming to foreground through a
> push notification. If you look at HelloWorld:
>
> https://github.com/jboss-mobile/unified-push-helloworld/blob/f7d0a7e093327f9a84041910c4c2892280c88ffb/ios-swift/HelloWorldSwift/AppDelegate.swift#L152
>
> In iOS, when we go from background to foreground we don't go through
> registration API. The iOS push lib doesn't store locally (as opposed to
> windows sdk for ex) the device information. So i can't really make another
> call to registration API. What i'd suggest is to have a separate endpoint
> for metrics instead of having it coupled with registration endpoint. wdyt?
>
> ++
>
> Corinne
>
> On 4 May 2015 at 19:07, S?bastien Blanc <scm.blanc at gmail.com> wrote:
>>
>> Hi Corinne !
>> We want to collect for both situations you described :)
>>
>> Envoy? de mon iPhone
>>
>> Le 4 mai 2015 ? 17:53, Corinne Krych <corinnekrych at gmail.com> a ?crit :
>>
>> Hello Sebi,
>>
>> After giving it a closer look, I've got a question for you: do we want to
>> collect metrics only when an app is opened via push notification or do we
>> also want to collect metrics when an app is brought to foreground by a push
>> notification?
>>
>> ++
>> Corinne
>>
>>
>> On 4 May 2015 at 10:21, Corinne Krych <corinnekrych at gmail.com> wrote:
>>>
>>> Yeap
>>> on it.
>>>
>>> On 30 April 2015 at 15:43, Sebastien Blanc <scm.blanc at gmail.com> wrote:
>>>>
>>>> Hi,
>>>>
>>>> The Advanced Analytics task[1] has a new PR[2] that has been rebased on
>>>> the latest master and got a lot of polishing.
>>>>
>>>> Could the Client Tech Leads take a look at it [3] and review ? The only
>>>> "breaking" change is the rename of the header's name that identifies a Push
>>>> Notification, it's called now "aerogear-push-id"
>>>>
>>>> Seb
>>>>
>>>>
>>>>
>>>> [1] https://issues.jboss.org/browse/AGPUSH-971
>>>> [2] https://github.com/aerogear/aerogear-unifiedpush-server/pull/540
>>>> [3] Subtasks of https://issues.jboss.org/browse/AGPUSH-971
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> aerogear-dev mailing list
>>>> aerogear-dev at lists.jboss.org
>>>> https://lists.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



-- 
Cheers,
       Erik Jan


From matzew at apache.org  Tue May  5 04:48:23 2015
From: matzew at apache.org (Matthias Wessendorf)
Date: Tue, 5 May 2015 10:48:23 +0200
Subject: [aerogear-dev] Advanced Analtyics,
 new PR and call to the client tech leads
In-Reply-To: <CAL8vO=c-22FWacpRzqjR+y2fobAXUNqsM5HhnFY_gHR-h8_8Sw@mail.gmail.com>
References: <CAD_dpu2LPTTYefjbpqt4TF2jUwhxmNzg2zpqcTDh7tPcjKtGQA@mail.gmail.com>
	<CAL8vO=f49cuKORAahQhE45DEANBLTcn4x_+yMjBxbfMfpSkTTg@mail.gmail.com>
	<CAL8vO=eLktLpMMdU=5tgu4U5uoKHmRFNjZY2O4VOb1tmFLwY3Q@mail.gmail.com>
	<C36F5B92-74F3-4A2B-BAF5-6A50018ECC1D@gmail.com>
	<CAL8vO=c-22FWacpRzqjR+y2fobAXUNqsM5HhnFY_gHR-h8_8Sw@mail.gmail.com>
Message-ID: <CAAg5f2Q=r3B8y7Kf7D7Dyfa2-y9JvmTGskkZFE78TpgiEo=iow@mail.gmail.com>

On Tue, May 5, 2015 at 9:26 AM, Corinne Krych <corinnekrych at gmail.com>
wrote:

> Hello Sebi,
>
>
> I've done an initial work on aerogear-ios-push [swift branch], adding a
> new parameter when doing the registration to pass the ag-push-id. See:
>
>
> https://github.com/aerogear/aerogear-ios-push/compare/aerogear:master...corinnekrych:AGPUSH-1232.analytics.push.notification?expand=1
>
> This client could be tested with HelloWorld. See:
>
>
> https://github.com/jboss-mobile/unified-push-helloworld/compare/jboss-mobile:swift...corinnekrych:AGPUSH-1232.analytics.push.notification?expand=1
>
> What is not covered is the background app coming to foreground through a
> push notification. If you look at HelloWorld:
>
>
> https://github.com/jboss-mobile/unified-push-helloworld/blob/f7d0a7e093327f9a84041910c4c2892280c88ffb/ios-swift/HelloWorldSwift/AppDelegate.swift#L152
>
> In iOS, when we go from background to foreground we don't go through
> registration API. The iOS push lib doesn't store locally (as opposed to
> windows sdk for ex) the device information. So i can't really make another
> call to registration API. What i'd suggest is to have a separate endpoint
> for metrics instead of having it coupled with registration endpoint. wdyt?
>

Ok, if that's needed, it has to be done! Thanks for the feedback and
research here. But before we change, let's see how it behaves on Android


> ++
> Corinne
>
> On 4 May 2015 at 19:07, S?bastien Blanc <scm.blanc at gmail.com> wrote:
>
>> Hi Corinne !
>> We want to collect for both situations you described :)
>>
>> Envoy? de mon iPhone
>>
>> Le 4 mai 2015 ? 17:53, Corinne Krych <corinnekrych at gmail.com> a ?crit :
>>
>> Hello Sebi,
>>
>> After giving it a closer look, I've got a question for you: do we want to
>> collect metrics only when an app is opened via push notification or do we
>> also want to collect metrics when an app is brought to foreground by a push
>> notification?
>>
>> ++
>> Corinne
>>
>>
>> On 4 May 2015 at 10:21, Corinne Krych <corinnekrych at gmail.com> wrote:
>>
>>> Yeap
>>> on it.
>>>
>>> On 30 April 2015 at 15:43, Sebastien Blanc <scm.blanc at gmail.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> The Advanced Analytics task[1] has a new PR[2] that has been rebased on
>>>> the latest master and got a lot of polishing.
>>>>
>>>> Could the Client Tech Leads take a look at it [3] and review ? The only
>>>> "breaking" change is the rename of the header's name that identifies a Push
>>>> Notification, it's called now "aerogear-push-id"
>>>>
>>>> Seb
>>>>
>>>>
>>>>
>>>> [1] https://issues.jboss.org/browse/AGPUSH-971
>>>> [2] https://github.com/aerogear/aerogear-unifiedpush-server/pull/540
>>>> [3] Subtasks of https://issues.jboss.org/browse/AGPUSH-971
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> aerogear-dev mailing list
>>>> aerogear-dev at lists.jboss.org
>>>> https://lists.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/20150505/1acfe7e8/attachment-0001.html 

From matzew at apache.org  Tue May  5 04:51:30 2015
From: matzew at apache.org (Matthias Wessendorf)
Date: Tue, 5 May 2015 10:51:30 +0200
Subject: [aerogear-dev] Advanced Analtyics,
 new PR and call to the client tech leads
In-Reply-To: <CAO2B-faqA+WKx1CfikVpaERGiS3HJQAeB+mbVQTb9GQfg2mHKA@mail.gmail.com>
References: <CAD_dpu2LPTTYefjbpqt4TF2jUwhxmNzg2zpqcTDh7tPcjKtGQA@mail.gmail.com>
	<CAL8vO=f49cuKORAahQhE45DEANBLTcn4x_+yMjBxbfMfpSkTTg@mail.gmail.com>
	<CAL8vO=eLktLpMMdU=5tgu4U5uoKHmRFNjZY2O4VOb1tmFLwY3Q@mail.gmail.com>
	<C36F5B92-74F3-4A2B-BAF5-6A50018ECC1D@gmail.com>
	<CAL8vO=c-22FWacpRzqjR+y2fobAXUNqsM5HhnFY_gHR-h8_8Sw@mail.gmail.com>
	<CAO2B-faqA+WKx1CfikVpaERGiS3HJQAeB+mbVQTb9GQfg2mHKA@mail.gmail.com>
Message-ID: <CAAg5f2SjHzhwK5iOFUu69V=Nji6F2yYVdon=RPyz4Xjr3Kor+w@mail.gmail.com>

On Tue, May 5, 2015 at 10:39 AM, Erik Jan de Wit <edewit at redhat.com> wrote:

> I agree with this and maybe we want even more functionality moved,
> because also updating the categories is strange in a 'register'
> method. Say for instance you want to change the categories your
> interested in a developer has to call register again?


Right, there could be an update function on the client sdk.

For update we than could do PUT - instead of always do POST (since taht is
done now on the register)


> And if I
> understand Corinnes mail that will currently not even work on iOS.
>
> For cordova I store the device info, because the lifecycle is
> different, but that is okay it's an integration problem.
>
> So updating the installation details should be a separate method that
> also contains updating the categories. That way we have a better split
> between a device that registers itself with UPS and updating the
> subscription data.
>

sounds good to me!


>
>
> On Tue, May 5, 2015 at 9:26 AM, Corinne Krych <corinnekrych at gmail.com>
> wrote:
> > Hello Sebi,
> >
> >
> > I've done an initial work on aerogear-ios-push [swift branch], adding a
> new
> > parameter when doing the registration to pass the ag-push-id. See:
> >
> >
> https://github.com/aerogear/aerogear-ios-push/compare/aerogear:master...corinnekrych:AGPUSH-1232.analytics.push.notification?expand=1
> >
> > This client could be tested with HelloWorld. See:
> >
> >
> https://github.com/jboss-mobile/unified-push-helloworld/compare/jboss-mobile:swift...corinnekrych:AGPUSH-1232.analytics.push.notification?expand=1
> >
> > What is not covered is the background app coming to foreground through a
> > push notification. If you look at HelloWorld:
> >
> >
> https://github.com/jboss-mobile/unified-push-helloworld/blob/f7d0a7e093327f9a84041910c4c2892280c88ffb/ios-swift/HelloWorldSwift/AppDelegate.swift#L152
> >
> > In iOS, when we go from background to foreground we don't go through
> > registration API. The iOS push lib doesn't store locally (as opposed to
> > windows sdk for ex) the device information. So i can't really make
> another
> > call to registration API. What i'd suggest is to have a separate endpoint
> > for metrics instead of having it coupled with registration endpoint.
> wdyt?
> >
> > ++
> >
> > Corinne
> >
> > On 4 May 2015 at 19:07, S?bastien Blanc <scm.blanc at gmail.com> wrote:
> >>
> >> Hi Corinne !
> >> We want to collect for both situations you described :)
> >>
> >> Envoy? de mon iPhone
> >>
> >> Le 4 mai 2015 ? 17:53, Corinne Krych <corinnekrych at gmail.com> a ?crit :
> >>
> >> Hello Sebi,
> >>
> >> After giving it a closer look, I've got a question for you: do we want
> to
> >> collect metrics only when an app is opened via push notification or do
> we
> >> also want to collect metrics when an app is brought to foreground by a
> push
> >> notification?
> >>
> >> ++
> >> Corinne
> >>
> >>
> >> On 4 May 2015 at 10:21, Corinne Krych <corinnekrych at gmail.com> wrote:
> >>>
> >>> Yeap
> >>> on it.
> >>>
> >>> On 30 April 2015 at 15:43, Sebastien Blanc <scm.blanc at gmail.com>
> wrote:
> >>>>
> >>>> Hi,
> >>>>
> >>>> The Advanced Analytics task[1] has a new PR[2] that has been rebased
> on
> >>>> the latest master and got a lot of polishing.
> >>>>
> >>>> Could the Client Tech Leads take a look at it [3] and review ? The
> only
> >>>> "breaking" change is the rename of the header's name that identifies
> a Push
> >>>> Notification, it's called now "aerogear-push-id"
> >>>>
> >>>> Seb
> >>>>
> >>>>
> >>>>
> >>>> [1] https://issues.jboss.org/browse/AGPUSH-971
> >>>> [2] https://github.com/aerogear/aerogear-unifiedpush-server/pull/540
> >>>> [3] Subtasks of https://issues.jboss.org/browse/AGPUSH-971
> >>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> aerogear-dev mailing list
> >>>> aerogear-dev at lists.jboss.org
> >>>> https://lists.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
>
>
>
> --
> Cheers,
>        Erik Jan
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.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/20150505/be215649/attachment.html 

From corinnekrych at gmail.com  Tue May  5 04:53:06 2015
From: corinnekrych at gmail.com (Corinne Krych)
Date: Tue, 5 May 2015 10:53:06 +0200
Subject: [aerogear-dev] Advanced Analtyics,
 new PR and call to the client tech leads
In-Reply-To: <CAO2B-faqA+WKx1CfikVpaERGiS3HJQAeB+mbVQTb9GQfg2mHKA@mail.gmail.com>
References: <CAD_dpu2LPTTYefjbpqt4TF2jUwhxmNzg2zpqcTDh7tPcjKtGQA@mail.gmail.com>
	<CAL8vO=f49cuKORAahQhE45DEANBLTcn4x_+yMjBxbfMfpSkTTg@mail.gmail.com>
	<CAL8vO=eLktLpMMdU=5tgu4U5uoKHmRFNjZY2O4VOb1tmFLwY3Q@mail.gmail.com>
	<C36F5B92-74F3-4A2B-BAF5-6A50018ECC1D@gmail.com>
	<CAL8vO=c-22FWacpRzqjR+y2fobAXUNqsM5HhnFY_gHR-h8_8Sw@mail.gmail.com>
	<CAO2B-faqA+WKx1CfikVpaERGiS3HJQAeB+mbVQTb9GQfg2mHKA@mail.gmail.com>
Message-ID: <CAL8vO=e=C_VZNaYpkAacTfDW44cpVrs=ydX0vmmfY5HQYCw4uA@mail.gmail.com>

To give a bit of background on this background to foreground issue :))

Push Cordova plugin matches Cordova life cycle by storing some information
locally see:
https://github.com/aerogear/aerogear-cordova-push/blob/master/src/ios/AGPushPlugin.m#L82
Doing so allows you to call multiple time registration, even when an app
comes back from background to foreground. you can do it because you have
stored locally all the information neede for registration.

But when dealing directly with native apps, the life cycle does not always
goes through a registration.

To sort out this issue,we can:
- either store locally at the ios-push lib level instead of doing it in
Cordova plugin and then call registration API on all delegate methods (even
though we don't want to register but just send the metrics)
- or leave the ios-push lib without any storage and provide a separate
endpoint for sending metrics or changing categories.

I'd go for the second option.

++
Corinne

On 5 May 2015 at 10:39, Erik Jan de Wit <edewit at redhat.com> wrote:

> I agree with this and maybe we want even more functionality moved,
> because also updating the categories is strange in a 'register'
> method. Say for instance you want to change the categories your
> interested in a developer has to call register again? And if I
> understand Corinnes mail that will currently not even work on iOS.
>
> For cordova I store the device info, because the lifecycle is
> different, but that is okay it's an integration problem.
>
> So updating the installation details should be a separate method that
> also contains updating the categories. That way we have a better split
> between a device that registers itself with UPS and updating the
> subscription data.
>
>
> On Tue, May 5, 2015 at 9:26 AM, Corinne Krych <corinnekrych at gmail.com>
> wrote:
> > Hello Sebi,
> >
> >
> > I've done an initial work on aerogear-ios-push [swift branch], adding a
> new
> > parameter when doing the registration to pass the ag-push-id. See:
> >
> >
> https://github.com/aerogear/aerogear-ios-push/compare/aerogear:master...corinnekrych:AGPUSH-1232.analytics.push.notification?expand=1
> >
> > This client could be tested with HelloWorld. See:
> >
> >
> https://github.com/jboss-mobile/unified-push-helloworld/compare/jboss-mobile:swift...corinnekrych:AGPUSH-1232.analytics.push.notification?expand=1
> >
> > What is not covered is the background app coming to foreground through a
> > push notification. If you look at HelloWorld:
> >
> >
> https://github.com/jboss-mobile/unified-push-helloworld/blob/f7d0a7e093327f9a84041910c4c2892280c88ffb/ios-swift/HelloWorldSwift/AppDelegate.swift#L152
> >
> > In iOS, when we go from background to foreground we don't go through
> > registration API. The iOS push lib doesn't store locally (as opposed to
> > windows sdk for ex) the device information. So i can't really make
> another
> > call to registration API. What i'd suggest is to have a separate endpoint
> > for metrics instead of having it coupled with registration endpoint.
> wdyt?
> >
> > ++
> >
> > Corinne
> >
> > On 4 May 2015 at 19:07, S?bastien Blanc <scm.blanc at gmail.com> wrote:
> >>
> >> Hi Corinne !
> >> We want to collect for both situations you described :)
> >>
> >> Envoy? de mon iPhone
> >>
> >> Le 4 mai 2015 ? 17:53, Corinne Krych <corinnekrych at gmail.com> a ?crit :
> >>
> >> Hello Sebi,
> >>
> >> After giving it a closer look, I've got a question for you: do we want
> to
> >> collect metrics only when an app is opened via push notification or do
> we
> >> also want to collect metrics when an app is brought to foreground by a
> push
> >> notification?
> >>
> >> ++
> >> Corinne
> >>
> >>
> >> On 4 May 2015 at 10:21, Corinne Krych <corinnekrych at gmail.com> wrote:
> >>>
> >>> Yeap
> >>> on it.
> >>>
> >>> On 30 April 2015 at 15:43, Sebastien Blanc <scm.blanc at gmail.com>
> wrote:
> >>>>
> >>>> Hi,
> >>>>
> >>>> The Advanced Analytics task[1] has a new PR[2] that has been rebased
> on
> >>>> the latest master and got a lot of polishing.
> >>>>
> >>>> Could the Client Tech Leads take a look at it [3] and review ? The
> only
> >>>> "breaking" change is the rename of the header's name that identifies
> a Push
> >>>> Notification, it's called now "aerogear-push-id"
> >>>>
> >>>> Seb
> >>>>
> >>>>
> >>>>
> >>>> [1] https://issues.jboss.org/browse/AGPUSH-971
> >>>> [2] https://github.com/aerogear/aerogear-unifiedpush-server/pull/540
> >>>> [3] Subtasks of https://issues.jboss.org/browse/AGPUSH-971
> >>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> aerogear-dev mailing list
> >>>> aerogear-dev at lists.jboss.org
> >>>> https://lists.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
>
>
>
> --
> Cheers,
>        Erik Jan
>
> _______________________________________________
> 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/20150505/063fa586/attachment-0001.html 

From corinnekrych at gmail.com  Tue May  5 04:54:41 2015
From: corinnekrych at gmail.com (Corinne Krych)
Date: Tue, 5 May 2015 10:54:41 +0200
Subject: [aerogear-dev] Advanced Analtyics,
 new PR and call to the client tech leads
In-Reply-To: <CAL8vO=e=C_VZNaYpkAacTfDW44cpVrs=ydX0vmmfY5HQYCw4uA@mail.gmail.com>
References: <CAD_dpu2LPTTYefjbpqt4TF2jUwhxmNzg2zpqcTDh7tPcjKtGQA@mail.gmail.com>
	<CAL8vO=f49cuKORAahQhE45DEANBLTcn4x_+yMjBxbfMfpSkTTg@mail.gmail.com>
	<CAL8vO=eLktLpMMdU=5tgu4U5uoKHmRFNjZY2O4VOb1tmFLwY3Q@mail.gmail.com>
	<C36F5B92-74F3-4A2B-BAF5-6A50018ECC1D@gmail.com>
	<CAL8vO=c-22FWacpRzqjR+y2fobAXUNqsM5HhnFY_gHR-h8_8Sw@mail.gmail.com>
	<CAO2B-faqA+WKx1CfikVpaERGiS3HJQAeB+mbVQTb9GQfg2mHKA@mail.gmail.com>
	<CAL8vO=e=C_VZNaYpkAacTfDW44cpVrs=ydX0vmmfY5HQYCw4uA@mail.gmail.com>
Message-ID: <CAL8vO=dxczY2aijHDzoDmx4Z+SsYO9k4qQch3Ls9VmTFSMoxPA@mail.gmail.com>

@matt I missed your reply, but we're on the same page :)

On 5 May 2015 at 10:53, Corinne Krych <corinnekrych at gmail.com> wrote:

> To give a bit of background on this background to foreground issue :))
>
> Push Cordova plugin matches Cordova life cycle by storing some information
> locally see:
>
> https://github.com/aerogear/aerogear-cordova-push/blob/master/src/ios/AGPushPlugin.m#L82
> Doing so allows you to call multiple time registration, even when an app
> comes back from background to foreground. you can do it because you have
> stored locally all the information neede for registration.
>
> But when dealing directly with native apps, the life cycle does not always
> goes through a registration.
>
> To sort out this issue,we can:
> - either store locally at the ios-push lib level instead of doing it in
> Cordova plugin and then call registration API on all delegate methods (even
> though we don't want to register but just send the metrics)
> - or leave the ios-push lib without any storage and provide a separate
> endpoint for sending metrics or changing categories.
>
> I'd go for the second option.
>
> ++
> Corinne
>
>
> On 5 May 2015 at 10:39, Erik Jan de Wit <edewit at redhat.com> wrote:
>
>> I agree with this and maybe we want even more functionality moved,
>> because also updating the categories is strange in a 'register'
>> method. Say for instance you want to change the categories your
>> interested in a developer has to call register again? And if I
>> understand Corinnes mail that will currently not even work on iOS.
>>
>> For cordova I store the device info, because the lifecycle is
>> different, but that is okay it's an integration problem.
>>
>> So updating the installation details should be a separate method that
>> also contains updating the categories. That way we have a better split
>> between a device that registers itself with UPS and updating the
>> subscription data.
>>
>>
>> On Tue, May 5, 2015 at 9:26 AM, Corinne Krych <corinnekrych at gmail.com>
>> wrote:
>> > Hello Sebi,
>> >
>> >
>> > I've done an initial work on aerogear-ios-push [swift branch], adding a
>> new
>> > parameter when doing the registration to pass the ag-push-id. See:
>> >
>> >
>> https://github.com/aerogear/aerogear-ios-push/compare/aerogear:master...corinnekrych:AGPUSH-1232.analytics.push.notification?expand=1
>> >
>> > This client could be tested with HelloWorld. See:
>> >
>> >
>> https://github.com/jboss-mobile/unified-push-helloworld/compare/jboss-mobile:swift...corinnekrych:AGPUSH-1232.analytics.push.notification?expand=1
>> >
>> > What is not covered is the background app coming to foreground through a
>> > push notification. If you look at HelloWorld:
>> >
>> >
>> https://github.com/jboss-mobile/unified-push-helloworld/blob/f7d0a7e093327f9a84041910c4c2892280c88ffb/ios-swift/HelloWorldSwift/AppDelegate.swift#L152
>> >
>> > In iOS, when we go from background to foreground we don't go through
>> > registration API. The iOS push lib doesn't store locally (as opposed to
>> > windows sdk for ex) the device information. So i can't really make
>> another
>> > call to registration API. What i'd suggest is to have a separate
>> endpoint
>> > for metrics instead of having it coupled with registration endpoint.
>> wdyt?
>> >
>> > ++
>> >
>> > Corinne
>> >
>> > On 4 May 2015 at 19:07, S?bastien Blanc <scm.blanc at gmail.com> wrote:
>> >>
>> >> Hi Corinne !
>> >> We want to collect for both situations you described :)
>> >>
>> >> Envoy? de mon iPhone
>> >>
>> >> Le 4 mai 2015 ? 17:53, Corinne Krych <corinnekrych at gmail.com> a ?crit
>> :
>> >>
>> >> Hello Sebi,
>> >>
>> >> After giving it a closer look, I've got a question for you: do we want
>> to
>> >> collect metrics only when an app is opened via push notification or do
>> we
>> >> also want to collect metrics when an app is brought to foreground by a
>> push
>> >> notification?
>> >>
>> >> ++
>> >> Corinne
>> >>
>> >>
>> >> On 4 May 2015 at 10:21, Corinne Krych <corinnekrych at gmail.com> wrote:
>> >>>
>> >>> Yeap
>> >>> on it.
>> >>>
>> >>> On 30 April 2015 at 15:43, Sebastien Blanc <scm.blanc at gmail.com>
>> wrote:
>> >>>>
>> >>>> Hi,
>> >>>>
>> >>>> The Advanced Analytics task[1] has a new PR[2] that has been rebased
>> on
>> >>>> the latest master and got a lot of polishing.
>> >>>>
>> >>>> Could the Client Tech Leads take a look at it [3] and review ? The
>> only
>> >>>> "breaking" change is the rename of the header's name that identifies
>> a Push
>> >>>> Notification, it's called now "aerogear-push-id"
>> >>>>
>> >>>> Seb
>> >>>>
>> >>>>
>> >>>>
>> >>>> [1] https://issues.jboss.org/browse/AGPUSH-971
>> >>>> [2] https://github.com/aerogear/aerogear-unifiedpush-server/pull/540
>> >>>> [3] Subtasks of https://issues.jboss.org/browse/AGPUSH-971
>> >>>>
>> >>>>
>> >>>>
>> >>>> _______________________________________________
>> >>>> aerogear-dev mailing list
>> >>>> aerogear-dev at lists.jboss.org
>> >>>> https://lists.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
>>
>>
>>
>> --
>> Cheers,
>>        Erik Jan
>>
>> _______________________________________________
>> 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/20150505/f19c5a5e/attachment.html 

From cvasilak at gmail.com  Tue May  5 05:09:36 2015
From: cvasilak at gmail.com (Christos Vasilakis)
Date: Tue, 5 May 2015 12:09:36 +0300
Subject: [aerogear-dev] Advanced Analtyics,
 new PR and call to the client tech leads
In-Reply-To: <CAL8vO=e=C_VZNaYpkAacTfDW44cpVrs=ydX0vmmfY5HQYCw4uA@mail.gmail.com>
References: <CAD_dpu2LPTTYefjbpqt4TF2jUwhxmNzg2zpqcTDh7tPcjKtGQA@mail.gmail.com>
	<CAL8vO=f49cuKORAahQhE45DEANBLTcn4x_+yMjBxbfMfpSkTTg@mail.gmail.com>
	<CAL8vO=eLktLpMMdU=5tgu4U5uoKHmRFNjZY2O4VOb1tmFLwY3Q@mail.gmail.com>
	<C36F5B92-74F3-4A2B-BAF5-6A50018ECC1D@gmail.com>
	<CAL8vO=c-22FWacpRzqjR+y2fobAXUNqsM5HhnFY_gHR-h8_8Sw@mail.gmail.com>
	<CAO2B-faqA+WKx1CfikVpaERGiS3HJQAeB+mbVQTb9GQfg2mHKA@mail.gmail.com>
	<CAL8vO=e=C_VZNaYpkAacTfDW44cpVrs=ydX0vmmfY5HQYCw4uA@mail.gmail.com>
Message-ID: <CAKVvow-8uNu4OuivKkLOURMc1b-Jf=hQUqecwEKY7h=-Hh1diA@mail.gmail.com>

On Tue, May 5, 2015 at 11:53 AM, Corinne Krych <corinnekrych at gmail.com>
wrote:

> To give a bit of background on this background to foreground issue :))
>
> Push Cordova plugin matches Cordova life cycle by storing some information
> locally see:
>
> https://github.com/aerogear/aerogear-cordova-push/blob/master/src/ios/AGPushPlugin.m#L82
> Doing so allows you to call multiple time registration, even when an app
> comes back from background to foreground. you can do it because you have
> stored locally all the information neede for registration.
>
> But when dealing directly with native apps, the life cycle does not always
> goes through a registration.
>
> To sort out this issue,we can:
> - either store locally at the ios-push lib level instead of doing it in
> Cordova plugin and then call registration API on all delegate methods (even
> though we don't want to register but just send the metrics)
> - or leave the ios-push lib without any storage and provide a separate
> endpoint for sending metrics or changing categories.
>
> I'd go for the second option.
>
> second option makes sense +1

-
Christos

>
>
> On 5 May 2015 at 10:39, Erik Jan de Wit <edewit at redhat.com> wrote:
>
>> I agree with this and maybe we want even more functionality moved,
>> because also updating the categories is strange in a 'register'
>> method. Say for instance you want to change the categories your
>> interested in a developer has to call register again? And if I
>> understand Corinnes mail that will currently not even work on iOS.
>>
>> For cordova I store the device info, because the lifecycle is
>> different, but that is okay it's an integration problem.
>>
>> So updating the installation details should be a separate method that
>> also contains updating the categories. That way we have a better split
>> between a device that registers itself with UPS and updating the
>> subscription data.
>>
>>
>> On Tue, May 5, 2015 at 9:26 AM, Corinne Krych <corinnekrych at gmail.com>
>> wrote:
>> > Hello Sebi,
>> >
>> >
>> > I've done an initial work on aerogear-ios-push [swift branch], adding a
>> new
>> > parameter when doing the registration to pass the ag-push-id. See:
>> >
>> >
>> https://github.com/aerogear/aerogear-ios-push/compare/aerogear:master...corinnekrych:AGPUSH-1232.analytics.push.notification?expand=1
>> >
>> > This client could be tested with HelloWorld. See:
>> >
>> >
>> https://github.com/jboss-mobile/unified-push-helloworld/compare/jboss-mobile:swift...corinnekrych:AGPUSH-1232.analytics.push.notification?expand=1
>> >
>> > What is not covered is the background app coming to foreground through a
>> > push notification. If you look at HelloWorld:
>> >
>> >
>> https://github.com/jboss-mobile/unified-push-helloworld/blob/f7d0a7e093327f9a84041910c4c2892280c88ffb/ios-swift/HelloWorldSwift/AppDelegate.swift#L152
>> >
>> > In iOS, when we go from background to foreground we don't go through
>> > registration API. The iOS push lib doesn't store locally (as opposed to
>> > windows sdk for ex) the device information. So i can't really make
>> another
>> > call to registration API. What i'd suggest is to have a separate
>> endpoint
>> > for metrics instead of having it coupled with registration endpoint.
>> wdyt?
>> >
>> > ++
>> >
>> > Corinne
>> >
>> > On 4 May 2015 at 19:07, S?bastien Blanc <scm.blanc at gmail.com> wrote:
>> >>
>> >> Hi Corinne !
>> >> We want to collect for both situations you described :)
>> >>
>> >> Envoy? de mon iPhone
>> >>
>> >> Le 4 mai 2015 ? 17:53, Corinne Krych <corinnekrych at gmail.com> a ?crit
>> :
>> >>
>> >> Hello Sebi,
>> >>
>> >> After giving it a closer look, I've got a question for you: do we want
>> to
>> >> collect metrics only when an app is opened via push notification or do
>> we
>> >> also want to collect metrics when an app is brought to foreground by a
>> push
>> >> notification?
>> >>
>> >> ++
>> >> Corinne
>> >>
>> >>
>> >> On 4 May 2015 at 10:21, Corinne Krych <corinnekrych at gmail.com> wrote:
>> >>>
>> >>> Yeap
>> >>> on it.
>> >>>
>> >>> On 30 April 2015 at 15:43, Sebastien Blanc <scm.blanc at gmail.com>
>> wrote:
>> >>>>
>> >>>> Hi,
>> >>>>
>> >>>> The Advanced Analytics task[1] has a new PR[2] that has been rebased
>> on
>> >>>> the latest master and got a lot of polishing.
>> >>>>
>> >>>> Could the Client Tech Leads take a look at it [3] and review ? The
>> only
>> >>>> "breaking" change is the rename of the header's name that identifies
>> a Push
>> >>>> Notification, it's called now "aerogear-push-id"
>> >>>>
>> >>>> Seb
>> >>>>
>> >>>>
>> >>>>
>> >>>> [1] https://issues.jboss.org/browse/AGPUSH-971
>> >>>> [2] https://github.com/aerogear/aerogear-unifiedpush-server/pull/540
>> >>>> [3] Subtasks of https://issues.jboss.org/browse/AGPUSH-971
>> >>>>
>> >>>>
>> >>>>
>> >>>> _______________________________________________
>> >>>> aerogear-dev mailing list
>> >>>> aerogear-dev at lists.jboss.org
>> >>>> https://lists.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
>>
>>
>>
>> --
>> Cheers,
>>        Erik Jan
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.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/20150505/152c7ba4/attachment-0001.html 

From matzew at apache.org  Tue May  5 05:17:37 2015
From: matzew at apache.org (Matthias Wessendorf)
Date: Tue, 5 May 2015 11:17:37 +0200
Subject: [aerogear-dev] Advanced Analtyics,
 new PR and call to the client tech leads
In-Reply-To: <CAKVvow-8uNu4OuivKkLOURMc1b-Jf=hQUqecwEKY7h=-Hh1diA@mail.gmail.com>
References: <CAD_dpu2LPTTYefjbpqt4TF2jUwhxmNzg2zpqcTDh7tPcjKtGQA@mail.gmail.com>
	<CAL8vO=f49cuKORAahQhE45DEANBLTcn4x_+yMjBxbfMfpSkTTg@mail.gmail.com>
	<CAL8vO=eLktLpMMdU=5tgu4U5uoKHmRFNjZY2O4VOb1tmFLwY3Q@mail.gmail.com>
	<C36F5B92-74F3-4A2B-BAF5-6A50018ECC1D@gmail.com>
	<CAL8vO=c-22FWacpRzqjR+y2fobAXUNqsM5HhnFY_gHR-h8_8Sw@mail.gmail.com>
	<CAO2B-faqA+WKx1CfikVpaERGiS3HJQAeB+mbVQTb9GQfg2mHKA@mail.gmail.com>
	<CAL8vO=e=C_VZNaYpkAacTfDW44cpVrs=ydX0vmmfY5HQYCw4uA@mail.gmail.com>
	<CAKVvow-8uNu4OuivKkLOURMc1b-Jf=hQUqecwEKY7h=-Hh1diA@mail.gmail.com>
Message-ID: <CAAg5f2TpgrA-S0OO9asUL6noXtrurKuVUC7iGvXQu468Gm1SBg@mail.gmail.com>

On Tue, May 5, 2015 at 11:09 AM, Christos Vasilakis <cvasilak at gmail.com>
wrote:

>
>
> On Tue, May 5, 2015 at 11:53 AM, Corinne Krych <corinnekrych at gmail.com>
> wrote:
>
>> To give a bit of background on this background to foreground issue :))
>>
>> Push Cordova plugin matches Cordova life cycle by storing some
>> information locally see:
>>
>> https://github.com/aerogear/aerogear-cordova-push/blob/master/src/ios/AGPushPlugin.m#L82
>> Doing so allows you to call multiple time registration, even when an app
>> comes back from background to foreground. you can do it because you have
>> stored locally all the information neede for registration.
>>
>> But when dealing directly with native apps, the life cycle does not
>> always goes through a registration.
>>
>> To sort out this issue,we can:
>> - either store locally at the ios-push lib level instead of doing it in
>> Cordova plugin and then call registration API on all delegate methods (even
>> though we don't want to register but just send the metrics)
>> - or leave the ios-push lib without any storage and provide a separate
>> endpoint for sending metrics or changing categories.
>>
>> I'd go for the second option.
>>
>> second option makes sense +1
>

+1 on separate endpoint for metrics collection

regarding changing categories: Do you mean a new method on the client SDK,
performing a PUT, containing the new categories for the device token, to
the existing endpoint (but using PUT),  instead of getting a
/updateInstallation endpoint?



>
> -
> Christos
>
>>
>>
>> On 5 May 2015 at 10:39, Erik Jan de Wit <edewit at redhat.com> wrote:
>>
>>> I agree with this and maybe we want even more functionality moved,
>>> because also updating the categories is strange in a 'register'
>>> method. Say for instance you want to change the categories your
>>> interested in a developer has to call register again? And if I
>>> understand Corinnes mail that will currently not even work on iOS.
>>>
>>> For cordova I store the device info, because the lifecycle is
>>> different, but that is okay it's an integration problem.
>>>
>>> So updating the installation details should be a separate method that
>>> also contains updating the categories. That way we have a better split
>>> between a device that registers itself with UPS and updating the
>>> subscription data.
>>>
>>>
>>> On Tue, May 5, 2015 at 9:26 AM, Corinne Krych <corinnekrych at gmail.com>
>>> wrote:
>>> > Hello Sebi,
>>> >
>>> >
>>> > I've done an initial work on aerogear-ios-push [swift branch], adding
>>> a new
>>> > parameter when doing the registration to pass the ag-push-id. See:
>>> >
>>> >
>>> https://github.com/aerogear/aerogear-ios-push/compare/aerogear:master...corinnekrych:AGPUSH-1232.analytics.push.notification?expand=1
>>> >
>>> > This client could be tested with HelloWorld. See:
>>> >
>>> >
>>> https://github.com/jboss-mobile/unified-push-helloworld/compare/jboss-mobile:swift...corinnekrych:AGPUSH-1232.analytics.push.notification?expand=1
>>> >
>>> > What is not covered is the background app coming to foreground through
>>> a
>>> > push notification. If you look at HelloWorld:
>>> >
>>> >
>>> https://github.com/jboss-mobile/unified-push-helloworld/blob/f7d0a7e093327f9a84041910c4c2892280c88ffb/ios-swift/HelloWorldSwift/AppDelegate.swift#L152
>>> >
>>> > In iOS, when we go from background to foreground we don't go through
>>> > registration API. The iOS push lib doesn't store locally (as opposed to
>>> > windows sdk for ex) the device information. So i can't really make
>>> another
>>> > call to registration API. What i'd suggest is to have a separate
>>> endpoint
>>> > for metrics instead of having it coupled with registration endpoint.
>>> wdyt?
>>> >
>>> > ++
>>> >
>>> > Corinne
>>> >
>>> > On 4 May 2015 at 19:07, S?bastien Blanc <scm.blanc at gmail.com> wrote:
>>> >>
>>> >> Hi Corinne !
>>> >> We want to collect for both situations you described :)
>>> >>
>>> >> Envoy? de mon iPhone
>>> >>
>>> >> Le 4 mai 2015 ? 17:53, Corinne Krych <corinnekrych at gmail.com> a
>>> ?crit :
>>> >>
>>> >> Hello Sebi,
>>> >>
>>> >> After giving it a closer look, I've got a question for you: do we
>>> want to
>>> >> collect metrics only when an app is opened via push notification or
>>> do we
>>> >> also want to collect metrics when an app is brought to foreground by
>>> a push
>>> >> notification?
>>> >>
>>> >> ++
>>> >> Corinne
>>> >>
>>> >>
>>> >> On 4 May 2015 at 10:21, Corinne Krych <corinnekrych at gmail.com> wrote:
>>> >>>
>>> >>> Yeap
>>> >>> on it.
>>> >>>
>>> >>> On 30 April 2015 at 15:43, Sebastien Blanc <scm.blanc at gmail.com>
>>> wrote:
>>> >>>>
>>> >>>> Hi,
>>> >>>>
>>> >>>> The Advanced Analytics task[1] has a new PR[2] that has been
>>> rebased on
>>> >>>> the latest master and got a lot of polishing.
>>> >>>>
>>> >>>> Could the Client Tech Leads take a look at it [3] and review ? The
>>> only
>>> >>>> "breaking" change is the rename of the header's name that
>>> identifies a Push
>>> >>>> Notification, it's called now "aerogear-push-id"
>>> >>>>
>>> >>>> Seb
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> [1] https://issues.jboss.org/browse/AGPUSH-971
>>> >>>> [2]
>>> https://github.com/aerogear/aerogear-unifiedpush-server/pull/540
>>> >>>> [3] Subtasks of https://issues.jboss.org/browse/AGPUSH-971
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> _______________________________________________
>>> >>>> aerogear-dev mailing list
>>> >>>> aerogear-dev at lists.jboss.org
>>> >>>> https://lists.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
>>>
>>>
>>>
>>> --
>>> Cheers,
>>>        Erik Jan
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev at lists.jboss.org
>>> https://lists.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/20150505/a6430b63/attachment.html 

From corinnekrych at gmail.com  Tue May  5 05:21:34 2015
From: corinnekrych at gmail.com (Corinne Krych)
Date: Tue, 5 May 2015 11:21:34 +0200
Subject: [aerogear-dev] Advanced Analtyics,
 new PR and call to the client tech leads
In-Reply-To: <CAAg5f2TpgrA-S0OO9asUL6noXtrurKuVUC7iGvXQu468Gm1SBg@mail.gmail.com>
References: <CAD_dpu2LPTTYefjbpqt4TF2jUwhxmNzg2zpqcTDh7tPcjKtGQA@mail.gmail.com>
	<CAL8vO=f49cuKORAahQhE45DEANBLTcn4x_+yMjBxbfMfpSkTTg@mail.gmail.com>
	<CAL8vO=eLktLpMMdU=5tgu4U5uoKHmRFNjZY2O4VOb1tmFLwY3Q@mail.gmail.com>
	<C36F5B92-74F3-4A2B-BAF5-6A50018ECC1D@gmail.com>
	<CAL8vO=c-22FWacpRzqjR+y2fobAXUNqsM5HhnFY_gHR-h8_8Sw@mail.gmail.com>
	<CAO2B-faqA+WKx1CfikVpaERGiS3HJQAeB+mbVQTb9GQfg2mHKA@mail.gmail.com>
	<CAL8vO=e=C_VZNaYpkAacTfDW44cpVrs=ydX0vmmfY5HQYCw4uA@mail.gmail.com>
	<CAKVvow-8uNu4OuivKkLOURMc1b-Jf=hQUqecwEKY7h=-Hh1diA@mail.gmail.com>
	<CAAg5f2TpgrA-S0OO9asUL6noXtrurKuVUC7iGvXQu468Gm1SBg@mail.gmail.com>
Message-ID: <CAL8vO=ffMpEpc+m=VO1U1KNEWORJarPBy61q_n6U6CAx86Mt_Q@mail.gmail.com>

yeap, a new client API performing a PUt will do well

On 5 May 2015 at 11:17, Matthias Wessendorf <matzew at apache.org> wrote:

>
>
> On Tue, May 5, 2015 at 11:09 AM, Christos Vasilakis <cvasilak at gmail.com>
> wrote:
>
>>
>>
>> On Tue, May 5, 2015 at 11:53 AM, Corinne Krych <corinnekrych at gmail.com>
>> wrote:
>>
>>> To give a bit of background on this background to foreground issue :))
>>>
>>> Push Cordova plugin matches Cordova life cycle by storing some
>>> information locally see:
>>>
>>> https://github.com/aerogear/aerogear-cordova-push/blob/master/src/ios/AGPushPlugin.m#L82
>>> Doing so allows you to call multiple time registration, even when an app
>>> comes back from background to foreground. you can do it because you have
>>> stored locally all the information neede for registration.
>>>
>>> But when dealing directly with native apps, the life cycle does not
>>> always goes through a registration.
>>>
>>> To sort out this issue,we can:
>>> - either store locally at the ios-push lib level instead of doing it in
>>> Cordova plugin and then call registration API on all delegate methods (even
>>> though we don't want to register but just send the metrics)
>>> - or leave the ios-push lib without any storage and provide a separate
>>> endpoint for sending metrics or changing categories.
>>>
>>> I'd go for the second option.
>>>
>>> second option makes sense +1
>>
>
> +1 on separate endpoint for metrics collection
>
> regarding changing categories: Do you mean a new method on the client SDK,
> performing a PUT, containing the new categories for the device token, to
> the existing endpoint (but using PUT),  instead of getting a
> /updateInstallation endpoint?
>
>
>
>>
>> -
>> Christos
>>
>>>
>>>
>>> On 5 May 2015 at 10:39, Erik Jan de Wit <edewit at redhat.com> wrote:
>>>
>>>> I agree with this and maybe we want even more functionality moved,
>>>> because also updating the categories is strange in a 'register'
>>>> method. Say for instance you want to change the categories your
>>>> interested in a developer has to call register again? And if I
>>>> understand Corinnes mail that will currently not even work on iOS.
>>>>
>>>> For cordova I store the device info, because the lifecycle is
>>>> different, but that is okay it's an integration problem.
>>>>
>>>> So updating the installation details should be a separate method that
>>>> also contains updating the categories. That way we have a better split
>>>> between a device that registers itself with UPS and updating the
>>>> subscription data.
>>>>
>>>>
>>>> On Tue, May 5, 2015 at 9:26 AM, Corinne Krych <corinnekrych at gmail.com>
>>>> wrote:
>>>> > Hello Sebi,
>>>> >
>>>> >
>>>> > I've done an initial work on aerogear-ios-push [swift branch], adding
>>>> a new
>>>> > parameter when doing the registration to pass the ag-push-id. See:
>>>> >
>>>> >
>>>> https://github.com/aerogear/aerogear-ios-push/compare/aerogear:master...corinnekrych:AGPUSH-1232.analytics.push.notification?expand=1
>>>> >
>>>> > This client could be tested with HelloWorld. See:
>>>> >
>>>> >
>>>> https://github.com/jboss-mobile/unified-push-helloworld/compare/jboss-mobile:swift...corinnekrych:AGPUSH-1232.analytics.push.notification?expand=1
>>>> >
>>>> > What is not covered is the background app coming to foreground
>>>> through a
>>>> > push notification. If you look at HelloWorld:
>>>> >
>>>> >
>>>> https://github.com/jboss-mobile/unified-push-helloworld/blob/f7d0a7e093327f9a84041910c4c2892280c88ffb/ios-swift/HelloWorldSwift/AppDelegate.swift#L152
>>>> >
>>>> > In iOS, when we go from background to foreground we don't go through
>>>> > registration API. The iOS push lib doesn't store locally (as opposed
>>>> to
>>>> > windows sdk for ex) the device information. So i can't really make
>>>> another
>>>> > call to registration API. What i'd suggest is to have a separate
>>>> endpoint
>>>> > for metrics instead of having it coupled with registration endpoint.
>>>> wdyt?
>>>> >
>>>> > ++
>>>> >
>>>> > Corinne
>>>> >
>>>> > On 4 May 2015 at 19:07, S?bastien Blanc <scm.blanc at gmail.com> wrote:
>>>> >>
>>>> >> Hi Corinne !
>>>> >> We want to collect for both situations you described :)
>>>> >>
>>>> >> Envoy? de mon iPhone
>>>> >>
>>>> >> Le 4 mai 2015 ? 17:53, Corinne Krych <corinnekrych at gmail.com> a
>>>> ?crit :
>>>> >>
>>>> >> Hello Sebi,
>>>> >>
>>>> >> After giving it a closer look, I've got a question for you: do we
>>>> want to
>>>> >> collect metrics only when an app is opened via push notification or
>>>> do we
>>>> >> also want to collect metrics when an app is brought to foreground by
>>>> a push
>>>> >> notification?
>>>> >>
>>>> >> ++
>>>> >> Corinne
>>>> >>
>>>> >>
>>>> >> On 4 May 2015 at 10:21, Corinne Krych <corinnekrych at gmail.com>
>>>> wrote:
>>>> >>>
>>>> >>> Yeap
>>>> >>> on it.
>>>> >>>
>>>> >>> On 30 April 2015 at 15:43, Sebastien Blanc <scm.blanc at gmail.com>
>>>> wrote:
>>>> >>>>
>>>> >>>> Hi,
>>>> >>>>
>>>> >>>> The Advanced Analytics task[1] has a new PR[2] that has been
>>>> rebased on
>>>> >>>> the latest master and got a lot of polishing.
>>>> >>>>
>>>> >>>> Could the Client Tech Leads take a look at it [3] and review ? The
>>>> only
>>>> >>>> "breaking" change is the rename of the header's name that
>>>> identifies a Push
>>>> >>>> Notification, it's called now "aerogear-push-id"
>>>> >>>>
>>>> >>>> Seb
>>>> >>>>
>>>> >>>>
>>>> >>>>
>>>> >>>> [1] https://issues.jboss.org/browse/AGPUSH-971
>>>> >>>> [2]
>>>> https://github.com/aerogear/aerogear-unifiedpush-server/pull/540
>>>> >>>> [3] Subtasks of https://issues.jboss.org/browse/AGPUSH-971
>>>> >>>>
>>>> >>>>
>>>> >>>>
>>>> >>>> _______________________________________________
>>>> >>>> aerogear-dev mailing list
>>>> >>>> aerogear-dev at lists.jboss.org
>>>> >>>> https://lists.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
>>>>
>>>>
>>>>
>>>> --
>>>> Cheers,
>>>>        Erik Jan
>>>>
>>>> _______________________________________________
>>>> aerogear-dev mailing list
>>>> aerogear-dev at lists.jboss.org
>>>> https://lists.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/20150505/54efb6fc/attachment-0001.html 

From dpassos at redhat.com  Tue May  5 10:48:09 2015
From: dpassos at redhat.com (Daniel Passos)
Date: Tue, 5 May 2015 11:48:09 -0300
Subject: [aerogear-dev] Advanced Analtyics,
 new PR and call to the client tech leads
In-Reply-To: <CAL8vO=ffMpEpc+m=VO1U1KNEWORJarPBy61q_n6U6CAx86Mt_Q@mail.gmail.com>
References: <CAD_dpu2LPTTYefjbpqt4TF2jUwhxmNzg2zpqcTDh7tPcjKtGQA@mail.gmail.com>
	<CAL8vO=f49cuKORAahQhE45DEANBLTcn4x_+yMjBxbfMfpSkTTg@mail.gmail.com>
	<CAL8vO=eLktLpMMdU=5tgu4U5uoKHmRFNjZY2O4VOb1tmFLwY3Q@mail.gmail.com>
	<C36F5B92-74F3-4A2B-BAF5-6A50018ECC1D@gmail.com>
	<CAL8vO=c-22FWacpRzqjR+y2fobAXUNqsM5HhnFY_gHR-h8_8Sw@mail.gmail.com>
	<CAO2B-faqA+WKx1CfikVpaERGiS3HJQAeB+mbVQTb9GQfg2mHKA@mail.gmail.com>
	<CAL8vO=e=C_VZNaYpkAacTfDW44cpVrs=ydX0vmmfY5HQYCw4uA@mail.gmail.com>
	<CAKVvow-8uNu4OuivKkLOURMc1b-Jf=hQUqecwEKY7h=-Hh1diA@mail.gmail.com>
	<CAAg5f2TpgrA-S0OO9asUL6noXtrurKuVUC7iGvXQu468Gm1SBg@mail.gmail.com>
	<CAL8vO=ffMpEpc+m=VO1U1KNEWORJarPBy61q_n6U6CAx86Mt_Q@mail.gmail.com>
Message-ID: <CADF=h2sA5_NUt=ggx56SwN5uhFGCBbBNY2+ZqQSubuH8-9S2-w@mail.gmail.com>

+1 to add PUT to update device token infos

On Tue, May 5, 2015 at 6:21 AM, Corinne Krych <corinnekrych at gmail.com>
wrote:

> yeap, a new client API performing a PUt will do well
>
> On 5 May 2015 at 11:17, Matthias Wessendorf <matzew at apache.org> wrote:
>
>>
>>
>> On Tue, May 5, 2015 at 11:09 AM, Christos Vasilakis <cvasilak at gmail.com>
>> wrote:
>>
>>>
>>>
>>> On Tue, May 5, 2015 at 11:53 AM, Corinne Krych <corinnekrych at gmail.com>
>>> wrote:
>>>
>>>> To give a bit of background on this background to foreground issue :))
>>>>
>>>> Push Cordova plugin matches Cordova life cycle by storing some
>>>> information locally see:
>>>>
>>>> https://github.com/aerogear/aerogear-cordova-push/blob/master/src/ios/AGPushPlugin.m#L82
>>>> Doing so allows you to call multiple time registration, even when an
>>>> app comes back from background to foreground. you can do it because you
>>>> have stored locally all the information neede for registration.
>>>>
>>>> But when dealing directly with native apps, the life cycle does not
>>>> always goes through a registration.
>>>>
>>>> To sort out this issue,we can:
>>>> - either store locally at the ios-push lib level instead of doing it in
>>>> Cordova plugin and then call registration API on all delegate methods (even
>>>> though we don't want to register but just send the metrics)
>>>> - or leave the ios-push lib without any storage and provide a separate
>>>> endpoint for sending metrics or changing categories.
>>>>
>>>> I'd go for the second option.
>>>>
>>>> second option makes sense +1
>>>
>>
>> +1 on separate endpoint for metrics collection
>>
>> regarding changing categories: Do you mean a new method on the client
>> SDK, performing a PUT, containing the new categories for the device token,
>> to the existing endpoint (but using PUT),  instead of getting a
>> /updateInstallation endpoint?
>>
>>
>>
>>>
>>> -
>>> Christos
>>>
>>>>
>>>>
>>>> On 5 May 2015 at 10:39, Erik Jan de Wit <edewit at redhat.com> wrote:
>>>>
>>>>> I agree with this and maybe we want even more functionality moved,
>>>>> because also updating the categories is strange in a 'register'
>>>>> method. Say for instance you want to change the categories your
>>>>> interested in a developer has to call register again? And if I
>>>>> understand Corinnes mail that will currently not even work on iOS.
>>>>>
>>>>> For cordova I store the device info, because the lifecycle is
>>>>> different, but that is okay it's an integration problem.
>>>>>
>>>>> So updating the installation details should be a separate method that
>>>>> also contains updating the categories. That way we have a better split
>>>>> between a device that registers itself with UPS and updating the
>>>>> subscription data.
>>>>>
>>>>>
>>>>> On Tue, May 5, 2015 at 9:26 AM, Corinne Krych <corinnekrych at gmail.com>
>>>>> wrote:
>>>>> > Hello Sebi,
>>>>> >
>>>>> >
>>>>> > I've done an initial work on aerogear-ios-push [swift branch],
>>>>> adding a new
>>>>> > parameter when doing the registration to pass the ag-push-id. See:
>>>>> >
>>>>> >
>>>>> https://github.com/aerogear/aerogear-ios-push/compare/aerogear:master...corinnekrych:AGPUSH-1232.analytics.push.notification?expand=1
>>>>> >
>>>>> > This client could be tested with HelloWorld. See:
>>>>> >
>>>>> >
>>>>> https://github.com/jboss-mobile/unified-push-helloworld/compare/jboss-mobile:swift...corinnekrych:AGPUSH-1232.analytics.push.notification?expand=1
>>>>> >
>>>>> > What is not covered is the background app coming to foreground
>>>>> through a
>>>>> > push notification. If you look at HelloWorld:
>>>>> >
>>>>> >
>>>>> https://github.com/jboss-mobile/unified-push-helloworld/blob/f7d0a7e093327f9a84041910c4c2892280c88ffb/ios-swift/HelloWorldSwift/AppDelegate.swift#L152
>>>>> >
>>>>> > In iOS, when we go from background to foreground we don't go through
>>>>> > registration API. The iOS push lib doesn't store locally (as opposed
>>>>> to
>>>>> > windows sdk for ex) the device information. So i can't really make
>>>>> another
>>>>> > call to registration API. What i'd suggest is to have a separate
>>>>> endpoint
>>>>> > for metrics instead of having it coupled with registration endpoint.
>>>>> wdyt?
>>>>> >
>>>>> > ++
>>>>> >
>>>>> > Corinne
>>>>> >
>>>>> > On 4 May 2015 at 19:07, S?bastien Blanc <scm.blanc at gmail.com> wrote:
>>>>> >>
>>>>> >> Hi Corinne !
>>>>> >> We want to collect for both situations you described :)
>>>>> >>
>>>>> >> Envoy? de mon iPhone
>>>>> >>
>>>>> >> Le 4 mai 2015 ? 17:53, Corinne Krych <corinnekrych at gmail.com> a
>>>>> ?crit :
>>>>> >>
>>>>> >> Hello Sebi,
>>>>> >>
>>>>> >> After giving it a closer look, I've got a question for you: do we
>>>>> want to
>>>>> >> collect metrics only when an app is opened via push notification or
>>>>> do we
>>>>> >> also want to collect metrics when an app is brought to foreground
>>>>> by a push
>>>>> >> notification?
>>>>> >>
>>>>> >> ++
>>>>> >> Corinne
>>>>> >>
>>>>> >>
>>>>> >> On 4 May 2015 at 10:21, Corinne Krych <corinnekrych at gmail.com>
>>>>> wrote:
>>>>> >>>
>>>>> >>> Yeap
>>>>> >>> on it.
>>>>> >>>
>>>>> >>> On 30 April 2015 at 15:43, Sebastien Blanc <scm.blanc at gmail.com>
>>>>> wrote:
>>>>> >>>>
>>>>> >>>> Hi,
>>>>> >>>>
>>>>> >>>> The Advanced Analytics task[1] has a new PR[2] that has been
>>>>> rebased on
>>>>> >>>> the latest master and got a lot of polishing.
>>>>> >>>>
>>>>> >>>> Could the Client Tech Leads take a look at it [3] and review ?
>>>>> The only
>>>>> >>>> "breaking" change is the rename of the header's name that
>>>>> identifies a Push
>>>>> >>>> Notification, it's called now "aerogear-push-id"
>>>>> >>>>
>>>>> >>>> Seb
>>>>> >>>>
>>>>> >>>>
>>>>> >>>>
>>>>> >>>> [1] https://issues.jboss.org/browse/AGPUSH-971
>>>>> >>>> [2]
>>>>> https://github.com/aerogear/aerogear-unifiedpush-server/pull/540
>>>>> >>>> [3] Subtasks of https://issues.jboss.org/browse/AGPUSH-971
>>>>> >>>>
>>>>> >>>>
>>>>> >>>>
>>>>> >>>> _______________________________________________
>>>>> >>>> aerogear-dev mailing list
>>>>> >>>> aerogear-dev at lists.jboss.org
>>>>> >>>> https://lists.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
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Cheers,
>>>>>        Erik Jan
>>>>>
>>>>> _______________________________________________
>>>>> aerogear-dev mailing list
>>>>> aerogear-dev at lists.jboss.org
>>>>> https://lists.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
>



-- 
-- Passos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20150505/12bbd20d/attachment.html 

From supittma at redhat.com  Tue May  5 11:49:39 2015
From: supittma at redhat.com (Summers Pittman)
Date: Tue, 5 May 2015 11:49:39 -0400
Subject: [aerogear-dev] Advanced Analtyics,
 new PR and call to the client tech leads
In-Reply-To: <CAL8vO=e=C_VZNaYpkAacTfDW44cpVrs=ydX0vmmfY5HQYCw4uA@mail.gmail.com>
References: <CAD_dpu2LPTTYefjbpqt4TF2jUwhxmNzg2zpqcTDh7tPcjKtGQA@mail.gmail.com>
	<CAL8vO=f49cuKORAahQhE45DEANBLTcn4x_+yMjBxbfMfpSkTTg@mail.gmail.com>
	<CAL8vO=eLktLpMMdU=5tgu4U5uoKHmRFNjZY2O4VOb1tmFLwY3Q@mail.gmail.com>
	<C36F5B92-74F3-4A2B-BAF5-6A50018ECC1D@gmail.com>
	<CAL8vO=c-22FWacpRzqjR+y2fobAXUNqsM5HhnFY_gHR-h8_8Sw@mail.gmail.com>
	<CAO2B-faqA+WKx1CfikVpaERGiS3HJQAeB+mbVQTb9GQfg2mHKA@mail.gmail.com>
	<CAL8vO=e=C_VZNaYpkAacTfDW44cpVrs=ydX0vmmfY5HQYCw4uA@mail.gmail.com>
Message-ID: <CAEQz2CuGyh1wVviuVZ7sZx+d9J85sAPLKN+u+TOVvrU_xGXQ9g@mail.gmail.com>

On Tue, May 5, 2015 at 4:53 AM, Corinne Krych <corinnekrych at gmail.com>
wrote:

> To give a bit of background on this background to foreground issue :))
>
> Push Cordova plugin matches Cordova life cycle by storing some information
> locally see:
>
> https://github.com/aerogear/aerogear-cordova-push/blob/master/src/ios/AGPushPlugin.m#L82
> Doing so allows you to call multiple time registration, even when an app
> comes back from background to foreground. you can do it because you have
> stored locally all the information neede for registration.
>
> But when dealing directly with native apps, the life cycle does not always
> goes through a registration.
>
> To sort out this issue,we can:
> - either store locally at the ios-push lib level instead of doing it in
> Cordova plugin and then call registration API on all delegate methods (even
> though we don't want to register but just send the metrics)
> - or leave the ios-push lib without any storage and provide a separate
> endpoint for sending metrics or changing categories.
>
> I'd go for the second option.
>
I'd actually go for the first option.  This would bring the iOS libs in
line with what Cordova and Android already do.

>
> ++
> Corinne
>
>
> On 5 May 2015 at 10:39, Erik Jan de Wit <edewit at redhat.com> wrote:
>
>> I agree with this and maybe we want even more functionality moved,
>> because also updating the categories is strange in a 'register'
>> method. Say for instance you want to change the categories your
>> interested in a developer has to call register again? And if I
>> understand Corinnes mail that will currently not even work on iOS.
>>
>> For cordova I store the device info, because the lifecycle is
>> different, but that is okay it's an integration problem.
>>
>> So updating the installation details should be a separate method that
>> also contains updating the categories. That way we have a better split
>> between a device that registers itself with UPS and updating the
>> subscription data.
>>
>>
>> On Tue, May 5, 2015 at 9:26 AM, Corinne Krych <corinnekrych at gmail.com>
>> wrote:
>> > Hello Sebi,
>> >
>> >
>> > I've done an initial work on aerogear-ios-push [swift branch], adding a
>> new
>> > parameter when doing the registration to pass the ag-push-id. See:
>> >
>> >
>> https://github.com/aerogear/aerogear-ios-push/compare/aerogear:master...corinnekrych:AGPUSH-1232.analytics.push.notification?expand=1
>> >
>> > This client could be tested with HelloWorld. See:
>> >
>> >
>> https://github.com/jboss-mobile/unified-push-helloworld/compare/jboss-mobile:swift...corinnekrych:AGPUSH-1232.analytics.push.notification?expand=1
>> >
>> > What is not covered is the background app coming to foreground through a
>> > push notification. If you look at HelloWorld:
>> >
>> >
>> https://github.com/jboss-mobile/unified-push-helloworld/blob/f7d0a7e093327f9a84041910c4c2892280c88ffb/ios-swift/HelloWorldSwift/AppDelegate.swift#L152
>> >
>> > In iOS, when we go from background to foreground we don't go through
>> > registration API. The iOS push lib doesn't store locally (as opposed to
>> > windows sdk for ex) the device information. So i can't really make
>> another
>> > call to registration API. What i'd suggest is to have a separate
>> endpoint
>> > for metrics instead of having it coupled with registration endpoint.
>> wdyt?
>> >
>> > ++
>> >
>> > Corinne
>> >
>> > On 4 May 2015 at 19:07, S?bastien Blanc <scm.blanc at gmail.com> wrote:
>> >>
>> >> Hi Corinne !
>> >> We want to collect for both situations you described :)
>> >>
>> >> Envoy? de mon iPhone
>> >>
>> >> Le 4 mai 2015 ? 17:53, Corinne Krych <corinnekrych at gmail.com> a ?crit
>> :
>> >>
>> >> Hello Sebi,
>> >>
>> >> After giving it a closer look, I've got a question for you: do we want
>> to
>> >> collect metrics only when an app is opened via push notification or do
>> we
>> >> also want to collect metrics when an app is brought to foreground by a
>> push
>> >> notification?
>> >>
>> >> ++
>> >> Corinne
>> >>
>> >>
>> >> On 4 May 2015 at 10:21, Corinne Krych <corinnekrych at gmail.com> wrote:
>> >>>
>> >>> Yeap
>> >>> on it.
>> >>>
>> >>> On 30 April 2015 at 15:43, Sebastien Blanc <scm.blanc at gmail.com>
>> wrote:
>> >>>>
>> >>>> Hi,
>> >>>>
>> >>>> The Advanced Analytics task[1] has a new PR[2] that has been rebased
>> on
>> >>>> the latest master and got a lot of polishing.
>> >>>>
>> >>>> Could the Client Tech Leads take a look at it [3] and review ? The
>> only
>> >>>> "breaking" change is the rename of the header's name that identifies
>> a Push
>> >>>> Notification, it's called now "aerogear-push-id"
>> >>>>
>> >>>> Seb
>> >>>>
>> >>>>
>> >>>>
>> >>>> [1] https://issues.jboss.org/browse/AGPUSH-971
>> >>>> [2] https://github.com/aerogear/aerogear-unifiedpush-server/pull/540
>> >>>> [3] Subtasks of https://issues.jboss.org/browse/AGPUSH-971
>> >>>>
>> >>>>
>> >>>>
>> >>>> _______________________________________________
>> >>>> aerogear-dev mailing list
>> >>>> aerogear-dev at lists.jboss.org
>> >>>> https://lists.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
>>
>>
>>
>> --
>> Cheers,
>>        Erik Jan
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.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/20150505/c5721f8e/attachment-0001.html 

From supittma at redhat.com  Tue May  5 11:51:23 2015
From: supittma at redhat.com (Summers Pittman)
Date: Tue, 5 May 2015 11:51:23 -0400
Subject: [aerogear-dev] Advanced Analtyics,
 new PR and call to the client tech leads
In-Reply-To: <CAAg5f2TpgrA-S0OO9asUL6noXtrurKuVUC7iGvXQu468Gm1SBg@mail.gmail.com>
References: <CAD_dpu2LPTTYefjbpqt4TF2jUwhxmNzg2zpqcTDh7tPcjKtGQA@mail.gmail.com>
	<CAL8vO=f49cuKORAahQhE45DEANBLTcn4x_+yMjBxbfMfpSkTTg@mail.gmail.com>
	<CAL8vO=eLktLpMMdU=5tgu4U5uoKHmRFNjZY2O4VOb1tmFLwY3Q@mail.gmail.com>
	<C36F5B92-74F3-4A2B-BAF5-6A50018ECC1D@gmail.com>
	<CAL8vO=c-22FWacpRzqjR+y2fobAXUNqsM5HhnFY_gHR-h8_8Sw@mail.gmail.com>
	<CAO2B-faqA+WKx1CfikVpaERGiS3HJQAeB+mbVQTb9GQfg2mHKA@mail.gmail.com>
	<CAL8vO=e=C_VZNaYpkAacTfDW44cpVrs=ydX0vmmfY5HQYCw4uA@mail.gmail.com>
	<CAKVvow-8uNu4OuivKkLOURMc1b-Jf=hQUqecwEKY7h=-Hh1diA@mail.gmail.com>
	<CAAg5f2TpgrA-S0OO9asUL6noXtrurKuVUC7iGvXQu468Gm1SBg@mail.gmail.com>
Message-ID: <CAEQz2CvmqBZtTpeCROfeYS5yPn1b3ZafRjn0=h3=ePEBjZDDVA@mail.gmail.com>

On Tue, May 5, 2015 at 5:17 AM, Matthias Wessendorf <matzew at apache.org>
wrote:

>
>
> On Tue, May 5, 2015 at 11:09 AM, Christos Vasilakis <cvasilak at gmail.com>
> wrote:
>
>>
>>
>> On Tue, May 5, 2015 at 11:53 AM, Corinne Krych <corinnekrych at gmail.com>
>> wrote:
>>
>>> To give a bit of background on this background to foreground issue :))
>>>
>>> Push Cordova plugin matches Cordova life cycle by storing some
>>> information locally see:
>>>
>>> https://github.com/aerogear/aerogear-cordova-push/blob/master/src/ios/AGPushPlugin.m#L82
>>> Doing so allows you to call multiple time registration, even when an app
>>> comes back from background to foreground. you can do it because you have
>>> stored locally all the information neede for registration.
>>>
>>> But when dealing directly with native apps, the life cycle does not
>>> always goes through a registration.
>>>
>>> To sort out this issue,we can:
>>> - either store locally at the ios-push lib level instead of doing it in
>>> Cordova plugin and then call registration API on all delegate methods (even
>>> though we don't want to register but just send the metrics)
>>> - or leave the ios-push lib without any storage and provide a separate
>>> endpoint for sending metrics or changing categories.
>>>
>>> I'd go for the second option.
>>>
>>> second option makes sense +1
>>
>
> +1 on separate endpoint for metrics collection
>
> regarding changing categories: Do you mean a new method on the client SDK,
> performing a PUT, containing the new categories for the device token, to
> the existing endpoint (but using PUT),  instead of getting a
> /updateInstallation endpoint?
>

Adding a separate method on Android seems kind of weird. Android is rather
spammy (intentionally and by design and according to big papa G's best
practices) with the registration call.  Basically best practice on Android
is call registration every time the application is opened.


>
>
>>
>> -
>> Christos
>>
>>>
>>>
>>> On 5 May 2015 at 10:39, Erik Jan de Wit <edewit at redhat.com> wrote:
>>>
>>>> I agree with this and maybe we want even more functionality moved,
>>>> because also updating the categories is strange in a 'register'
>>>> method. Say for instance you want to change the categories your
>>>> interested in a developer has to call register again? And if I
>>>> understand Corinnes mail that will currently not even work on iOS.
>>>>
>>>> For cordova I store the device info, because the lifecycle is
>>>> different, but that is okay it's an integration problem.
>>>>
>>>> So updating the installation details should be a separate method that
>>>> also contains updating the categories. That way we have a better split
>>>> between a device that registers itself with UPS and updating the
>>>> subscription data.
>>>>
>>>>
>>>> On Tue, May 5, 2015 at 9:26 AM, Corinne Krych <corinnekrych at gmail.com>
>>>> wrote:
>>>> > Hello Sebi,
>>>> >
>>>> >
>>>> > I've done an initial work on aerogear-ios-push [swift branch], adding
>>>> a new
>>>> > parameter when doing the registration to pass the ag-push-id. See:
>>>> >
>>>> >
>>>> https://github.com/aerogear/aerogear-ios-push/compare/aerogear:master...corinnekrych:AGPUSH-1232.analytics.push.notification?expand=1
>>>> >
>>>> > This client could be tested with HelloWorld. See:
>>>> >
>>>> >
>>>> https://github.com/jboss-mobile/unified-push-helloworld/compare/jboss-mobile:swift...corinnekrych:AGPUSH-1232.analytics.push.notification?expand=1
>>>> >
>>>> > What is not covered is the background app coming to foreground
>>>> through a
>>>> > push notification. If you look at HelloWorld:
>>>> >
>>>> >
>>>> https://github.com/jboss-mobile/unified-push-helloworld/blob/f7d0a7e093327f9a84041910c4c2892280c88ffb/ios-swift/HelloWorldSwift/AppDelegate.swift#L152
>>>> >
>>>> > In iOS, when we go from background to foreground we don't go through
>>>> > registration API. The iOS push lib doesn't store locally (as opposed
>>>> to
>>>> > windows sdk for ex) the device information. So i can't really make
>>>> another
>>>> > call to registration API. What i'd suggest is to have a separate
>>>> endpoint
>>>> > for metrics instead of having it coupled with registration endpoint.
>>>> wdyt?
>>>> >
>>>> > ++
>>>> >
>>>> > Corinne
>>>> >
>>>> > On 4 May 2015 at 19:07, S?bastien Blanc <scm.blanc at gmail.com> wrote:
>>>> >>
>>>> >> Hi Corinne !
>>>> >> We want to collect for both situations you described :)
>>>> >>
>>>> >> Envoy? de mon iPhone
>>>> >>
>>>> >> Le 4 mai 2015 ? 17:53, Corinne Krych <corinnekrych at gmail.com> a
>>>> ?crit :
>>>> >>
>>>> >> Hello Sebi,
>>>> >>
>>>> >> After giving it a closer look, I've got a question for you: do we
>>>> want to
>>>> >> collect metrics only when an app is opened via push notification or
>>>> do we
>>>> >> also want to collect metrics when an app is brought to foreground by
>>>> a push
>>>> >> notification?
>>>> >>
>>>> >> ++
>>>> >> Corinne
>>>> >>
>>>> >>
>>>> >> On 4 May 2015 at 10:21, Corinne Krych <corinnekrych at gmail.com>
>>>> wrote:
>>>> >>>
>>>> >>> Yeap
>>>> >>> on it.
>>>> >>>
>>>> >>> On 30 April 2015 at 15:43, Sebastien Blanc <scm.blanc at gmail.com>
>>>> wrote:
>>>> >>>>
>>>> >>>> Hi,
>>>> >>>>
>>>> >>>> The Advanced Analytics task[1] has a new PR[2] that has been
>>>> rebased on
>>>> >>>> the latest master and got a lot of polishing.
>>>> >>>>
>>>> >>>> Could the Client Tech Leads take a look at it [3] and review ? The
>>>> only
>>>> >>>> "breaking" change is the rename of the header's name that
>>>> identifies a Push
>>>> >>>> Notification, it's called now "aerogear-push-id"
>>>> >>>>
>>>> >>>> Seb
>>>> >>>>
>>>> >>>>
>>>> >>>>
>>>> >>>> [1] https://issues.jboss.org/browse/AGPUSH-971
>>>> >>>> [2]
>>>> https://github.com/aerogear/aerogear-unifiedpush-server/pull/540
>>>> >>>> [3] Subtasks of https://issues.jboss.org/browse/AGPUSH-971
>>>> >>>>
>>>> >>>>
>>>> >>>>
>>>> >>>> _______________________________________________
>>>> >>>> aerogear-dev mailing list
>>>> >>>> aerogear-dev at lists.jboss.org
>>>> >>>> https://lists.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
>>>>
>>>>
>>>>
>>>> --
>>>> Cheers,
>>>>        Erik Jan
>>>>
>>>> _______________________________________________
>>>> aerogear-dev mailing list
>>>> aerogear-dev at lists.jboss.org
>>>> https://lists.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/20150505/6cb71cc9/attachment.html 

From matzew at apache.org  Tue May  5 12:08:57 2015
From: matzew at apache.org (Matthias Wessendorf)
Date: Tue, 5 May 2015 18:08:57 +0200
Subject: [aerogear-dev] Advanced Analtyics,
 new PR and call to the client tech leads
In-Reply-To: <CAEQz2CvmqBZtTpeCROfeYS5yPn1b3ZafRjn0=h3=ePEBjZDDVA@mail.gmail.com>
References: <CAD_dpu2LPTTYefjbpqt4TF2jUwhxmNzg2zpqcTDh7tPcjKtGQA@mail.gmail.com>
	<CAL8vO=f49cuKORAahQhE45DEANBLTcn4x_+yMjBxbfMfpSkTTg@mail.gmail.com>
	<CAL8vO=eLktLpMMdU=5tgu4U5uoKHmRFNjZY2O4VOb1tmFLwY3Q@mail.gmail.com>
	<C36F5B92-74F3-4A2B-BAF5-6A50018ECC1D@gmail.com>
	<CAL8vO=c-22FWacpRzqjR+y2fobAXUNqsM5HhnFY_gHR-h8_8Sw@mail.gmail.com>
	<CAO2B-faqA+WKx1CfikVpaERGiS3HJQAeB+mbVQTb9GQfg2mHKA@mail.gmail.com>
	<CAL8vO=e=C_VZNaYpkAacTfDW44cpVrs=ydX0vmmfY5HQYCw4uA@mail.gmail.com>
	<CAKVvow-8uNu4OuivKkLOURMc1b-Jf=hQUqecwEKY7h=-Hh1diA@mail.gmail.com>
	<CAAg5f2TpgrA-S0OO9asUL6noXtrurKuVUC7iGvXQu468Gm1SBg@mail.gmail.com>
	<CAEQz2CvmqBZtTpeCROfeYS5yPn1b3ZafRjn0=h3=ePEBjZDDVA@mail.gmail.com>
Message-ID: <CAAg5f2TapgEVWmScoht9HnH9iMSQp=6JonZAmnPgzG49OMd_eA@mail.gmail.com>

On Tue, May 5, 2015 at 5:51 PM, Summers Pittman <supittma at redhat.com> wrote:

>
>
> On Tue, May 5, 2015 at 5:17 AM, Matthias Wessendorf <matzew at apache.org>
> wrote:
>
>>
>>
>> On Tue, May 5, 2015 at 11:09 AM, Christos Vasilakis <cvasilak at gmail.com>
>> wrote:
>>
>>>
>>>
>>> On Tue, May 5, 2015 at 11:53 AM, Corinne Krych <corinnekrych at gmail.com>
>>> wrote:
>>>
>>>> To give a bit of background on this background to foreground issue :))
>>>>
>>>> Push Cordova plugin matches Cordova life cycle by storing some
>>>> information locally see:
>>>>
>>>> https://github.com/aerogear/aerogear-cordova-push/blob/master/src/ios/AGPushPlugin.m#L82
>>>> Doing so allows you to call multiple time registration, even when an
>>>> app comes back from background to foreground. you can do it because you
>>>> have stored locally all the information neede for registration.
>>>>
>>>> But when dealing directly with native apps, the life cycle does not
>>>> always goes through a registration.
>>>>
>>>> To sort out this issue,we can:
>>>> - either store locally at the ios-push lib level instead of doing it in
>>>> Cordova plugin and then call registration API on all delegate methods (even
>>>> though we don't want to register but just send the metrics)
>>>> - or leave the ios-push lib without any storage and provide a separate
>>>> endpoint for sending metrics or changing categories.
>>>>
>>>> I'd go for the second option.
>>>>
>>>> second option makes sense +1
>>>
>>
>> +1 on separate endpoint for metrics collection
>>
>> regarding changing categories: Do you mean a new method on the client
>> SDK, performing a PUT, containing the new categories for the device token,
>> to the existing endpoint (but using PUT),  instead of getting a
>> /updateInstallation endpoint?
>>
>
> Adding a separate method on Android seems kind of weird. Android is rather
> spammy (intentionally and by design and according to big papa G's best
> practices) with the registration call.  Basically best practice on Android
> is call registration every time the application is opened.
>

I see - that relates to your earlier comment, of calling 'register' all the
time on Android/iOS as well - instead of having a update() hook.

I do believe that having an updateDeviceMetadata() (e.g. to update the used
categories, as the end-user is no longer interested in 'rihanna') does make
sense.


What about the metrics endpoint? Instead of sending that through the
registration endpoint? Agree on that or not?

>
>
>>
>>
>>>
>>> -
>>> Christos
>>>
>>>>
>>>>
>>>> On 5 May 2015 at 10:39, Erik Jan de Wit <edewit at redhat.com> wrote:
>>>>
>>>>> I agree with this and maybe we want even more functionality moved,
>>>>> because also updating the categories is strange in a 'register'
>>>>> method. Say for instance you want to change the categories your
>>>>> interested in a developer has to call register again? And if I
>>>>> understand Corinnes mail that will currently not even work on iOS.
>>>>>
>>>>> For cordova I store the device info, because the lifecycle is
>>>>> different, but that is okay it's an integration problem.
>>>>>
>>>>> So updating the installation details should be a separate method that
>>>>> also contains updating the categories. That way we have a better split
>>>>> between a device that registers itself with UPS and updating the
>>>>> subscription data.
>>>>>
>>>>>
>>>>> On Tue, May 5, 2015 at 9:26 AM, Corinne Krych <corinnekrych at gmail.com>
>>>>> wrote:
>>>>> > Hello Sebi,
>>>>> >
>>>>> >
>>>>> > I've done an initial work on aerogear-ios-push [swift branch],
>>>>> adding a new
>>>>> > parameter when doing the registration to pass the ag-push-id. See:
>>>>> >
>>>>> >
>>>>> https://github.com/aerogear/aerogear-ios-push/compare/aerogear:master...corinnekrych:AGPUSH-1232.analytics.push.notification?expand=1
>>>>> >
>>>>> > This client could be tested with HelloWorld. See:
>>>>> >
>>>>> >
>>>>> https://github.com/jboss-mobile/unified-push-helloworld/compare/jboss-mobile:swift...corinnekrych:AGPUSH-1232.analytics.push.notification?expand=1
>>>>> >
>>>>> > What is not covered is the background app coming to foreground
>>>>> through a
>>>>> > push notification. If you look at HelloWorld:
>>>>> >
>>>>> >
>>>>> https://github.com/jboss-mobile/unified-push-helloworld/blob/f7d0a7e093327f9a84041910c4c2892280c88ffb/ios-swift/HelloWorldSwift/AppDelegate.swift#L152
>>>>> >
>>>>> > In iOS, when we go from background to foreground we don't go through
>>>>> > registration API. The iOS push lib doesn't store locally (as opposed
>>>>> to
>>>>> > windows sdk for ex) the device information. So i can't really make
>>>>> another
>>>>> > call to registration API. What i'd suggest is to have a separate
>>>>> endpoint
>>>>> > for metrics instead of having it coupled with registration endpoint.
>>>>> wdyt?
>>>>> >
>>>>> > ++
>>>>> >
>>>>> > Corinne
>>>>> >
>>>>> > On 4 May 2015 at 19:07, S?bastien Blanc <scm.blanc at gmail.com> wrote:
>>>>> >>
>>>>> >> Hi Corinne !
>>>>> >> We want to collect for both situations you described :)
>>>>> >>
>>>>> >> Envoy? de mon iPhone
>>>>> >>
>>>>> >> Le 4 mai 2015 ? 17:53, Corinne Krych <corinnekrych at gmail.com> a
>>>>> ?crit :
>>>>> >>
>>>>> >> Hello Sebi,
>>>>> >>
>>>>> >> After giving it a closer look, I've got a question for you: do we
>>>>> want to
>>>>> >> collect metrics only when an app is opened via push notification or
>>>>> do we
>>>>> >> also want to collect metrics when an app is brought to foreground
>>>>> by a push
>>>>> >> notification?
>>>>> >>
>>>>> >> ++
>>>>> >> Corinne
>>>>> >>
>>>>> >>
>>>>> >> On 4 May 2015 at 10:21, Corinne Krych <corinnekrych at gmail.com>
>>>>> wrote:
>>>>> >>>
>>>>> >>> Yeap
>>>>> >>> on it.
>>>>> >>>
>>>>> >>> On 30 April 2015 at 15:43, Sebastien Blanc <scm.blanc at gmail.com>
>>>>> wrote:
>>>>> >>>>
>>>>> >>>> Hi,
>>>>> >>>>
>>>>> >>>> The Advanced Analytics task[1] has a new PR[2] that has been
>>>>> rebased on
>>>>> >>>> the latest master and got a lot of polishing.
>>>>> >>>>
>>>>> >>>> Could the Client Tech Leads take a look at it [3] and review ?
>>>>> The only
>>>>> >>>> "breaking" change is the rename of the header's name that
>>>>> identifies a Push
>>>>> >>>> Notification, it's called now "aerogear-push-id"
>>>>> >>>>
>>>>> >>>> Seb
>>>>> >>>>
>>>>> >>>>
>>>>> >>>>
>>>>> >>>> [1] https://issues.jboss.org/browse/AGPUSH-971
>>>>> >>>> [2]
>>>>> https://github.com/aerogear/aerogear-unifiedpush-server/pull/540
>>>>> >>>> [3] Subtasks of https://issues.jboss.org/browse/AGPUSH-971
>>>>> >>>>
>>>>> >>>>
>>>>> >>>>
>>>>> >>>> _______________________________________________
>>>>> >>>> aerogear-dev mailing list
>>>>> >>>> aerogear-dev at lists.jboss.org
>>>>> >>>> https://lists.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
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Cheers,
>>>>>        Erik Jan
>>>>>
>>>>> _______________________________________________
>>>>> aerogear-dev mailing list
>>>>> aerogear-dev at lists.jboss.org
>>>>> https://lists.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/20150505/c549de70/attachment-0001.html 

From supittma at redhat.com  Tue May  5 12:24:57 2015
From: supittma at redhat.com (Summers Pittman)
Date: Tue, 5 May 2015 12:24:57 -0400
Subject: [aerogear-dev] Advanced Analtyics,
 new PR and call to the client tech leads
In-Reply-To: <CAAg5f2TapgEVWmScoht9HnH9iMSQp=6JonZAmnPgzG49OMd_eA@mail.gmail.com>
References: <CAD_dpu2LPTTYefjbpqt4TF2jUwhxmNzg2zpqcTDh7tPcjKtGQA@mail.gmail.com>
	<CAL8vO=f49cuKORAahQhE45DEANBLTcn4x_+yMjBxbfMfpSkTTg@mail.gmail.com>
	<CAL8vO=eLktLpMMdU=5tgu4U5uoKHmRFNjZY2O4VOb1tmFLwY3Q@mail.gmail.com>
	<C36F5B92-74F3-4A2B-BAF5-6A50018ECC1D@gmail.com>
	<CAL8vO=c-22FWacpRzqjR+y2fobAXUNqsM5HhnFY_gHR-h8_8Sw@mail.gmail.com>
	<CAO2B-faqA+WKx1CfikVpaERGiS3HJQAeB+mbVQTb9GQfg2mHKA@mail.gmail.com>
	<CAL8vO=e=C_VZNaYpkAacTfDW44cpVrs=ydX0vmmfY5HQYCw4uA@mail.gmail.com>
	<CAKVvow-8uNu4OuivKkLOURMc1b-Jf=hQUqecwEKY7h=-Hh1diA@mail.gmail.com>
	<CAAg5f2TpgrA-S0OO9asUL6noXtrurKuVUC7iGvXQu468Gm1SBg@mail.gmail.com>
	<CAEQz2CvmqBZtTpeCROfeYS5yPn1b3ZafRjn0=h3=ePEBjZDDVA@mail.gmail.com>
	<CAAg5f2TapgEVWmScoht9HnH9iMSQp=6JonZAmnPgzG49OMd_eA@mail.gmail.com>
Message-ID: <CAEQz2CsHPEUnWoF9_StarvOaE7h3s5UNgSQpRs9f4B8eXp=KQQ@mail.gmail.com>

On Tue, May 5, 2015 at 12:08 PM, Matthias Wessendorf <matzew at apache.org>
wrote:

>
>
> On Tue, May 5, 2015 at 5:51 PM, Summers Pittman <supittma at redhat.com>
> wrote:
>
>>
>>
>> On Tue, May 5, 2015 at 5:17 AM, Matthias Wessendorf <matzew at apache.org>
>> wrote:
>>
>>>
>>>
>>> On Tue, May 5, 2015 at 11:09 AM, Christos Vasilakis <cvasilak at gmail.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Tue, May 5, 2015 at 11:53 AM, Corinne Krych <corinnekrych at gmail.com>
>>>> wrote:
>>>>
>>>>> To give a bit of background on this background to foreground issue :))
>>>>>
>>>>> Push Cordova plugin matches Cordova life cycle by storing some
>>>>> information locally see:
>>>>>
>>>>> https://github.com/aerogear/aerogear-cordova-push/blob/master/src/ios/AGPushPlugin.m#L82
>>>>> Doing so allows you to call multiple time registration, even when an
>>>>> app comes back from background to foreground. you can do it because you
>>>>> have stored locally all the information neede for registration.
>>>>>
>>>>> But when dealing directly with native apps, the life cycle does not
>>>>> always goes through a registration.
>>>>>
>>>>> To sort out this issue,we can:
>>>>> - either store locally at the ios-push lib level instead of doing it
>>>>> in Cordova plugin and then call registration API on all delegate methods
>>>>> (even though we don't want to register but just send the metrics)
>>>>> - or leave the ios-push lib without any storage and provide a separate
>>>>> endpoint for sending metrics or changing categories.
>>>>>
>>>>> I'd go for the second option.
>>>>>
>>>>> second option makes sense +1
>>>>
>>>
>>> +1 on separate endpoint for metrics collection
>>>
>>> regarding changing categories: Do you mean a new method on the client
>>> SDK, performing a PUT, containing the new categories for the device token,
>>> to the existing endpoint (but using PUT),  instead of getting a
>>> /updateInstallation endpoint?
>>>
>>
>> Adding a separate method on Android seems kind of weird. Android is
>> rather spammy (intentionally and by design and according to big papa G's
>> best practices) with the registration call.  Basically best practice on
>> Android is call registration every time the application is opened.
>>
>
> I see - that relates to your earlier comment, of calling 'register' all
> the time on Android/iOS as well - instead of having a update() hook.
>
> I do believe that having an updateDeviceMetadata() (e.g. to update the
> used categories, as the end-user is no longer interested in 'rihanna') does
> make sense.
>

I'm conflicted.  I see the utility but I also want to keep the amount of
mutable state to a minimum.

I still think with the way Android is architected re-registering is a less
error prone approach for developers.

In this model when a users category changes they will regenerate the
configuration using the new categories and register.  This will be the same
if the user is registering for the first time or not.

If we add an update method the developer will need to EITHER make sure the
categories are added to the config object when it is generated when the
application loads anyway OR not include category information in the
registration and then call update metadata with the proper categories.




>
> What about the metrics endpoint? Instead of sending that through the
> registration endpoint? Agree on that or not?
>

I (mostly) agree on that point.  Registration is an intention to subscribe
not a general data submission pipeline.  The thing which does metrics
should probably not be part of the PushRegistrar at all.  It might make
sense to make it a composite object which embeds a registrar though.


>
>>
>>>
>>>
>>>>
>>>> -
>>>> Christos
>>>>
>>>>>
>>>>>
>>>>> On 5 May 2015 at 10:39, Erik Jan de Wit <edewit at redhat.com> wrote:
>>>>>
>>>>>> I agree with this and maybe we want even more functionality moved,
>>>>>> because also updating the categories is strange in a 'register'
>>>>>> method. Say for instance you want to change the categories your
>>>>>> interested in a developer has to call register again? And if I
>>>>>> understand Corinnes mail that will currently not even work on iOS.
>>>>>>
>>>>>> For cordova I store the device info, because the lifecycle is
>>>>>> different, but that is okay it's an integration problem.
>>>>>>
>>>>>> So updating the installation details should be a separate method that
>>>>>> also contains updating the categories. That way we have a better split
>>>>>> between a device that registers itself with UPS and updating the
>>>>>> subscription data.
>>>>>>
>>>>>>
>>>>>> On Tue, May 5, 2015 at 9:26 AM, Corinne Krych <corinnekrych at gmail.com>
>>>>>> wrote:
>>>>>> > Hello Sebi,
>>>>>> >
>>>>>> >
>>>>>> > I've done an initial work on aerogear-ios-push [swift branch],
>>>>>> adding a new
>>>>>> > parameter when doing the registration to pass the ag-push-id. See:
>>>>>> >
>>>>>> >
>>>>>> https://github.com/aerogear/aerogear-ios-push/compare/aerogear:master...corinnekrych:AGPUSH-1232.analytics.push.notification?expand=1
>>>>>> >
>>>>>> > This client could be tested with HelloWorld. See:
>>>>>> >
>>>>>> >
>>>>>> https://github.com/jboss-mobile/unified-push-helloworld/compare/jboss-mobile:swift...corinnekrych:AGPUSH-1232.analytics.push.notification?expand=1
>>>>>> >
>>>>>> > What is not covered is the background app coming to foreground
>>>>>> through a
>>>>>> > push notification. If you look at HelloWorld:
>>>>>> >
>>>>>> >
>>>>>> https://github.com/jboss-mobile/unified-push-helloworld/blob/f7d0a7e093327f9a84041910c4c2892280c88ffb/ios-swift/HelloWorldSwift/AppDelegate.swift#L152
>>>>>> >
>>>>>> > In iOS, when we go from background to foreground we don't go through
>>>>>> > registration API. The iOS push lib doesn't store locally (as
>>>>>> opposed to
>>>>>> > windows sdk for ex) the device information. So i can't really make
>>>>>> another
>>>>>> > call to registration API. What i'd suggest is to have a separate
>>>>>> endpoint
>>>>>> > for metrics instead of having it coupled with registration
>>>>>> endpoint. wdyt?
>>>>>> >
>>>>>> > ++
>>>>>> >
>>>>>> > Corinne
>>>>>> >
>>>>>> > On 4 May 2015 at 19:07, S?bastien Blanc <scm.blanc at gmail.com>
>>>>>> wrote:
>>>>>> >>
>>>>>> >> Hi Corinne !
>>>>>> >> We want to collect for both situations you described :)
>>>>>> >>
>>>>>> >> Envoy? de mon iPhone
>>>>>> >>
>>>>>> >> Le 4 mai 2015 ? 17:53, Corinne Krych <corinnekrych at gmail.com> a
>>>>>> ?crit :
>>>>>> >>
>>>>>> >> Hello Sebi,
>>>>>> >>
>>>>>> >> After giving it a closer look, I've got a question for you: do we
>>>>>> want to
>>>>>> >> collect metrics only when an app is opened via push notification
>>>>>> or do we
>>>>>> >> also want to collect metrics when an app is brought to foreground
>>>>>> by a push
>>>>>> >> notification?
>>>>>> >>
>>>>>> >> ++
>>>>>> >> Corinne
>>>>>> >>
>>>>>> >>
>>>>>> >> On 4 May 2015 at 10:21, Corinne Krych <corinnekrych at gmail.com>
>>>>>> wrote:
>>>>>> >>>
>>>>>> >>> Yeap
>>>>>> >>> on it.
>>>>>> >>>
>>>>>> >>> On 30 April 2015 at 15:43, Sebastien Blanc <scm.blanc at gmail.com>
>>>>>> wrote:
>>>>>> >>>>
>>>>>> >>>> Hi,
>>>>>> >>>>
>>>>>> >>>> The Advanced Analytics task[1] has a new PR[2] that has been
>>>>>> rebased on
>>>>>> >>>> the latest master and got a lot of polishing.
>>>>>> >>>>
>>>>>> >>>> Could the Client Tech Leads take a look at it [3] and review ?
>>>>>> The only
>>>>>> >>>> "breaking" change is the rename of the header's name that
>>>>>> identifies a Push
>>>>>> >>>> Notification, it's called now "aerogear-push-id"
>>>>>> >>>>
>>>>>> >>>> Seb
>>>>>> >>>>
>>>>>> >>>>
>>>>>> >>>>
>>>>>> >>>> [1] https://issues.jboss.org/browse/AGPUSH-971
>>>>>> >>>> [2]
>>>>>> https://github.com/aerogear/aerogear-unifiedpush-server/pull/540
>>>>>> >>>> [3] Subtasks of https://issues.jboss.org/browse/AGPUSH-971
>>>>>> >>>>
>>>>>> >>>>
>>>>>> >>>>
>>>>>> >>>> _______________________________________________
>>>>>> >>>> aerogear-dev mailing list
>>>>>> >>>> aerogear-dev at lists.jboss.org
>>>>>> >>>> https://lists.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
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Cheers,
>>>>>>        Erik Jan
>>>>>>
>>>>>> _______________________________________________
>>>>>> aerogear-dev mailing list
>>>>>> aerogear-dev at lists.jboss.org
>>>>>> https://lists.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/20150505/ea8375ec/attachment-0001.html 

From matzew at apache.org  Tue May  5 13:47:35 2015
From: matzew at apache.org (Matthias Wessendorf)
Date: Tue, 5 May 2015 19:47:35 +0200
Subject: [aerogear-dev] Advanced Analtyics,
 new PR and call to the client tech leads
In-Reply-To: <CAEQz2CsHPEUnWoF9_StarvOaE7h3s5UNgSQpRs9f4B8eXp=KQQ@mail.gmail.com>
References: <CAD_dpu2LPTTYefjbpqt4TF2jUwhxmNzg2zpqcTDh7tPcjKtGQA@mail.gmail.com>
	<CAL8vO=f49cuKORAahQhE45DEANBLTcn4x_+yMjBxbfMfpSkTTg@mail.gmail.com>
	<CAL8vO=eLktLpMMdU=5tgu4U5uoKHmRFNjZY2O4VOb1tmFLwY3Q@mail.gmail.com>
	<C36F5B92-74F3-4A2B-BAF5-6A50018ECC1D@gmail.com>
	<CAL8vO=c-22FWacpRzqjR+y2fobAXUNqsM5HhnFY_gHR-h8_8Sw@mail.gmail.com>
	<CAO2B-faqA+WKx1CfikVpaERGiS3HJQAeB+mbVQTb9GQfg2mHKA@mail.gmail.com>
	<CAL8vO=e=C_VZNaYpkAacTfDW44cpVrs=ydX0vmmfY5HQYCw4uA@mail.gmail.com>
	<CAKVvow-8uNu4OuivKkLOURMc1b-Jf=hQUqecwEKY7h=-Hh1diA@mail.gmail.com>
	<CAAg5f2TpgrA-S0OO9asUL6noXtrurKuVUC7iGvXQu468Gm1SBg@mail.gmail.com>
	<CAEQz2CvmqBZtTpeCROfeYS5yPn1b3ZafRjn0=h3=ePEBjZDDVA@mail.gmail.com>
	<CAAg5f2TapgEVWmScoht9HnH9iMSQp=6JonZAmnPgzG49OMd_eA@mail.gmail.com>
	<CAEQz2CsHPEUnWoF9_StarvOaE7h3s5UNgSQpRs9f4B8eXp=KQQ@mail.gmail.com>
Message-ID: <CAAg5f2T9NMTK_Yz1ge6MxGB7wLCpptESetqQ5MYJnC6F5Fv6QA@mail.gmail.com>

On Tue, May 5, 2015 at 6:24 PM, Summers Pittman <supittma at redhat.com> wrote:

>
>
> On Tue, May 5, 2015 at 12:08 PM, Matthias Wessendorf <matzew at apache.org>
> wrote:
>
>>
>>
>> On Tue, May 5, 2015 at 5:51 PM, Summers Pittman <supittma at redhat.com>
>> wrote:
>>
>>>
>>>
>>> On Tue, May 5, 2015 at 5:17 AM, Matthias Wessendorf <matzew at apache.org>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Tue, May 5, 2015 at 11:09 AM, Christos Vasilakis <cvasilak at gmail.com
>>>> > wrote:
>>>>
>>>>>
>>>>>
>>>>> On Tue, May 5, 2015 at 11:53 AM, Corinne Krych <corinnekrych at gmail.com
>>>>> > wrote:
>>>>>
>>>>>> To give a bit of background on this background to foreground issue :))
>>>>>>
>>>>>> Push Cordova plugin matches Cordova life cycle by storing some
>>>>>> information locally see:
>>>>>>
>>>>>> https://github.com/aerogear/aerogear-cordova-push/blob/master/src/ios/AGPushPlugin.m#L82
>>>>>> Doing so allows you to call multiple time registration, even when an
>>>>>> app comes back from background to foreground. you can do it because you
>>>>>> have stored locally all the information neede for registration.
>>>>>>
>>>>>> But when dealing directly with native apps, the life cycle does not
>>>>>> always goes through a registration.
>>>>>>
>>>>>> To sort out this issue,we can:
>>>>>> - either store locally at the ios-push lib level instead of doing it
>>>>>> in Cordova plugin and then call registration API on all delegate methods
>>>>>> (even though we don't want to register but just send the metrics)
>>>>>> - or leave the ios-push lib without any storage and provide a
>>>>>> separate endpoint for sending metrics or changing categories.
>>>>>>
>>>>>> I'd go for the second option.
>>>>>>
>>>>>> second option makes sense +1
>>>>>
>>>>
>>>> +1 on separate endpoint for metrics collection
>>>>
>>>> regarding changing categories: Do you mean a new method on the client
>>>> SDK, performing a PUT, containing the new categories for the device token,
>>>> to the existing endpoint (but using PUT),  instead of getting a
>>>> /updateInstallation endpoint?
>>>>
>>>
>>> Adding a separate method on Android seems kind of weird. Android is
>>> rather spammy (intentionally and by design and according to big papa G's
>>> best practices) with the registration call.  Basically best practice on
>>> Android is call registration every time the application is opened.
>>>
>>
>> I see - that relates to your earlier comment, of calling 'register' all
>> the time on Android/iOS as well - instead of having a update() hook.
>>
>> I do believe that having an updateDeviceMetadata() (e.g. to update the
>> used categories, as the end-user is no longer interested in 'rihanna') does
>> make sense.
>>
>
> I'm conflicted.  I see the utility but I also want to keep the amount of
> mutable state to a minimum.
>
> I still think with the way Android is architected re-registering is a less
> error prone approach for developers.
>
> In this model when a users category changes they will regenerate the
> configuration using the new categories and register.  This will be the same
> if the user is registering for the first time or not.
>

Right, that's the original idea - and looks like works best on Android :-)


>
> If we add an update method the developer will need to EITHER make sure the
> categories are added to the config object when it is generated when the
> application loads anyway OR not include category information in the
> registration and then call update metadata with the proper categories.
>

right, it's not that great

>
>
>
>
>>
>> What about the metrics endpoint? Instead of sending that through the
>> registration endpoint? Agree on that or not?
>>
>
> I (mostly) agree on that point.  Registration is an intention to subscribe
> not a general data submission pipeline.  The thing which does metrics
> should probably not be part of the PushRegistrar at all.
>

Ah, right, I understand


> It might make sense to make it a composite object which embeds a registrar
> though.
>

and than internally it would deliver the metrics data to a different
endpoint - independent from the actual registration calls




>
>
>>
>>>
>>>>
>>>>
>>>>>
>>>>> -
>>>>> Christos
>>>>>
>>>>>>
>>>>>>
>>>>>> On 5 May 2015 at 10:39, Erik Jan de Wit <edewit at redhat.com> wrote:
>>>>>>
>>>>>>> I agree with this and maybe we want even more functionality moved,
>>>>>>> because also updating the categories is strange in a 'register'
>>>>>>> method. Say for instance you want to change the categories your
>>>>>>> interested in a developer has to call register again? And if I
>>>>>>> understand Corinnes mail that will currently not even work on iOS.
>>>>>>>
>>>>>>> For cordova I store the device info, because the lifecycle is
>>>>>>> different, but that is okay it's an integration problem.
>>>>>>>
>>>>>>> So updating the installation details should be a separate method that
>>>>>>> also contains updating the categories. That way we have a better
>>>>>>> split
>>>>>>> between a device that registers itself with UPS and updating the
>>>>>>> subscription data.
>>>>>>>
>>>>>>>
>>>>>>> On Tue, May 5, 2015 at 9:26 AM, Corinne Krych <
>>>>>>> corinnekrych at gmail.com> wrote:
>>>>>>> > Hello Sebi,
>>>>>>> >
>>>>>>> >
>>>>>>> > I've done an initial work on aerogear-ios-push [swift branch],
>>>>>>> adding a new
>>>>>>> > parameter when doing the registration to pass the ag-push-id. See:
>>>>>>> >
>>>>>>> >
>>>>>>> https://github.com/aerogear/aerogear-ios-push/compare/aerogear:master...corinnekrych:AGPUSH-1232.analytics.push.notification?expand=1
>>>>>>> >
>>>>>>> > This client could be tested with HelloWorld. See:
>>>>>>> >
>>>>>>> >
>>>>>>> https://github.com/jboss-mobile/unified-push-helloworld/compare/jboss-mobile:swift...corinnekrych:AGPUSH-1232.analytics.push.notification?expand=1
>>>>>>> >
>>>>>>> > What is not covered is the background app coming to foreground
>>>>>>> through a
>>>>>>> > push notification. If you look at HelloWorld:
>>>>>>> >
>>>>>>> >
>>>>>>> https://github.com/jboss-mobile/unified-push-helloworld/blob/f7d0a7e093327f9a84041910c4c2892280c88ffb/ios-swift/HelloWorldSwift/AppDelegate.swift#L152
>>>>>>> >
>>>>>>> > In iOS, when we go from background to foreground we don't go
>>>>>>> through
>>>>>>> > registration API. The iOS push lib doesn't store locally (as
>>>>>>> opposed to
>>>>>>> > windows sdk for ex) the device information. So i can't really make
>>>>>>> another
>>>>>>> > call to registration API. What i'd suggest is to have a separate
>>>>>>> endpoint
>>>>>>> > for metrics instead of having it coupled with registration
>>>>>>> endpoint. wdyt?
>>>>>>> >
>>>>>>> > ++
>>>>>>> >
>>>>>>> > Corinne
>>>>>>> >
>>>>>>> > On 4 May 2015 at 19:07, S?bastien Blanc <scm.blanc at gmail.com>
>>>>>>> wrote:
>>>>>>> >>
>>>>>>> >> Hi Corinne !
>>>>>>> >> We want to collect for both situations you described :)
>>>>>>> >>
>>>>>>> >> Envoy? de mon iPhone
>>>>>>> >>
>>>>>>> >> Le 4 mai 2015 ? 17:53, Corinne Krych <corinnekrych at gmail.com> a
>>>>>>> ?crit :
>>>>>>> >>
>>>>>>> >> Hello Sebi,
>>>>>>> >>
>>>>>>> >> After giving it a closer look, I've got a question for you: do we
>>>>>>> want to
>>>>>>> >> collect metrics only when an app is opened via push notification
>>>>>>> or do we
>>>>>>> >> also want to collect metrics when an app is brought to foreground
>>>>>>> by a push
>>>>>>> >> notification?
>>>>>>> >>
>>>>>>> >> ++
>>>>>>> >> Corinne
>>>>>>> >>
>>>>>>> >>
>>>>>>> >> On 4 May 2015 at 10:21, Corinne Krych <corinnekrych at gmail.com>
>>>>>>> wrote:
>>>>>>> >>>
>>>>>>> >>> Yeap
>>>>>>> >>> on it.
>>>>>>> >>>
>>>>>>> >>> On 30 April 2015 at 15:43, Sebastien Blanc <scm.blanc at gmail.com>
>>>>>>> wrote:
>>>>>>> >>>>
>>>>>>> >>>> Hi,
>>>>>>> >>>>
>>>>>>> >>>> The Advanced Analytics task[1] has a new PR[2] that has been
>>>>>>> rebased on
>>>>>>> >>>> the latest master and got a lot of polishing.
>>>>>>> >>>>
>>>>>>> >>>> Could the Client Tech Leads take a look at it [3] and review ?
>>>>>>> The only
>>>>>>> >>>> "breaking" change is the rename of the header's name that
>>>>>>> identifies a Push
>>>>>>> >>>> Notification, it's called now "aerogear-push-id"
>>>>>>> >>>>
>>>>>>> >>>> Seb
>>>>>>> >>>>
>>>>>>> >>>>
>>>>>>> >>>>
>>>>>>> >>>> [1] https://issues.jboss.org/browse/AGPUSH-971
>>>>>>> >>>> [2]
>>>>>>> https://github.com/aerogear/aerogear-unifiedpush-server/pull/540
>>>>>>> >>>> [3] Subtasks of https://issues.jboss.org/browse/AGPUSH-971
>>>>>>> >>>>
>>>>>>> >>>>
>>>>>>> >>>>
>>>>>>> >>>> _______________________________________________
>>>>>>> >>>> aerogear-dev mailing list
>>>>>>> >>>> aerogear-dev at lists.jboss.org
>>>>>>> >>>> https://lists.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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Cheers,
>>>>>>>        Erik Jan
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> aerogear-dev mailing list
>>>>>>> aerogear-dev at lists.jboss.org
>>>>>>> https://lists.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
>>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.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/20150505/23a9eb22/attachment-0001.html 

From matzew at apache.org  Tue May  5 13:53:28 2015
From: matzew at apache.org (Matthias Wessendorf)
Date: Tue, 5 May 2015 19:53:28 +0200
Subject: [aerogear-dev] Advanced Analtyics,
 new PR and call to the client tech leads
In-Reply-To: <CAL8vO=e=C_VZNaYpkAacTfDW44cpVrs=ydX0vmmfY5HQYCw4uA@mail.gmail.com>
References: <CAD_dpu2LPTTYefjbpqt4TF2jUwhxmNzg2zpqcTDh7tPcjKtGQA@mail.gmail.com>
	<CAL8vO=f49cuKORAahQhE45DEANBLTcn4x_+yMjBxbfMfpSkTTg@mail.gmail.com>
	<CAL8vO=eLktLpMMdU=5tgu4U5uoKHmRFNjZY2O4VOb1tmFLwY3Q@mail.gmail.com>
	<C36F5B92-74F3-4A2B-BAF5-6A50018ECC1D@gmail.com>
	<CAL8vO=c-22FWacpRzqjR+y2fobAXUNqsM5HhnFY_gHR-h8_8Sw@mail.gmail.com>
	<CAO2B-faqA+WKx1CfikVpaERGiS3HJQAeB+mbVQTb9GQfg2mHKA@mail.gmail.com>
	<CAL8vO=e=C_VZNaYpkAacTfDW44cpVrs=ydX0vmmfY5HQYCw4uA@mail.gmail.com>
Message-ID: <CAAg5f2QQM_LWMNkk=Ax2hGS-dS=jaP4a86KETXuKR71F4Yjb_Q@mail.gmail.com>

On Tue, May 5, 2015 at 10:53 AM, Corinne Krych <corinnekrych at gmail.com>
wrote:

> To give a bit of background on this background to foreground issue :))
>
> Push Cordova plugin matches Cordova life cycle by storing some information
> locally see:
>
> https://github.com/aerogear/aerogear-cordova-push/blob/master/src/ios/AGPushPlugin.m#L82
> Doing so allows you to call multiple time registration, even when an app
> comes back from background to foreground. you can do it because you have
> stored locally all the information neede for registration.
>
> But when dealing directly with native apps, the life cycle does not always
> goes through a registration.
>
> To sort out this issue,we can:
> - either store locally at the ios-push lib level instead of doing it in
> Cordova plugin and then call registration API on all delegate methods (even
> though we don't want to register but just send the metrics)
>

based on summers comments, I thought about this - perhaps this is the way
to go.
For sending metrics, we do not need to run the registration again, with the
new endpoint in place. The iOS push SDK could call a (private) method and
just deliver the metrics related info - that's splits the concerns and
removes the need to call register endpoint on places where we do not really
need it

-M




> - or leave the ios-push lib without any storage and provide a separate
> endpoint for sending metrics or changing categories.
>
> I'd go for the second option.
>
> ++
> Corinne
>
>
> On 5 May 2015 at 10:39, Erik Jan de Wit <edewit at redhat.com> wrote:
>
>> I agree with this and maybe we want even more functionality moved,
>> because also updating the categories is strange in a 'register'
>> method. Say for instance you want to change the categories your
>> interested in a developer has to call register again? And if I
>> understand Corinnes mail that will currently not even work on iOS.
>>
>> For cordova I store the device info, because the lifecycle is
>> different, but that is okay it's an integration problem.
>>
>> So updating the installation details should be a separate method that
>> also contains updating the categories. That way we have a better split
>> between a device that registers itself with UPS and updating the
>> subscription data.
>>
>>
>> On Tue, May 5, 2015 at 9:26 AM, Corinne Krych <corinnekrych at gmail.com>
>> wrote:
>> > Hello Sebi,
>> >
>> >
>> > I've done an initial work on aerogear-ios-push [swift branch], adding a
>> new
>> > parameter when doing the registration to pass the ag-push-id. See:
>> >
>> >
>> https://github.com/aerogear/aerogear-ios-push/compare/aerogear:master...corinnekrych:AGPUSH-1232.analytics.push.notification?expand=1
>> >
>> > This client could be tested with HelloWorld. See:
>> >
>> >
>> https://github.com/jboss-mobile/unified-push-helloworld/compare/jboss-mobile:swift...corinnekrych:AGPUSH-1232.analytics.push.notification?expand=1
>> >
>> > What is not covered is the background app coming to foreground through a
>> > push notification. If you look at HelloWorld:
>> >
>> >
>> https://github.com/jboss-mobile/unified-push-helloworld/blob/f7d0a7e093327f9a84041910c4c2892280c88ffb/ios-swift/HelloWorldSwift/AppDelegate.swift#L152
>> >
>> > In iOS, when we go from background to foreground we don't go through
>> > registration API. The iOS push lib doesn't store locally (as opposed to
>> > windows sdk for ex) the device information. So i can't really make
>> another
>> > call to registration API. What i'd suggest is to have a separate
>> endpoint
>> > for metrics instead of having it coupled with registration endpoint.
>> wdyt?
>> >
>> > ++
>> >
>> > Corinne
>> >
>> > On 4 May 2015 at 19:07, S?bastien Blanc <scm.blanc at gmail.com> wrote:
>> >>
>> >> Hi Corinne !
>> >> We want to collect for both situations you described :)
>> >>
>> >> Envoy? de mon iPhone
>> >>
>> >> Le 4 mai 2015 ? 17:53, Corinne Krych <corinnekrych at gmail.com> a ?crit
>> :
>> >>
>> >> Hello Sebi,
>> >>
>> >> After giving it a closer look, I've got a question for you: do we want
>> to
>> >> collect metrics only when an app is opened via push notification or do
>> we
>> >> also want to collect metrics when an app is brought to foreground by a
>> push
>> >> notification?
>> >>
>> >> ++
>> >> Corinne
>> >>
>> >>
>> >> On 4 May 2015 at 10:21, Corinne Krych <corinnekrych at gmail.com> wrote:
>> >>>
>> >>> Yeap
>> >>> on it.
>> >>>
>> >>> On 30 April 2015 at 15:43, Sebastien Blanc <scm.blanc at gmail.com>
>> wrote:
>> >>>>
>> >>>> Hi,
>> >>>>
>> >>>> The Advanced Analytics task[1] has a new PR[2] that has been rebased
>> on
>> >>>> the latest master and got a lot of polishing.
>> >>>>
>> >>>> Could the Client Tech Leads take a look at it [3] and review ? The
>> only
>> >>>> "breaking" change is the rename of the header's name that identifies
>> a Push
>> >>>> Notification, it's called now "aerogear-push-id"
>> >>>>
>> >>>> Seb
>> >>>>
>> >>>>
>> >>>>
>> >>>> [1] https://issues.jboss.org/browse/AGPUSH-971
>> >>>> [2] https://github.com/aerogear/aerogear-unifiedpush-server/pull/540
>> >>>> [3] Subtasks of https://issues.jboss.org/browse/AGPUSH-971
>> >>>>
>> >>>>
>> >>>>
>> >>>> _______________________________________________
>> >>>> aerogear-dev mailing list
>> >>>> aerogear-dev at lists.jboss.org
>> >>>> https://lists.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
>>
>>
>>
>> --
>> Cheers,
>>        Erik Jan
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.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/20150505/15de68fe/attachment.html 

From matzew at apache.org  Wed May  6 05:38:02 2015
From: matzew at apache.org (Matthias Wessendorf)
Date: Wed, 6 May 2015 11:38:02 +0200
Subject: [aerogear-dev] Metrics Endpoint (was: Re:  Advanced Analtyics,
 new PR and call to the client tech leads)
Message-ID: <CAAg5f2SVYYtv+hTcH=JkDkbjvGDyvLj4aG98HzY8nhK2uKnKRg@mail.gmail.com>

Hi,

as discussed on the previous thread, there will be a new endpoint to
'track' the "App opened/launched due to received push notification".

Internally, on the UPS, the Push Message has an ID, which get's append to
the payload of the notification, like here:
https://github.com/matzew/aerogear-unifiedpush-server/blob/analytics/push/sender/src/main/java/org/jboss/aerogear/unifiedpush/message/sender/APNsPushNotificationSender.java#L107-L108

On the client SDKs this will be read and a HTTP call made to the soon
introduced MetricsEndpoint. Currently this info is send to the
RegistrationEndpoint, including the deviceToken/registrationId. However, I
think that the deviceToken/registrationId is currently not needed for
metrics, since we are just interested in anonymous "app launched/opened due
to push", and not a specific "DEVICE X did open, while DEVICE Y did not yet
open".

So all we really need is the ID of the push notification, to be processed
by our Metrics Service
https://github.com/matzew/aerogear-unifiedpush-server/blob/analytics/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/registry/installations/InstallationRegistrationEndpoint.java#L128-L133

Therefore my proposal is have an endpoint:

PUT /metrics/pushmessage/{pushMessageID}

I think PUT is good/best, because there is nothing really created on the
server, it's more updating the 'counter' on the existing
PushMessageInformation object.

Thoughts?
-Matthias


On Tue, May 5, 2015 at 7:53 PM, Matthias Wessendorf <matzew at apache.org>
wrote:

>
>
> On Tue, May 5, 2015 at 10:53 AM, Corinne Krych <corinnekrych at gmail.com>
> wrote:
>
>> To give a bit of background on this background to foreground issue :))
>>
>> Push Cordova plugin matches Cordova life cycle by storing some
>> information locally see:
>>
>> https://github.com/aerogear/aerogear-cordova-push/blob/master/src/ios/AGPushPlugin.m#L82
>> Doing so allows you to call multiple time registration, even when an app
>> comes back from background to foreground. you can do it because you have
>> stored locally all the information neede for registration.
>>
>> But when dealing directly with native apps, the life cycle does not
>> always goes through a registration.
>>
>> To sort out this issue,we can:
>> - either store locally at the ios-push lib level instead of doing it in
>> Cordova plugin and then call registration API on all delegate methods (even
>> though we don't want to register but just send the metrics)
>>
>
> based on summers comments, I thought about this - perhaps this is the way
> to go.
> For sending metrics, we do not need to run the registration again, with
> the new endpoint in place. The iOS push SDK could call a (private) method
> and just deliver the metrics related info - that's splits the concerns and
> removes the need to call register endpoint on places where we do not really
> need it
>
> -M
>
>
>
>
>> - or leave the ios-push lib without any storage and provide a separate
>> endpoint for sending metrics or changing categories.
>>
>> I'd go for the second option.
>>
>> ++
>> Corinne
>>
>>
>> On 5 May 2015 at 10:39, Erik Jan de Wit <edewit at redhat.com> wrote:
>>
>>> I agree with this and maybe we want even more functionality moved,
>>> because also updating the categories is strange in a 'register'
>>> method. Say for instance you want to change the categories your
>>> interested in a developer has to call register again? And if I
>>> understand Corinnes mail that will currently not even work on iOS.
>>>
>>> For cordova I store the device info, because the lifecycle is
>>> different, but that is okay it's an integration problem.
>>>
>>> So updating the installation details should be a separate method that
>>> also contains updating the categories. That way we have a better split
>>> between a device that registers itself with UPS and updating the
>>> subscription data.
>>>
>>>
>>> On Tue, May 5, 2015 at 9:26 AM, Corinne Krych <corinnekrych at gmail.com>
>>> wrote:
>>> > Hello Sebi,
>>> >
>>> >
>>> > I've done an initial work on aerogear-ios-push [swift branch], adding
>>> a new
>>> > parameter when doing the registration to pass the ag-push-id. See:
>>> >
>>> >
>>> https://github.com/aerogear/aerogear-ios-push/compare/aerogear:master...corinnekrych:AGPUSH-1232.analytics.push.notification?expand=1
>>> >
>>> > This client could be tested with HelloWorld. See:
>>> >
>>> >
>>> https://github.com/jboss-mobile/unified-push-helloworld/compare/jboss-mobile:swift...corinnekrych:AGPUSH-1232.analytics.push.notification?expand=1
>>> >
>>> > What is not covered is the background app coming to foreground through
>>> a
>>> > push notification. If you look at HelloWorld:
>>> >
>>> >
>>> https://github.com/jboss-mobile/unified-push-helloworld/blob/f7d0a7e093327f9a84041910c4c2892280c88ffb/ios-swift/HelloWorldSwift/AppDelegate.swift#L152
>>> >
>>> > In iOS, when we go from background to foreground we don't go through
>>> > registration API. The iOS push lib doesn't store locally (as opposed to
>>> > windows sdk for ex) the device information. So i can't really make
>>> another
>>> > call to registration API. What i'd suggest is to have a separate
>>> endpoint
>>> > for metrics instead of having it coupled with registration endpoint.
>>> wdyt?
>>> >
>>> > ++
>>> >
>>> > Corinne
>>> >
>>> > On 4 May 2015 at 19:07, S?bastien Blanc <scm.blanc at gmail.com> wrote:
>>> >>
>>> >> Hi Corinne !
>>> >> We want to collect for both situations you described :)
>>> >>
>>> >> Envoy? de mon iPhone
>>> >>
>>> >> Le 4 mai 2015 ? 17:53, Corinne Krych <corinnekrych at gmail.com> a
>>> ?crit :
>>> >>
>>> >> Hello Sebi,
>>> >>
>>> >> After giving it a closer look, I've got a question for you: do we
>>> want to
>>> >> collect metrics only when an app is opened via push notification or
>>> do we
>>> >> also want to collect metrics when an app is brought to foreground by
>>> a push
>>> >> notification?
>>> >>
>>> >> ++
>>> >> Corinne
>>> >>
>>> >>
>>> >> On 4 May 2015 at 10:21, Corinne Krych <corinnekrych at gmail.com> wrote:
>>> >>>
>>> >>> Yeap
>>> >>> on it.
>>> >>>
>>> >>> On 30 April 2015 at 15:43, Sebastien Blanc <scm.blanc at gmail.com>
>>> wrote:
>>> >>>>
>>> >>>> Hi,
>>> >>>>
>>> >>>> The Advanced Analytics task[1] has a new PR[2] that has been
>>> rebased on
>>> >>>> the latest master and got a lot of polishing.
>>> >>>>
>>> >>>> Could the Client Tech Leads take a look at it [3] and review ? The
>>> only
>>> >>>> "breaking" change is the rename of the header's name that
>>> identifies a Push
>>> >>>> Notification, it's called now "aerogear-push-id"
>>> >>>>
>>> >>>> Seb
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> [1] https://issues.jboss.org/browse/AGPUSH-971
>>> >>>> [2]
>>> https://github.com/aerogear/aerogear-unifiedpush-server/pull/540
>>> >>>> [3] Subtasks of https://issues.jboss.org/browse/AGPUSH-971
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> _______________________________________________
>>> >>>> aerogear-dev mailing list
>>> >>>> aerogear-dev at lists.jboss.org
>>> >>>> https://lists.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
>>>
>>>
>>>
>>> --
>>> Cheers,
>>>        Erik Jan
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.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/20150506/9c89fa5f/attachment-0001.html 

From scm.blanc at gmail.com  Wed May  6 05:47:23 2015
From: scm.blanc at gmail.com (=?utf-8?Q?S=C3=A9bastien_Blanc?=)
Date: Wed, 6 May 2015 11:47:23 +0200
Subject: [aerogear-dev] Metrics Endpoint (was: Re:  Advanced Analtyics,
	new PR and call to the client tech leads)
In-Reply-To: <CAAg5f2SVYYtv+hTcH=JkDkbjvGDyvLj4aG98HzY8nhK2uKnKRg@mail.gmail.com>
References: <CAAg5f2SVYYtv+hTcH=JkDkbjvGDyvLj4aG98HzY8nhK2uKnKRg@mail.gmail.com>
Message-ID: <83B32C88-B549-48E5-9F1A-3300D079A251@gmail.com>



Envoy? de mon iPhone

> Le 6 mai 2015 ? 11:38, Matthias Wessendorf <matzew at apache.org> a ?crit :
> 
> Hi,
> 
> as discussed on the previous thread, there will be a new endpoint to 'track' the "App opened/launched due to received push notification".
> 
> Internally, on the UPS, the Push Message has an ID, which get's append to the payload of the notification, like here:
> https://github.com/matzew/aerogear-unifiedpush-server/blob/analytics/push/sender/src/main/java/org/jboss/aerogear/unifiedpush/message/sender/APNsPushNotificationSender.java#L107-L108
> 
> On the client SDKs this will be read and a HTTP call made to the soon introduced MetricsEndpoint. Currently this info is send to the RegistrationEndpoint, including the deviceToken/registrationId. However, I think that the deviceToken/registrationId is currently not needed for metrics, since we are just interested in anonymous "app launched/opened due to push", and not a specific "DEVICE X did open, while DEVICE Y did not yet open".
> 
> So all we really need is the ID of the push notification, to be processed by our Metrics Service
> https://github.com/matzew/aerogear-unifiedpush-server/blob/analytics/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/registry/installations/InstallationRegistrationEndpoint.java#L128-L133
> 
> Therefore my proposal is have an endpoint:
> 
> PUT /metrics/pushmessage/{pushMessageID}
> 
> I think PUT is good/best, because there is nothing really created on the server, it's more updating the 'counter' on the existing PushMessageInformation object.
> 
> Thoughts?
Let's make sure it's still protected by basic auth using the variantId, we need to know which variant is hit. 

Skipping the registration endpoint we might miss metadata, like os version etc ... But for this first version it should not be a issue. 
> -Matthias
> 
> 
>> On Tue, May 5, 2015 at 7:53 PM, Matthias Wessendorf <matzew at apache.org> wrote:
>> 
>> 
>>> On Tue, May 5, 2015 at 10:53 AM, Corinne Krych <corinnekrych at gmail.com> wrote:
>>> To give a bit of background on this background to foreground issue :))
>>> 
>>> Push Cordova plugin matches Cordova life cycle by storing some information locally see:
>>> https://github.com/aerogear/aerogear-cordova-push/blob/master/src/ios/AGPushPlugin.m#L82
>>> Doing so allows you to call multiple time registration, even when an app comes back from background to foreground. you can do it because you have stored locally all the information neede for registration.
>>> 
>>> But when dealing directly with native apps, the life cycle does not always goes through a registration.
>>> 
>>> To sort out this issue,we can:
>>> - either store locally at the ios-push lib level instead of doing it in Cordova plugin and then call registration API on all delegate methods (even though we don't want to register but just send the metrics)
>> 
>> based on summers comments, I thought about this - perhaps this is the way to go.
>> For sending metrics, we do not need to run the registration again, with the new endpoint in place. The iOS push SDK could call a (private) method and just deliver the metrics related info - that's splits the concerns and removes the need to call register endpoint on places where we do not really need it
>> 
>> -M
>> 
>> 
>>  
>>> - or leave the ios-push lib without any storage and provide a separate endpoint for sending metrics or changing categories.  
>>> 
>>> I'd go for the second option.
>>> 
>>> ++
>>> Corinne
>>> 
>>> 
>>>> On 5 May 2015 at 10:39, Erik Jan de Wit <edewit at redhat.com> wrote:
>>>> I agree with this and maybe we want even more functionality moved,
>>>> because also updating the categories is strange in a 'register'
>>>> method. Say for instance you want to change the categories your
>>>> interested in a developer has to call register again? And if I
>>>> understand Corinnes mail that will currently not even work on iOS.
>>>> 
>>>> For cordova I store the device info, because the lifecycle is
>>>> different, but that is okay it's an integration problem.
>>>> 
>>>> So updating the installation details should be a separate method that
>>>> also contains updating the categories. That way we have a better split
>>>> between a device that registers itself with UPS and updating the
>>>> subscription data.
>>>> 
>>>> 
>>>> On Tue, May 5, 2015 at 9:26 AM, Corinne Krych <corinnekrych at gmail.com> wrote:
>>>> > Hello Sebi,
>>>> >
>>>> >
>>>> > I've done an initial work on aerogear-ios-push [swift branch], adding a new
>>>> > parameter when doing the registration to pass the ag-push-id. See:
>>>> >
>>>> > https://github.com/aerogear/aerogear-ios-push/compare/aerogear:master...corinnekrych:AGPUSH-1232.analytics.push.notification?expand=1
>>>> >
>>>> > This client could be tested with HelloWorld. See:
>>>> >
>>>> > https://github.com/jboss-mobile/unified-push-helloworld/compare/jboss-mobile:swift...corinnekrych:AGPUSH-1232.analytics.push.notification?expand=1
>>>> >
>>>> > What is not covered is the background app coming to foreground through a
>>>> > push notification. If you look at HelloWorld:
>>>> >
>>>> > https://github.com/jboss-mobile/unified-push-helloworld/blob/f7d0a7e093327f9a84041910c4c2892280c88ffb/ios-swift/HelloWorldSwift/AppDelegate.swift#L152
>>>> >
>>>> > In iOS, when we go from background to foreground we don't go through
>>>> > registration API. The iOS push lib doesn't store locally (as opposed to
>>>> > windows sdk for ex) the device information. So i can't really make another
>>>> > call to registration API. What i'd suggest is to have a separate endpoint
>>>> > for metrics instead of having it coupled with registration endpoint. wdyt?
>>>> >
>>>> > ++
>>>> >
>>>> > Corinne
>>>> >
>>>> > On 4 May 2015 at 19:07, S?bastien Blanc <scm.blanc at gmail.com> wrote:
>>>> >>
>>>> >> Hi Corinne !
>>>> >> We want to collect for both situations you described :)
>>>> >>
>>>> >> Envoy? de mon iPhone
>>>> >>
>>>> >> Le 4 mai 2015 ? 17:53, Corinne Krych <corinnekrych at gmail.com> a ?crit :
>>>> >>
>>>> >> Hello Sebi,
>>>> >>
>>>> >> After giving it a closer look, I've got a question for you: do we want to
>>>> >> collect metrics only when an app is opened via push notification or do we
>>>> >> also want to collect metrics when an app is brought to foreground by a push
>>>> >> notification?
>>>> >>
>>>> >> ++
>>>> >> Corinne
>>>> >>
>>>> >>
>>>> >> On 4 May 2015 at 10:21, Corinne Krych <corinnekrych at gmail.com> wrote:
>>>> >>>
>>>> >>> Yeap
>>>> >>> on it.
>>>> >>>
>>>> >>> On 30 April 2015 at 15:43, Sebastien Blanc <scm.blanc at gmail.com> wrote:
>>>> >>>>
>>>> >>>> Hi,
>>>> >>>>
>>>> >>>> The Advanced Analytics task[1] has a new PR[2] that has been rebased on
>>>> >>>> the latest master and got a lot of polishing.
>>>> >>>>
>>>> >>>> Could the Client Tech Leads take a look at it [3] and review ? The only
>>>> >>>> "breaking" change is the rename of the header's name that identifies a Push
>>>> >>>> Notification, it's called now "aerogear-push-id"
>>>> >>>>
>>>> >>>> Seb
>>>> >>>>
>>>> >>>>
>>>> >>>>
>>>> >>>> [1] https://issues.jboss.org/browse/AGPUSH-971
>>>> >>>> [2] https://github.com/aerogear/aerogear-unifiedpush-server/pull/540
>>>> >>>> [3] Subtasks of https://issues.jboss.org/browse/AGPUSH-971
>>>> >>>>
>>>> >>>>
>>>> >>>>
>>>> >>>> _______________________________________________
>>>> >>>> aerogear-dev mailing list
>>>> >>>> aerogear-dev at lists.jboss.org
>>>> >>>> https://lists.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
>>>> 
>>>> 
>>>> 
>>>> --
>>>> Cheers,
>>>>        Erik Jan
>>>> 
>>>> _______________________________________________
>>>> aerogear-dev mailing list
>>>> aerogear-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>> 
>>> 
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev at lists.jboss.org
>>> https://lists.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/20150506/5e2374e7/attachment.html 

From matzew at apache.org  Wed May  6 05:52:39 2015
From: matzew at apache.org (Matthias Wessendorf)
Date: Wed, 6 May 2015 11:52:39 +0200
Subject: [aerogear-dev] Metrics Endpoint (was: Re: Advanced Analtyics,
 new PR and call to the client tech leads)
In-Reply-To: <83B32C88-B549-48E5-9F1A-3300D079A251@gmail.com>
References: <CAAg5f2SVYYtv+hTcH=JkDkbjvGDyvLj4aG98HzY8nhK2uKnKRg@mail.gmail.com>
	<83B32C88-B549-48E5-9F1A-3300D079A251@gmail.com>
Message-ID: <CAAg5f2Rf4UEc4mw5mgSidAzhnHWDP62zDbnnH68HVvC7ESTbSg@mail.gmail.com>

On Wed, May 6, 2015 at 11:47 AM, S?bastien Blanc <scm.blanc at gmail.com>
wrote:

>
>
> Envoy? de mon iPhone
>
> Le 6 mai 2015 ? 11:38, Matthias Wessendorf <matzew at apache.org> a ?crit :
>
> Hi,
>
> as discussed on the previous thread, there will be a new endpoint to
> 'track' the "App opened/launched due to received push notification".
>
> Internally, on the UPS, the Push Message has an ID, which get's append to
> the payload of the notification, like here:
>
> https://github.com/matzew/aerogear-unifiedpush-server/blob/analytics/push/sender/src/main/java/org/jboss/aerogear/unifiedpush/message/sender/APNsPushNotificationSender.java#L107-L108
>
> On the client SDKs this will be read and a HTTP call made to the soon
> introduced MetricsEndpoint. Currently this info is send to the
> RegistrationEndpoint, including the deviceToken/registrationId. However, I
> think that the deviceToken/registrationId is currently not needed for
> metrics, since we are just interested in anonymous "app launched/opened due
> to push", and not a specific "DEVICE X did open, while DEVICE Y did not yet
> open".
>
> So all we really need is the ID of the push notification, to be processed
> by our Metrics Service
>
> https://github.com/matzew/aerogear-unifiedpush-server/blob/analytics/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/registry/installations/InstallationRegistrationEndpoint.java#L128-L133
>
> Therefore my proposal is have an endpoint:
>
> PUT /metrics/pushmessage/{pushMessageID}
>
> I think PUT is good/best, because there is nothing really created on the
> server, it's more updating the 'counter' on the existing
> PushMessageInformation object.
>
> Thoughts?
>
> Let's make sure it's still protected by basic auth using the variantId, we
> need to know which variant is hit.
>

yes :-)


>
> Skipping the registration endpoint we might miss metadata, like os version
> etc ... But for this first version it should not be a issue.
>

I think that would be nice to have percentage of OS/OS version - it would
be not too hard to have that included.

Are we, today, are already having a relationship between "app opened" and
OS/OS_version? I don't really see that on the PR


> -Matthias
>
>
> On Tue, May 5, 2015 at 7:53 PM, Matthias Wessendorf <matzew at apache.org>
> wrote:
>
>>
>>
>> On Tue, May 5, 2015 at 10:53 AM, Corinne Krych <corinnekrych at gmail.com>
>> wrote:
>>
>>> To give a bit of background on this background to foreground issue :))
>>>
>>> Push Cordova plugin matches Cordova life cycle by storing some
>>> information locally see:
>>>
>>> https://github.com/aerogear/aerogear-cordova-push/blob/master/src/ios/AGPushPlugin.m#L82
>>> Doing so allows you to call multiple time registration, even when an app
>>> comes back from background to foreground. you can do it because you have
>>> stored locally all the information neede for registration.
>>>
>>> But when dealing directly with native apps, the life cycle does not
>>> always goes through a registration.
>>>
>>> To sort out this issue,we can:
>>> - either store locally at the ios-push lib level instead of doing it in
>>> Cordova plugin and then call registration API on all delegate methods (even
>>> though we don't want to register but just send the metrics)
>>>
>>
>> based on summers comments, I thought about this - perhaps this is the way
>> to go.
>> For sending metrics, we do not need to run the registration again, with
>> the new endpoint in place. The iOS push SDK could call a (private) method
>> and just deliver the metrics related info - that's splits the concerns and
>> removes the need to call register endpoint on places where we do not really
>> need it
>>
>> -M
>>
>>
>>
>>
>>> - or leave the ios-push lib without any storage and provide a separate
>>> endpoint for sending metrics or changing categories.
>>>
>>> I'd go for the second option.
>>>
>>> ++
>>> Corinne
>>>
>>>
>>> On 5 May 2015 at 10:39, Erik Jan de Wit <edewit at redhat.com> wrote:
>>>
>>>> I agree with this and maybe we want even more functionality moved,
>>>> because also updating the categories is strange in a 'register'
>>>> method. Say for instance you want to change the categories your
>>>> interested in a developer has to call register again? And if I
>>>> understand Corinnes mail that will currently not even work on iOS.
>>>>
>>>> For cordova I store the device info, because the lifecycle is
>>>> different, but that is okay it's an integration problem.
>>>>
>>>> So updating the installation details should be a separate method that
>>>> also contains updating the categories. That way we have a better split
>>>> between a device that registers itself with UPS and updating the
>>>> subscription data.
>>>>
>>>>
>>>> On Tue, May 5, 2015 at 9:26 AM, Corinne Krych <corinnekrych at gmail.com>
>>>> wrote:
>>>> > Hello Sebi,
>>>> >
>>>> >
>>>> > I've done an initial work on aerogear-ios-push [swift branch], adding
>>>> a new
>>>> > parameter when doing the registration to pass the ag-push-id. See:
>>>> >
>>>> >
>>>> https://github.com/aerogear/aerogear-ios-push/compare/aerogear:master...corinnekrych:AGPUSH-1232.analytics.push.notification?expand=1
>>>> >
>>>> > This client could be tested with HelloWorld. See:
>>>> >
>>>> >
>>>> https://github.com/jboss-mobile/unified-push-helloworld/compare/jboss-mobile:swift...corinnekrych:AGPUSH-1232.analytics.push.notification?expand=1
>>>> >
>>>> > What is not covered is the background app coming to foreground
>>>> through a
>>>> > push notification. If you look at HelloWorld:
>>>> >
>>>> >
>>>> https://github.com/jboss-mobile/unified-push-helloworld/blob/f7d0a7e093327f9a84041910c4c2892280c88ffb/ios-swift/HelloWorldSwift/AppDelegate.swift#L152
>>>> >
>>>> > In iOS, when we go from background to foreground we don't go through
>>>> > registration API. The iOS push lib doesn't store locally (as opposed
>>>> to
>>>> > windows sdk for ex) the device information. So i can't really make
>>>> another
>>>> > call to registration API. What i'd suggest is to have a separate
>>>> endpoint
>>>> > for metrics instead of having it coupled with registration endpoint.
>>>> wdyt?
>>>> >
>>>> > ++
>>>> >
>>>> > Corinne
>>>> >
>>>> > On 4 May 2015 at 19:07, S?bastien Blanc <scm.blanc at gmail.com> wrote:
>>>> >>
>>>> >> Hi Corinne !
>>>> >> We want to collect for both situations you described :)
>>>> >>
>>>> >> Envoy? de mon iPhone
>>>> >>
>>>> >> Le 4 mai 2015 ? 17:53, Corinne Krych <corinnekrych at gmail.com> a
>>>> ?crit :
>>>> >>
>>>> >> Hello Sebi,
>>>> >>
>>>> >> After giving it a closer look, I've got a question for you: do we
>>>> want to
>>>> >> collect metrics only when an app is opened via push notification or
>>>> do we
>>>> >> also want to collect metrics when an app is brought to foreground by
>>>> a push
>>>> >> notification?
>>>> >>
>>>> >> ++
>>>> >> Corinne
>>>> >>
>>>> >>
>>>> >> On 4 May 2015 at 10:21, Corinne Krych <corinnekrych at gmail.com>
>>>> wrote:
>>>> >>>
>>>> >>> Yeap
>>>> >>> on it.
>>>> >>>
>>>> >>> On 30 April 2015 at 15:43, Sebastien Blanc <scm.blanc at gmail.com>
>>>> wrote:
>>>> >>>>
>>>> >>>> Hi,
>>>> >>>>
>>>> >>>> The Advanced Analytics task[1] has a new PR[2] that has been
>>>> rebased on
>>>> >>>> the latest master and got a lot of polishing.
>>>> >>>>
>>>> >>>> Could the Client Tech Leads take a look at it [3] and review ? The
>>>> only
>>>> >>>> "breaking" change is the rename of the header's name that
>>>> identifies a Push
>>>> >>>> Notification, it's called now "aerogear-push-id"
>>>> >>>>
>>>> >>>> Seb
>>>> >>>>
>>>> >>>>
>>>> >>>>
>>>> >>>> [1] https://issues.jboss.org/browse/AGPUSH-971
>>>> >>>> [2]
>>>> https://github.com/aerogear/aerogear-unifiedpush-server/pull/540
>>>> >>>> [3] Subtasks of https://issues.jboss.org/browse/AGPUSH-971
>>>> >>>>
>>>> >>>>
>>>> >>>>
>>>> >>>> _______________________________________________
>>>> >>>> aerogear-dev mailing list
>>>> >>>> aerogear-dev at lists.jboss.org
>>>> >>>> https://lists.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
>>>>
>>>>
>>>>
>>>> --
>>>> Cheers,
>>>>        Erik Jan
>>>>
>>>> _______________________________________________
>>>> aerogear-dev mailing list
>>>> aerogear-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>
>>>
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev at lists.jboss.org
>>> https://lists.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/20150506/df0d7055/attachment-0001.html 

From matzew at apache.org  Wed May  6 05:54:43 2015
From: matzew at apache.org (Matthias Wessendorf)
Date: Wed, 6 May 2015 11:54:43 +0200
Subject: [aerogear-dev] Metrics Endpoint (was: Re: Advanced Analtyics,
 new PR and call to the client tech leads)
In-Reply-To: <CAAg5f2Rf4UEc4mw5mgSidAzhnHWDP62zDbnnH68HVvC7ESTbSg@mail.gmail.com>
References: <CAAg5f2SVYYtv+hTcH=JkDkbjvGDyvLj4aG98HzY8nhK2uKnKRg@mail.gmail.com>
	<83B32C88-B549-48E5-9F1A-3300D079A251@gmail.com>
	<CAAg5f2Rf4UEc4mw5mgSidAzhnHWDP62zDbnnH68HVvC7ESTbSg@mail.gmail.com>
Message-ID: <CAAg5f2Q6Dyh+wxQ0cQkKZ0MGT-zzECKRZ-_rHCusMXEifz1pdw@mail.gmail.com>

On Wed, May 6, 2015 at 11:52 AM, Matthias Wessendorf <matzew at apache.org>
wrote:

>
>
> On Wed, May 6, 2015 at 11:47 AM, S?bastien Blanc <scm.blanc at gmail.com>
> wrote:
>
>>
>>
>> Envoy? de mon iPhone
>>
>> Le 6 mai 2015 ? 11:38, Matthias Wessendorf <matzew at apache.org> a ?crit :
>>
>> Hi,
>>
>> as discussed on the previous thread, there will be a new endpoint to
>> 'track' the "App opened/launched due to received push notification".
>>
>> Internally, on the UPS, the Push Message has an ID, which get's append to
>> the payload of the notification, like here:
>>
>> https://github.com/matzew/aerogear-unifiedpush-server/blob/analytics/push/sender/src/main/java/org/jboss/aerogear/unifiedpush/message/sender/APNsPushNotificationSender.java#L107-L108
>>
>> On the client SDKs this will be read and a HTTP call made to the soon
>> introduced MetricsEndpoint. Currently this info is send to the
>> RegistrationEndpoint, including the deviceToken/registrationId. However, I
>> think that the deviceToken/registrationId is currently not needed for
>> metrics, since we are just interested in anonymous "app launched/opened due
>> to push", and not a specific "DEVICE X did open, while DEVICE Y did not yet
>> open".
>>
>> So all we really need is the ID of the push notification, to be processed
>> by our Metrics Service
>>
>> https://github.com/matzew/aerogear-unifiedpush-server/blob/analytics/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/registry/installations/InstallationRegistrationEndpoint.java#L128-L133
>>
>> Therefore my proposal is have an endpoint:
>>
>> PUT /metrics/pushmessage/{pushMessageID}
>>
>> I think PUT is good/best, because there is nothing really created on the
>> server, it's more updating the 'counter' on the existing
>> PushMessageInformation object.
>>
>> Thoughts?
>>
>> Let's make sure it's still protected by basic auth using the variantId,
>> we need to know which variant is hit.
>>
>
> yes :-)
>
>
>>
>> Skipping the registration endpoint we might miss metadata, like os
>> version etc ... But for this first version it should not be a issue.
>>
>
> I think that would be nice to have percentage of OS/OS version - it would
> be not too hard to have that included.
>

the variant gives us at least the platform - which would be good enough ;-)
But perhaps, at some point, a version string would be nice.

However, on iOS SDK that is a bit of an issue, since that means the push
registration SDK needs to use UIDevice APIs for automatic submit of the
version ;-/
Today, this is done on the user code, on the Delegate - which is better.

>
> Are we, today, are already having a relationship between "app opened" and
> OS/OS_version? I don't really see that on the PR
>
>
>> -Matthias
>>
>>
>> On Tue, May 5, 2015 at 7:53 PM, Matthias Wessendorf <matzew at apache.org>
>> wrote:
>>
>>>
>>>
>>> On Tue, May 5, 2015 at 10:53 AM, Corinne Krych <corinnekrych at gmail.com>
>>> wrote:
>>>
>>>> To give a bit of background on this background to foreground issue :))
>>>>
>>>> Push Cordova plugin matches Cordova life cycle by storing some
>>>> information locally see:
>>>>
>>>> https://github.com/aerogear/aerogear-cordova-push/blob/master/src/ios/AGPushPlugin.m#L82
>>>> Doing so allows you to call multiple time registration, even when an
>>>> app comes back from background to foreground. you can do it because you
>>>> have stored locally all the information neede for registration.
>>>>
>>>> But when dealing directly with native apps, the life cycle does not
>>>> always goes through a registration.
>>>>
>>>> To sort out this issue,we can:
>>>> - either store locally at the ios-push lib level instead of doing it in
>>>> Cordova plugin and then call registration API on all delegate methods (even
>>>> though we don't want to register but just send the metrics)
>>>>
>>>
>>> based on summers comments, I thought about this - perhaps this is the
>>> way to go.
>>> For sending metrics, we do not need to run the registration again, with
>>> the new endpoint in place. The iOS push SDK could call a (private) method
>>> and just deliver the metrics related info - that's splits the concerns and
>>> removes the need to call register endpoint on places where we do not really
>>> need it
>>>
>>> -M
>>>
>>>
>>>
>>>
>>>> - or leave the ios-push lib without any storage and provide a separate
>>>> endpoint for sending metrics or changing categories.
>>>>
>>>> I'd go for the second option.
>>>>
>>>> ++
>>>> Corinne
>>>>
>>>>
>>>> On 5 May 2015 at 10:39, Erik Jan de Wit <edewit at redhat.com> wrote:
>>>>
>>>>> I agree with this and maybe we want even more functionality moved,
>>>>> because also updating the categories is strange in a 'register'
>>>>> method. Say for instance you want to change the categories your
>>>>> interested in a developer has to call register again? And if I
>>>>> understand Corinnes mail that will currently not even work on iOS.
>>>>>
>>>>> For cordova I store the device info, because the lifecycle is
>>>>> different, but that is okay it's an integration problem.
>>>>>
>>>>> So updating the installation details should be a separate method that
>>>>> also contains updating the categories. That way we have a better split
>>>>> between a device that registers itself with UPS and updating the
>>>>> subscription data.
>>>>>
>>>>>
>>>>> On Tue, May 5, 2015 at 9:26 AM, Corinne Krych <corinnekrych at gmail.com>
>>>>> wrote:
>>>>> > Hello Sebi,
>>>>> >
>>>>> >
>>>>> > I've done an initial work on aerogear-ios-push [swift branch],
>>>>> adding a new
>>>>> > parameter when doing the registration to pass the ag-push-id. See:
>>>>> >
>>>>> >
>>>>> https://github.com/aerogear/aerogear-ios-push/compare/aerogear:master...corinnekrych:AGPUSH-1232.analytics.push.notification?expand=1
>>>>> >
>>>>> > This client could be tested with HelloWorld. See:
>>>>> >
>>>>> >
>>>>> https://github.com/jboss-mobile/unified-push-helloworld/compare/jboss-mobile:swift...corinnekrych:AGPUSH-1232.analytics.push.notification?expand=1
>>>>> >
>>>>> > What is not covered is the background app coming to foreground
>>>>> through a
>>>>> > push notification. If you look at HelloWorld:
>>>>> >
>>>>> >
>>>>> https://github.com/jboss-mobile/unified-push-helloworld/blob/f7d0a7e093327f9a84041910c4c2892280c88ffb/ios-swift/HelloWorldSwift/AppDelegate.swift#L152
>>>>> >
>>>>> > In iOS, when we go from background to foreground we don't go through
>>>>> > registration API. The iOS push lib doesn't store locally (as opposed
>>>>> to
>>>>> > windows sdk for ex) the device information. So i can't really make
>>>>> another
>>>>> > call to registration API. What i'd suggest is to have a separate
>>>>> endpoint
>>>>> > for metrics instead of having it coupled with registration endpoint.
>>>>> wdyt?
>>>>> >
>>>>> > ++
>>>>> >
>>>>> > Corinne
>>>>> >
>>>>> > On 4 May 2015 at 19:07, S?bastien Blanc <scm.blanc at gmail.com> wrote:
>>>>> >>
>>>>> >> Hi Corinne !
>>>>> >> We want to collect for both situations you described :)
>>>>> >>
>>>>> >> Envoy? de mon iPhone
>>>>> >>
>>>>> >> Le 4 mai 2015 ? 17:53, Corinne Krych <corinnekrych at gmail.com> a
>>>>> ?crit :
>>>>> >>
>>>>> >> Hello Sebi,
>>>>> >>
>>>>> >> After giving it a closer look, I've got a question for you: do we
>>>>> want to
>>>>> >> collect metrics only when an app is opened via push notification or
>>>>> do we
>>>>> >> also want to collect metrics when an app is brought to foreground
>>>>> by a push
>>>>> >> notification?
>>>>> >>
>>>>> >> ++
>>>>> >> Corinne
>>>>> >>
>>>>> >>
>>>>> >> On 4 May 2015 at 10:21, Corinne Krych <corinnekrych at gmail.com>
>>>>> wrote:
>>>>> >>>
>>>>> >>> Yeap
>>>>> >>> on it.
>>>>> >>>
>>>>> >>> On 30 April 2015 at 15:43, Sebastien Blanc <scm.blanc at gmail.com>
>>>>> wrote:
>>>>> >>>>
>>>>> >>>> Hi,
>>>>> >>>>
>>>>> >>>> The Advanced Analytics task[1] has a new PR[2] that has been
>>>>> rebased on
>>>>> >>>> the latest master and got a lot of polishing.
>>>>> >>>>
>>>>> >>>> Could the Client Tech Leads take a look at it [3] and review ?
>>>>> The only
>>>>> >>>> "breaking" change is the rename of the header's name that
>>>>> identifies a Push
>>>>> >>>> Notification, it's called now "aerogear-push-id"
>>>>> >>>>
>>>>> >>>> Seb
>>>>> >>>>
>>>>> >>>>
>>>>> >>>>
>>>>> >>>> [1] https://issues.jboss.org/browse/AGPUSH-971
>>>>> >>>> [2]
>>>>> https://github.com/aerogear/aerogear-unifiedpush-server/pull/540
>>>>> >>>> [3] Subtasks of https://issues.jboss.org/browse/AGPUSH-971
>>>>> >>>>
>>>>> >>>>
>>>>> >>>>
>>>>> >>>> _______________________________________________
>>>>> >>>> aerogear-dev mailing list
>>>>> >>>> aerogear-dev at lists.jboss.org
>>>>> >>>> https://lists.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
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Cheers,
>>>>>        Erik Jan
>>>>>
>>>>> _______________________________________________
>>>>> aerogear-dev mailing list
>>>>> aerogear-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> aerogear-dev mailing list
>>>> aerogear-dev at lists.jboss.org
>>>> https://lists.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
>



-- 
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/20150506/b56ed3e4/attachment-0001.html 

From scm.blanc at gmail.com  Wed May  6 06:28:38 2015
From: scm.blanc at gmail.com (=?utf-8?Q?S=C3=A9bastien_Blanc?=)
Date: Wed, 6 May 2015 12:28:38 +0200
Subject: [aerogear-dev] Metrics Endpoint (was: Re: Advanced Analtyics,
	new PR and call to the client tech leads)
In-Reply-To: <CAAg5f2Rf4UEc4mw5mgSidAzhnHWDP62zDbnnH68HVvC7ESTbSg@mail.gmail.com>
References: <CAAg5f2SVYYtv+hTcH=JkDkbjvGDyvLj4aG98HzY8nhK2uKnKRg@mail.gmail.com>
	<83B32C88-B549-48E5-9F1A-3300D079A251@gmail.com>
	<CAAg5f2Rf4UEc4mw5mgSidAzhnHWDP62zDbnnH68HVvC7ESTbSg@mail.gmail.com>
Message-ID: <E100C4B3-F798-437B-9F55-32AB73F1DABC@gmail.com>



Envoy? de mon iPhone

> Le 6 mai 2015 ? 11:52, Matthias Wessendorf <matzew at apache.org> a ?crit :
> 
> 
> 
>> On Wed, May 6, 2015 at 11:47 AM, S?bastien Blanc <scm.blanc at gmail.com> wrote:
>> 
>> 
>> Envoy? de mon iPhone
>> 
>>> Le 6 mai 2015 ? 11:38, Matthias Wessendorf <matzew at apache.org> a ?crit :
>>> 
>>> Hi,
>>> 
>>> as discussed on the previous thread, there will be a new endpoint to 'track' the "App opened/launched due to received push notification".
>>> 
>>> Internally, on the UPS, the Push Message has an ID, which get's append to the payload of the notification, like here:
>>> https://github.com/matzew/aerogear-unifiedpush-server/blob/analytics/push/sender/src/main/java/org/jboss/aerogear/unifiedpush/message/sender/APNsPushNotificationSender.java#L107-L108
>>> 
>>> On the client SDKs this will be read and a HTTP call made to the soon introduced MetricsEndpoint. Currently this info is send to the RegistrationEndpoint, including the deviceToken/registrationId. However, I think that the deviceToken/registrationId is currently not needed for metrics, since we are just interested in anonymous "app launched/opened due to push", and not a specific "DEVICE X did open, while DEVICE Y did not yet open".
>>> 
>>> So all we really need is the ID of the push notification, to be processed by our Metrics Service
>>> https://github.com/matzew/aerogear-unifiedpush-server/blob/analytics/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/registry/installations/InstallationRegistrationEndpoint.java#L128-L133
>>> 
>>> Therefore my proposal is have an endpoint:
>>> 
>>> PUT /metrics/pushmessage/{pushMessageID}
>>> 
>>> I think PUT is good/best, because there is nothing really created on the server, it's more updating the 'counter' on the existing PushMessageInformation object.
>>> 
>>> Thoughts?
>> Let's make sure it's still protected by basic auth using the variantId, we need to know which variant is hit. 
> 
> yes :-) 
>  
>> 
>> Skipping the registration endpoint we might miss metadata, like os version etc ... But for this first version it should not be a issue. 
> 
> I think that would be nice to have percentage of OS/OS version - it would be not too hard to have that included.
> 
> Are we, today, are already having a relationship between "app opened" and OS/OS_version? I don't really see that on the PR 
No but it "was" ready in case we wanted to add it.
> 
>> 
>>> -Matthias
>>> 
>>> 
>>>> On Tue, May 5, 2015 at 7:53 PM, Matthias Wessendorf <matzew at apache.org> wrote:
>>>> 
>>>> 
>>>>> On Tue, May 5, 2015 at 10:53 AM, Corinne Krych <corinnekrych at gmail.com> wrote:
>>>>> To give a bit of background on this background to foreground issue :))
>>>>> 
>>>>> Push Cordova plugin matches Cordova life cycle by storing some information locally see:
>>>>> https://github.com/aerogear/aerogear-cordova-push/blob/master/src/ios/AGPushPlugin.m#L82
>>>>> Doing so allows you to call multiple time registration, even when an app comes back from background to foreground. you can do it because you have stored locally all the information neede for registration.
>>>>> 
>>>>> But when dealing directly with native apps, the life cycle does not always goes through a registration.
>>>>> 
>>>>> To sort out this issue,we can:
>>>>> - either store locally at the ios-push lib level instead of doing it in Cordova plugin and then call registration API on all delegate methods (even though we don't want to register but just send the metrics)
>>>> 
>>>> based on summers comments, I thought about this - perhaps this is the way to go.
>>>> For sending metrics, we do not need to run the registration again, with the new endpoint in place. The iOS push SDK could call a (private) method and just deliver the metrics related info - that's splits the concerns and removes the need to call register endpoint on places where we do not really need it
>>>> 
>>>> -M
>>>> 
>>>> 
>>>>  
>>>>> - or leave the ios-push lib without any storage and provide a separate endpoint for sending metrics or changing categories.  
>>>>> 
>>>>> I'd go for the second option.
>>>>> 
>>>>> ++
>>>>> Corinne
>>>>> 
>>>>> 
>>>>>> On 5 May 2015 at 10:39, Erik Jan de Wit <edewit at redhat.com> wrote:
>>>>>> I agree with this and maybe we want even more functionality moved,
>>>>>> because also updating the categories is strange in a 'register'
>>>>>> method. Say for instance you want to change the categories your
>>>>>> interested in a developer has to call register again? And if I
>>>>>> understand Corinnes mail that will currently not even work on iOS.
>>>>>> 
>>>>>> For cordova I store the device info, because the lifecycle is
>>>>>> different, but that is okay it's an integration problem.
>>>>>> 
>>>>>> So updating the installation details should be a separate method that
>>>>>> also contains updating the categories. That way we have a better split
>>>>>> between a device that registers itself with UPS and updating the
>>>>>> subscription data.
>>>>>> 
>>>>>> 
>>>>>> On Tue, May 5, 2015 at 9:26 AM, Corinne Krych <corinnekrych at gmail.com> wrote:
>>>>>> > Hello Sebi,
>>>>>> >
>>>>>> >
>>>>>> > I've done an initial work on aerogear-ios-push [swift branch], adding a new
>>>>>> > parameter when doing the registration to pass the ag-push-id. See:
>>>>>> >
>>>>>> > https://github.com/aerogear/aerogear-ios-push/compare/aerogear:master...corinnekrych:AGPUSH-1232.analytics.push.notification?expand=1
>>>>>> >
>>>>>> > This client could be tested with HelloWorld. See:
>>>>>> >
>>>>>> > https://github.com/jboss-mobile/unified-push-helloworld/compare/jboss-mobile:swift...corinnekrych:AGPUSH-1232.analytics.push.notification?expand=1
>>>>>> >
>>>>>> > What is not covered is the background app coming to foreground through a
>>>>>> > push notification. If you look at HelloWorld:
>>>>>> >
>>>>>> > https://github.com/jboss-mobile/unified-push-helloworld/blob/f7d0a7e093327f9a84041910c4c2892280c88ffb/ios-swift/HelloWorldSwift/AppDelegate.swift#L152
>>>>>> >
>>>>>> > In iOS, when we go from background to foreground we don't go through
>>>>>> > registration API. The iOS push lib doesn't store locally (as opposed to
>>>>>> > windows sdk for ex) the device information. So i can't really make another
>>>>>> > call to registration API. What i'd suggest is to have a separate endpoint
>>>>>> > for metrics instead of having it coupled with registration endpoint. wdyt?
>>>>>> >
>>>>>> > ++
>>>>>> >
>>>>>> > Corinne
>>>>>> >
>>>>>> > On 4 May 2015 at 19:07, S?bastien Blanc <scm.blanc at gmail.com> wrote:
>>>>>> >>
>>>>>> >> Hi Corinne !
>>>>>> >> We want to collect for both situations you described :)
>>>>>> >>
>>>>>> >> Envoy? de mon iPhone
>>>>>> >>
>>>>>> >> Le 4 mai 2015 ? 17:53, Corinne Krych <corinnekrych at gmail.com> a ?crit :
>>>>>> >>
>>>>>> >> Hello Sebi,
>>>>>> >>
>>>>>> >> After giving it a closer look, I've got a question for you: do we want to
>>>>>> >> collect metrics only when an app is opened via push notification or do we
>>>>>> >> also want to collect metrics when an app is brought to foreground by a push
>>>>>> >> notification?
>>>>>> >>
>>>>>> >> ++
>>>>>> >> Corinne
>>>>>> >>
>>>>>> >>
>>>>>> >> On 4 May 2015 at 10:21, Corinne Krych <corinnekrych at gmail.com> wrote:
>>>>>> >>>
>>>>>> >>> Yeap
>>>>>> >>> on it.
>>>>>> >>>
>>>>>> >>> On 30 April 2015 at 15:43, Sebastien Blanc <scm.blanc at gmail.com> wrote:
>>>>>> >>>>
>>>>>> >>>> Hi,
>>>>>> >>>>
>>>>>> >>>> The Advanced Analytics task[1] has a new PR[2] that has been rebased on
>>>>>> >>>> the latest master and got a lot of polishing.
>>>>>> >>>>
>>>>>> >>>> Could the Client Tech Leads take a look at it [3] and review ? The only
>>>>>> >>>> "breaking" change is the rename of the header's name that identifies a Push
>>>>>> >>>> Notification, it's called now "aerogear-push-id"
>>>>>> >>>>
>>>>>> >>>> Seb
>>>>>> >>>>
>>>>>> >>>>
>>>>>> >>>>
>>>>>> >>>> [1] https://issues.jboss.org/browse/AGPUSH-971
>>>>>> >>>> [2] https://github.com/aerogear/aerogear-unifiedpush-server/pull/540
>>>>>> >>>> [3] Subtasks of https://issues.jboss.org/browse/AGPUSH-971
>>>>>> >>>>
>>>>>> >>>>
>>>>>> >>>>
>>>>>> >>>> _______________________________________________
>>>>>> >>>> aerogear-dev mailing list
>>>>>> >>>> aerogear-dev at lists.jboss.org
>>>>>> >>>> https://lists.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
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> Cheers,
>>>>>>        Erik Jan
>>>>>> 
>>>>>> _______________________________________________
>>>>>> aerogear-dev mailing list
>>>>>> aerogear-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> aerogear-dev mailing list
>>>>> aerogear-dev at lists.jboss.org
>>>>> https://lists.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/20150506/55e55d1c/attachment-0001.html 

From qmx at qmx.me  Wed May  6 14:27:52 2015
From: qmx at qmx.me (Douglas Campos)
Date: Wed, 6 May 2015 15:27:52 -0300
Subject: [aerogear-dev] Dealing with UPS Keycloak data post-datasource-split
Message-ID: <CAN-DfD5v6svHbP63QvhVHCzfKxY2Bmgy0Pq3jVYRND_jvKeN_w@mail.gmail.com>

Howdy y'all!

I'm revisiting migration strategies for UPS master, and we have a tough
situation to deal with.

Since we have moved keycloak to its own DataSource, there are KC leftovers
at UPS database which need to be cleaned up.

1) Any suggestions on how to provide a migration path?
  Since the tables are intertwined with UPS tables, it's not a matter of
doing a db dump/restore...
2) How to ensure we can safely get rid of the leftover tables on UPS
DataSource?
  I can easily provide migrations which just nuke the tables from the face
of the earth, but how to do this without data loss?

Thoughts?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20150506/120e00ce/attachment.html 

From matzew at apache.org  Wed May  6 21:26:20 2015
From: matzew at apache.org (Matthias Wessendorf)
Date: Thu, 7 May 2015 03:26:20 +0200
Subject: [aerogear-dev] Dealing with UPS Keycloak data
	post-datasource-split
In-Reply-To: <CAN-DfD5v6svHbP63QvhVHCzfKxY2Bmgy0Pq3jVYRND_jvKeN_w@mail.gmail.com>
References: <CAN-DfD5v6svHbP63QvhVHCzfKxY2Bmgy0Pq3jVYRND_jvKeN_w@mail.gmail.com>
Message-ID: <CAAg5f2Trqwrg46PwY4+ZtUR9ymRvSoX3f0rYr5uxO7t2oRHpoQ@mail.gmail.com>

On Wed, May 6, 2015 at 8:27 PM, Douglas Campos <qmx at qmx.me> wrote:

> Howdy y'all!
>
> I'm revisiting migration strategies for UPS master, and we have a tough
> situation to deal with.
>
> Since we have moved keycloak to its own DataSource, there are KC leftovers
> at UPS database which need to be cleaned up.
>
> 1) Any suggestions on how to provide a migration path?
>   Since the tables are intertwined with UPS tables, it's not a matter of
> doing a db dump/restore...
>

how are they intertwined? Is UPS stuff stored in KC tables, or vice versa?


> 2) How to ensure we can safely get rid of the leftover tables on UPS
> DataSource?
>   I can easily provide migrations which just nuke the tables from the face
> of the earth,
>

that's good, but


> but how to do this without data loss?
>

I don't know :-) I wonder if we just can not move the data to a new
datasource.





>
> Thoughts?
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.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/20150507/8d965c4e/attachment.html 

From matzew at apache.org  Wed May  6 21:54:03 2015
From: matzew at apache.org (Matthias Wessendorf)
Date: Thu, 7 May 2015 03:54:03 +0200
Subject: [aerogear-dev] Dealing with UPS Keycloak data
	post-datasource-split
In-Reply-To: <CAAg5f2Trqwrg46PwY4+ZtUR9ymRvSoX3f0rYr5uxO7t2oRHpoQ@mail.gmail.com>
References: <CAN-DfD5v6svHbP63QvhVHCzfKxY2Bmgy0Pq3jVYRND_jvKeN_w@mail.gmail.com>
	<CAAg5f2Trqwrg46PwY4+ZtUR9ymRvSoX3f0rYr5uxO7t2oRHpoQ@mail.gmail.com>
Message-ID: <CAAg5f2T7zOkVQU8oKptCOJCb1nd8Um9jLo-5FqTHSSufgzdrkA@mail.gmail.com>

How about the following, not optimal, proposal:

* get back to one data-source
* stick w/ Keycloak-1.1.0-final (in case updating to KC-1.2.0 makes above
item harder)

I understand that a separation of the two is needed on the longer run - it
would be good if that's something on our agenda post 1.1.0 e.g. for 1.2.0

I think the above is a 'work around', which I could live with and buys us
time to truly think about a perfect separation.






On Thu, May 7, 2015 at 3:26 AM, Matthias Wessendorf <matzew at apache.org>
wrote:

>
>
> On Wed, May 6, 2015 at 8:27 PM, Douglas Campos <qmx at qmx.me> wrote:
>
>> Howdy y'all!
>>
>> I'm revisiting migration strategies for UPS master, and we have a tough
>> situation to deal with.
>>
>> Since we have moved keycloak to its own DataSource, there are KC
>> leftovers at UPS database which need to be cleaned up.
>>
>> 1) Any suggestions on how to provide a migration path?
>>   Since the tables are intertwined with UPS tables, it's not a matter of
>> doing a db dump/restore...
>>
>
> how are they intertwined? Is UPS stuff stored in KC tables, or vice versa?
>
>
>> 2) How to ensure we can safely get rid of the leftover tables on UPS
>> DataSource?
>>   I can easily provide migrations which just nuke the tables from the
>> face of the earth,
>>
>
> that's good, but
>
>
>> but how to do this without data loss?
>>
>
> I don't know :-) I wonder if we just can not move the data to a new
> datasource.
>
>
>
>
>
>>
>> Thoughts?
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.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/20150507/ae908edd/attachment.html 

From qmx at qmx.me  Wed May  6 23:22:03 2015
From: qmx at qmx.me (Douglas Campos)
Date: Thu, 7 May 2015 00:22:03 -0300
Subject: [aerogear-dev] Dealing with UPS Keycloak data
	post-datasource-split
In-Reply-To: <CAAg5f2Trqwrg46PwY4+ZtUR9ymRvSoX3f0rYr5uxO7t2oRHpoQ@mail.gmail.com>
References: <CAN-DfD5v6svHbP63QvhVHCzfKxY2Bmgy0Pq3jVYRND_jvKeN_w@mail.gmail.com>
	<CAAg5f2Trqwrg46PwY4+ZtUR9ymRvSoX3f0rYr5uxO7t2oRHpoQ@mail.gmail.com>
Message-ID: <CAN-DfD65_++zPF1miik3EzJqZhsbsLENJC6WDKpaiufF_fR6aw@mail.gmail.com>

On Wed, May 6, 2015 at 10:26 PM, Matthias Wessendorf <matzew at apache.org>
wrote:

>
>
> On Wed, May 6, 2015 at 8:27 PM, Douglas Campos <qmx at qmx.me> wrote:
>
>> Howdy y'all!
>>
>> I'm revisiting migration strategies for UPS master, and we have a tough
>> situation to deal with.
>>
>> Since we have moved keycloak to its own DataSource, there are KC
>> leftovers at UPS database which need to be cleaned up.
>>
>> 1) Any suggestions on how to provide a migration path?
>>   Since the tables are intertwined with UPS tables, it's not a matter of
>> doing a db dump/restore...
>>
>
> how are they intertwined? Is UPS stuff stored in KC tables, or vice versa?
>

UPS tables live alongside KC tables on the same schema/database


>
>> 2) How to ensure we can safely get rid of the leftover tables on UPS
>> DataSource?
>>   I can easily provide migrations which just nuke the tables from the
>> face of the earth,
>>
>
> that's good, but
>
>
>> but how to do this without data loss?
>>
>
> I don't know :-) I wonder if we just can not move the data to a new
> datasource.
>

We can, but you know how risky data migration is :)

>
>
>
>
>
>>
>> Thoughts?
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/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/20150507/e85a36be/attachment.html 

From matzew at apache.org  Thu May  7 01:22:23 2015
From: matzew at apache.org (Matthias Wessendorf)
Date: Thu, 7 May 2015 07:22:23 +0200
Subject: [aerogear-dev] Dealing with UPS Keycloak data
	post-datasource-split
In-Reply-To: <CAN-DfD65_++zPF1miik3EzJqZhsbsLENJC6WDKpaiufF_fR6aw@mail.gmail.com>
References: <CAN-DfD5v6svHbP63QvhVHCzfKxY2Bmgy0Pq3jVYRND_jvKeN_w@mail.gmail.com>
	<CAAg5f2Trqwrg46PwY4+ZtUR9ymRvSoX3f0rYr5uxO7t2oRHpoQ@mail.gmail.com>
	<CAN-DfD65_++zPF1miik3EzJqZhsbsLENJC6WDKpaiufF_fR6aw@mail.gmail.com>
Message-ID: <CAAg5f2TkXzUEVdtMN6vG0RxuaYOtrf0f+=E+jZXbmiQ14Z-T8w@mail.gmail.com>

On Thursday, May 7, 2015, Douglas Campos <qmx at qmx.me> wrote:

>
>
> On Wed, May 6, 2015 at 10:26 PM, Matthias Wessendorf <matzew at apache.org
> <javascript:_e(%7B%7D,'cvml','matzew at apache.org');>> wrote:
>
>>
>>
>> On Wed, May 6, 2015 at 8:27 PM, Douglas Campos <qmx at qmx.me
>> <javascript:_e(%7B%7D,'cvml','qmx at qmx.me');>> wrote:
>>
>>> Howdy y'all!
>>>
>>> I'm revisiting migration strategies for UPS master, and we have a tough
>>> situation to deal with.
>>>
>>> Since we have moved keycloak to its own DataSource, there are KC
>>> leftovers at UPS database which need to be cleaned up.
>>>
>>> 1) Any suggestions on how to provide a migration path?
>>>   Since the tables are intertwined with UPS tables, it's not a matter of
>>> doing a db dump/restore...
>>>
>>
>> how are they intertwined? Is UPS stuff stored in KC tables, or vice versa?
>>
>
> UPS tables live alongside KC tables on the same schema/database
>
>
>>
>>> 2) How to ensure we can safely get rid of the leftover tables on UPS
>>> DataSource?
>>>   I can easily provide migrations which just nuke the tables from the
>>> face of the earth,
>>>
>>
>> that's good, but
>>
>>
>>> but how to do this without data loss?
>>>
>>
>> I don't know :-) I wonder if we just can not move the data to a new
>> datasource.
>>
>
> We can, but you know how risky data migration is :)
>

back to one schema, for 1.1.0 and do clean separation on 1.2.0?


>
>>
>>
>>
>>
>>>
>>> Thoughts?
>>>
>>> _______________________________________________
>>> 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
>>
>> _______________________________________________
>> 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/20150507/c56bcf01/attachment-0001.html 

From edewit at redhat.com  Thu May  7 03:58:57 2015
From: edewit at redhat.com (Erik Jan de Wit)
Date: Thu, 7 May 2015 09:58:57 +0200
Subject: [aerogear-dev] Dealing with UPS Keycloak data
	post-datasource-split
In-Reply-To: <CAAg5f2TkXzUEVdtMN6vG0RxuaYOtrf0f+=E+jZXbmiQ14Z-T8w@mail.gmail.com>
References: <CAN-DfD5v6svHbP63QvhVHCzfKxY2Bmgy0Pq3jVYRND_jvKeN_w@mail.gmail.com>
	<CAAg5f2Trqwrg46PwY4+ZtUR9ymRvSoX3f0rYr5uxO7t2oRHpoQ@mail.gmail.com>
	<CAN-DfD65_++zPF1miik3EzJqZhsbsLENJC6WDKpaiufF_fR6aw@mail.gmail.com>
	<CAAg5f2TkXzUEVdtMN6vG0RxuaYOtrf0f+=E+jZXbmiQ14Z-T8w@mail.gmail.com>
Message-ID: <CAO2B-faJG78yLH82NkLj2UWLpx3k9kxL6NZ12mbGJSRszOS47g@mail.gmail.com>

Even though keycloak and UPS used to share the schema I'm pretty sure
that no data from UPS has ended up in Keycloak and visa versa. Because
there is no direct hibernate keycloak class usage in UPS, therefore
there is no way for UPS to store data in keycloak tables.

So I propose to nuke the keycloak tables that are left over in the UPS schema.

On Thu, May 7, 2015 at 7:22 AM, Matthias Wessendorf <matzew at apache.org> wrote:
>
>
> On Thursday, May 7, 2015, Douglas Campos <qmx at qmx.me> wrote:
>>
>>
>>
>> On Wed, May 6, 2015 at 10:26 PM, Matthias Wessendorf <matzew at apache.org>
>> wrote:
>>>
>>>
>>>
>>> On Wed, May 6, 2015 at 8:27 PM, Douglas Campos <qmx at qmx.me> wrote:
>>>>
>>>> Howdy y'all!
>>>>
>>>> I'm revisiting migration strategies for UPS master, and we have a tough
>>>> situation to deal with.
>>>>
>>>> Since we have moved keycloak to its own DataSource, there are KC
>>>> leftovers at UPS database which need to be cleaned up.
>>>>
>>>> 1) Any suggestions on how to provide a migration path?
>>>>   Since the tables are intertwined with UPS tables, it's not a matter of
>>>> doing a db dump/restore...
>>>
>>>
>>> how are they intertwined? Is UPS stuff stored in KC tables, or vice
>>> versa?
>>
>>
>> UPS tables live alongside KC tables on the same schema/database
>>
>>>
>>>>
>>>> 2) How to ensure we can safely get rid of the leftover tables on UPS
>>>> DataSource?
>>>>   I can easily provide migrations which just nuke the tables from the
>>>> face of the earth,
>>>
>>>
>>> that's good, but
>>>
>>>>
>>>> but how to do this without data loss?
>>>
>>>
>>> I don't know :-) I wonder if we just can not move the data to a new
>>> datasource.
>>
>>
>> We can, but you know how risky data migration is :)
>
>
> back to one schema, for 1.1.0 and do clean separation on 1.2.0?
>
>>>
>>>
>>>
>>>
>>>
>>>>
>>>>
>>>> Thoughts?
>>>>
>>>> _______________________________________________
>>>> aerogear-dev mailing list
>>>> aerogear-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>>
>>>
>>>
>>> --
>>> Matthias Wessendorf
>>>
>>> blog: http://matthiaswessendorf.wordpress.com/
>>> sessions: http://www.slideshare.net/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



-- 
Cheers,
       Erik Jan

From edewit at redhat.com  Thu May  7 05:15:15 2015
From: edewit at redhat.com (Erik Jan de Wit)
Date: Thu, 7 May 2015 11:15:15 +0200
Subject: [aerogear-dev] PushPlugin release 1.0.3
Message-ID: <CAO2B-fbhsdS6DDGg-UgTJX-E+s09W-ospPWeA-GCB-Ba3Ldspw@mail.gmail.com>

Hi,

This is a bug fix release of the push plugin for your testing pleasure I've
updated the 1.0.x branch to test you can run:

cordova plugin add https://github.com/aerogear/aerogear-cordova-push.git\#1.0.x

Release notes:
Bug

   - [AGCORDOVA-38 <https://issues.jboss.org/browse/AGCORDOVA-38>] -
   Authorisation error iOS is to big

Feature Request

   - [AGCORDOVA-76 <https://issues.jboss.org/browse/AGCORDOVA-76>] - Update
   Push SDK to Android 1.0.1


-- 
Cheers,
       Erik Jan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20150507/545d39a3/attachment.html 

From matzew at apache.org  Thu May  7 07:35:47 2015
From: matzew at apache.org (Matthias Wessendorf)
Date: Thu, 7 May 2015 13:35:47 +0200
Subject: [aerogear-dev] UPS: Java Sender for alpha.2
In-Reply-To: <CAAg5f2RFYoqtr_ok=c95s-J2YOz6wbDH1c=7q2bycHQ5wZ6RcQ@mail.gmail.com>
References: <CAAg5f2Tm8mg36R5nT71yAxQDy=2H3kO9Ecqf69qTHv1L4vLC9g@mail.gmail.com>
	<1D09DF31-D2B4-4C36-A273-54AEE1E4B2F1@gmail.com>
	<CAAg5f2TZZk_P-V2nRhRhkVY0yEeyUd+SmMGKwT0iH6pdfR0NPw@mail.gmail.com>
	<CAEroY35LnKbQ7Dr_OyXPR93gYS=sgWP6k+x1AYkoESRkOSjF=Q@mail.gmail.com>
	<CAAg5f2TsOPT6AKmyBaHG3-eL1HWgfszwoSerKr2PaFtVD601wA@mail.gmail.com>
	<CAAg5f2RFYoqtr_ok=c95s-J2YOz6wbDH1c=7q2bycHQ5wZ6RcQ@mail.gmail.com>
Message-ID: <CAAg5f2QBq1=JRV2nCwxHRBvwUtmttpTVbNuJgrPZYPUosqeACg@mail.gmail.com>

Alright, this got pushed to maven central

-M

On Mon, May 4, 2015 at 2:45 PM, Matthias Wessendorf <matzew at apache.org>
wrote:

> Ok, folks here is the staging repo:
>
>
> https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-5450/
>
> -Matthias
>
> On Mon, May 4, 2015 at 12:49 PM, Matthias Wessendorf <matzew at apache.org>
> wrote:
>
>> +1
>> let me do it
>>
>> On Mon, May 4, 2015 at 12:42 PM, Luk?? Fry? <lukas.fryc at gmail.com> wrote:
>>
>>> If we release Sender Java Client alpha2, we should also fix
>>> https://issues.jboss.org/browse/AGPUSH-1377
>>>
>>> po 4. 5. 2015 v 12:39 odes?latel Matthias Wessendorf <matzew at apache.org>
>>> napsal:
>>>
>>> thanks for the heads up - I will give it a spin
>>>>
>>>> On Mon, May 4, 2015 at 12:31 PM, S?bastien Blanc <scm.blanc at gmail.com>
>>>> wrote:
>>>>
>>>>> Yes master is up to date with the latest push payload, should be good
>>>>> to release.
>>>>>
>>>>> Envoy? de mon iPhone
>>>>>
>>>>> Le 4 mai 2015 ? 12:08, Matthias Wessendorf <matzew at apache.org> a
>>>>> ?crit :
>>>>>
>>>>> Hi,
>>>>>
>>>>> w/ the release of the server, I think we should release the sender as
>>>>> well:
>>>>>
>>>>> https://github.com/aerogear/aerogear-unifiedpush-java-client/blob/master/pom.xml#L23
>>>>>
>>>>> Just wondering, is it up-to-date regarding push payload?
>>>>>
>>>>> --
>>>>> Matthias Wessendorf
>>>>>
>>>>> blog: http://matthiaswessendorf.wordpress.com/
>>>>> sessions: http://www.slideshare.net/mwessendorf
>>>>> twitter: http://twitter.com/mwessendorf
>>>>>
>>>>> _______________________________________________
>>>>> aerogear-dev mailing list
>>>>> aerogear-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> aerogear-dev mailing list
>>>>> aerogear-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Matthias Wessendorf
>>>>
>>>> blog: http://matthiaswessendorf.wordpress.com/
>>>> sessions: http://www.slideshare.net/mwessendorf
>>>> twitter: http://twitter.com/mwessendorf
>>>>  _______________________________________________
>>>> aerogear-dev mailing list
>>>> aerogear-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev at lists.jboss.org
>>> https://lists.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
>



-- 
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/20150507/6362888a/attachment.html 

From scm.blanc at gmail.com  Thu May  7 08:23:48 2015
From: scm.blanc at gmail.com (Sebastien Blanc)
Date: Thu, 7 May 2015 14:23:48 +0200
Subject: [aerogear-dev] UPS: Java Sender for alpha.2
In-Reply-To: <CAAg5f2QBq1=JRV2nCwxHRBvwUtmttpTVbNuJgrPZYPUosqeACg@mail.gmail.com>
References: <CAAg5f2Tm8mg36R5nT71yAxQDy=2H3kO9Ecqf69qTHv1L4vLC9g@mail.gmail.com>
	<1D09DF31-D2B4-4C36-A273-54AEE1E4B2F1@gmail.com>
	<CAAg5f2TZZk_P-V2nRhRhkVY0yEeyUd+SmMGKwT0iH6pdfR0NPw@mail.gmail.com>
	<CAEroY35LnKbQ7Dr_OyXPR93gYS=sgWP6k+x1AYkoESRkOSjF=Q@mail.gmail.com>
	<CAAg5f2TsOPT6AKmyBaHG3-eL1HWgfszwoSerKr2PaFtVD601wA@mail.gmail.com>
	<CAAg5f2RFYoqtr_ok=c95s-J2YOz6wbDH1c=7q2bycHQ5wZ6RcQ@mail.gmail.com>
	<CAAg5f2QBq1=JRV2nCwxHRBvwUtmttpTVbNuJgrPZYPUosqeACg@mail.gmail.com>
Message-ID: <CAD_dpu297Xu-pQbbti1st2Sa3aZyF3XF5YFmeGE0Hn4yM-JMtQ@mail.gmail.com>

FYI, I've done a PR that updates the Forge Addon for the Java Sender
https://github.com/aerogear/unifiedpush-forge-addon/pull/3


On Thu, May 7, 2015 at 1:35 PM, Matthias Wessendorf <matzew at apache.org>
wrote:

> Alright, this got pushed to maven central
>
> -M
>
> On Mon, May 4, 2015 at 2:45 PM, Matthias Wessendorf <matzew at apache.org>
> wrote:
>
>> Ok, folks here is the staging repo:
>>
>>
>> https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-5450/
>>
>> -Matthias
>>
>> On Mon, May 4, 2015 at 12:49 PM, Matthias Wessendorf <matzew at apache.org>
>> wrote:
>>
>>> +1
>>> let me do it
>>>
>>> On Mon, May 4, 2015 at 12:42 PM, Luk?? Fry? <lukas.fryc at gmail.com>
>>> wrote:
>>>
>>>> If we release Sender Java Client alpha2, we should also fix
>>>> https://issues.jboss.org/browse/AGPUSH-1377
>>>>
>>>> po 4. 5. 2015 v 12:39 odes?latel Matthias Wessendorf <matzew at apache.org>
>>>> napsal:
>>>>
>>>> thanks for the heads up - I will give it a spin
>>>>>
>>>>> On Mon, May 4, 2015 at 12:31 PM, S?bastien Blanc <scm.blanc at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Yes master is up to date with the latest push payload, should be good
>>>>>> to release.
>>>>>>
>>>>>> Envoy? de mon iPhone
>>>>>>
>>>>>> Le 4 mai 2015 ? 12:08, Matthias Wessendorf <matzew at apache.org> a
>>>>>> ?crit :
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> w/ the release of the server, I think we should release the sender as
>>>>>> well:
>>>>>>
>>>>>> https://github.com/aerogear/aerogear-unifiedpush-java-client/blob/master/pom.xml#L23
>>>>>>
>>>>>> Just wondering, is it up-to-date regarding push payload?
>>>>>>
>>>>>> --
>>>>>> Matthias Wessendorf
>>>>>>
>>>>>> blog: http://matthiaswessendorf.wordpress.com/
>>>>>> sessions: http://www.slideshare.net/mwessendorf
>>>>>> twitter: http://twitter.com/mwessendorf
>>>>>>
>>>>>> _______________________________________________
>>>>>> aerogear-dev mailing list
>>>>>> aerogear-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> aerogear-dev mailing list
>>>>>> aerogear-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Matthias Wessendorf
>>>>>
>>>>> blog: http://matthiaswessendorf.wordpress.com/
>>>>> sessions: http://www.slideshare.net/mwessendorf
>>>>> twitter: http://twitter.com/mwessendorf
>>>>>  _______________________________________________
>>>>> aerogear-dev mailing list
>>>>> aerogear-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>
>>>>
>>>> _______________________________________________
>>>> aerogear-dev mailing list
>>>> aerogear-dev at lists.jboss.org
>>>> https://lists.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
>>
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/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/20150507/6353c0b7/attachment-0001.html 

From qmx at qmx.me  Thu May  7 15:07:52 2015
From: qmx at qmx.me (Douglas Campos)
Date: Thu, 7 May 2015 16:07:52 -0300
Subject: [aerogear-dev] Dealing with UPS Keycloak data
	post-datasource-split
In-Reply-To: <CAO2B-faJG78yLH82NkLj2UWLpx3k9kxL6NZ12mbGJSRszOS47g@mail.gmail.com>
References: <CAN-DfD5v6svHbP63QvhVHCzfKxY2Bmgy0Pq3jVYRND_jvKeN_w@mail.gmail.com>
	<CAAg5f2Trqwrg46PwY4+ZtUR9ymRvSoX3f0rYr5uxO7t2oRHpoQ@mail.gmail.com>
	<CAN-DfD65_++zPF1miik3EzJqZhsbsLENJC6WDKpaiufF_fR6aw@mail.gmail.com>
	<CAAg5f2TkXzUEVdtMN6vG0RxuaYOtrf0f+=E+jZXbmiQ14Z-T8w@mail.gmail.com>
	<CAO2B-faJG78yLH82NkLj2UWLpx3k9kxL6NZ12mbGJSRszOS47g@mail.gmail.com>
Message-ID: <CAN-DfD56BbebJo9WafULey4rK__VHRSqP=Xomi6C6ComaUK5YA@mail.gmail.com>

On Thu, May 7, 2015 at 4:58 AM, Erik Jan de Wit <edewit at redhat.com> wrote:

> Even though keycloak and UPS used to share the schema I'm pretty sure
> that no data from UPS has ended up in Keycloak and visa versa. Because
> there is no direct hibernate keycloak class usage in UPS, therefore
> there is no way for UPS to store data in keycloak tables.
>
> So I propose to nuke the keycloak tables that are left over in the UPS
> schema.
>

Sure, what about the potential user data that might be still living there?
That's exactly why I'm bringing this to ag-dev :)


>
> On Thu, May 7, 2015 at 7:22 AM, Matthias Wessendorf <matzew at apache.org>
> wrote:
> >
> >
> > On Thursday, May 7, 2015, Douglas Campos <qmx at qmx.me> wrote:
> >>
> >>
> >>
> >> On Wed, May 6, 2015 at 10:26 PM, Matthias Wessendorf <matzew at apache.org
> >
> >> wrote:
> >>>
> >>>
> >>>
> >>> On Wed, May 6, 2015 at 8:27 PM, Douglas Campos <qmx at qmx.me> wrote:
> >>>>
> >>>> Howdy y'all!
> >>>>
> >>>> I'm revisiting migration strategies for UPS master, and we have a
> tough
> >>>> situation to deal with.
> >>>>
> >>>> Since we have moved keycloak to its own DataSource, there are KC
> >>>> leftovers at UPS database which need to be cleaned up.
> >>>>
> >>>> 1) Any suggestions on how to provide a migration path?
> >>>>   Since the tables are intertwined with UPS tables, it's not a matter
> of
> >>>> doing a db dump/restore...
> >>>
> >>>
> >>> how are they intertwined? Is UPS stuff stored in KC tables, or vice
> >>> versa?
> >>
> >>
> >> UPS tables live alongside KC tables on the same schema/database
> >>
> >>>
> >>>>
> >>>> 2) How to ensure we can safely get rid of the leftover tables on UPS
> >>>> DataSource?
> >>>>   I can easily provide migrations which just nuke the tables from the
> >>>> face of the earth,
> >>>
> >>>
> >>> that's good, but
> >>>
> >>>>
> >>>> but how to do this without data loss?
> >>>
> >>>
> >>> I don't know :-) I wonder if we just can not move the data to a new
> >>> datasource.
> >>
> >>
> >> We can, but you know how risky data migration is :)
> >
> >
> > back to one schema, for 1.1.0 and do clean separation on 1.2.0?
> >
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>>
> >>>>
> >>>> Thoughts?
> >>>>
> >>>> _______________________________________________
> >>>> aerogear-dev mailing list
> >>>> aerogear-dev at lists.jboss.org
> >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>> Matthias Wessendorf
> >>>
> >>> blog: http://matthiaswessendorf.wordpress.com/
> >>> sessions: http://www.slideshare.net/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
>
>
>
> --
> Cheers,
>        Erik Jan
> _______________________________________________
> 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/20150507/c3bf7ac6/attachment.html 

From matzew at apache.org  Thu May  7 15:10:23 2015
From: matzew at apache.org (Matthias Wessendorf)
Date: Thu, 7 May 2015 21:10:23 +0200
Subject: [aerogear-dev] Dealing with UPS Keycloak data
	post-datasource-split
In-Reply-To: <CAN-DfD56BbebJo9WafULey4rK__VHRSqP=Xomi6C6ComaUK5YA@mail.gmail.com>
References: <CAN-DfD5v6svHbP63QvhVHCzfKxY2Bmgy0Pq3jVYRND_jvKeN_w@mail.gmail.com>
	<CAAg5f2Trqwrg46PwY4+ZtUR9ymRvSoX3f0rYr5uxO7t2oRHpoQ@mail.gmail.com>
	<CAN-DfD65_++zPF1miik3EzJqZhsbsLENJC6WDKpaiufF_fR6aw@mail.gmail.com>
	<CAAg5f2TkXzUEVdtMN6vG0RxuaYOtrf0f+=E+jZXbmiQ14Z-T8w@mail.gmail.com>
	<CAO2B-faJG78yLH82NkLj2UWLpx3k9kxL6NZ12mbGJSRszOS47g@mail.gmail.com>
	<CAN-DfD56BbebJo9WafULey4rK__VHRSqP=Xomi6C6ComaUK5YA@mail.gmail.com>
Message-ID: <CAAg5f2ToDG+11Uar06DmPqLcxUitL6LSG7+cgfhrmhjvb4EZuQ@mail.gmail.com>

back to one schema, for 1.1.0 and do clean separation on 1.2.0?


On Thursday, May 7, 2015, Douglas Campos <qmx at qmx.me> wrote:

>
>
> On Thu, May 7, 2015 at 4:58 AM, Erik Jan de Wit <edewit at redhat.com
> <javascript:_e(%7B%7D,'cvml','edewit at redhat.com');>> wrote:
>
>> Even though keycloak and UPS used to share the schema I'm pretty sure
>> that no data from UPS has ended up in Keycloak and visa versa. Because
>> there is no direct hibernate keycloak class usage in UPS, therefore
>> there is no way for UPS to store data in keycloak tables.
>>
>> So I propose to nuke the keycloak tables that are left over in the UPS
>> schema.
>>
>
> Sure, what about the potential user data that might be still living there?
> That's exactly why I'm bringing this to ag-dev :)
>
>
>>
>> On Thu, May 7, 2015 at 7:22 AM, Matthias Wessendorf <matzew at apache.org
>> <javascript:_e(%7B%7D,'cvml','matzew at apache.org');>> wrote:
>> >
>> >
>> > On Thursday, May 7, 2015, Douglas Campos <qmx at qmx.me
>> <javascript:_e(%7B%7D,'cvml','qmx at qmx.me');>> wrote:
>> >>
>> >>
>> >>
>> >> On Wed, May 6, 2015 at 10:26 PM, Matthias Wessendorf <
>> matzew at apache.org <javascript:_e(%7B%7D,'cvml','matzew at apache.org');>>
>> >> wrote:
>> >>>
>> >>>
>> >>>
>> >>> On Wed, May 6, 2015 at 8:27 PM, Douglas Campos <qmx at qmx.me
>> <javascript:_e(%7B%7D,'cvml','qmx at qmx.me');>> wrote:
>> >>>>
>> >>>> Howdy y'all!
>> >>>>
>> >>>> I'm revisiting migration strategies for UPS master, and we have a
>> tough
>> >>>> situation to deal with.
>> >>>>
>> >>>> Since we have moved keycloak to its own DataSource, there are KC
>> >>>> leftovers at UPS database which need to be cleaned up.
>> >>>>
>> >>>> 1) Any suggestions on how to provide a migration path?
>> >>>>   Since the tables are intertwined with UPS tables, it's not a
>> matter of
>> >>>> doing a db dump/restore...
>> >>>
>> >>>
>> >>> how are they intertwined? Is UPS stuff stored in KC tables, or vice
>> >>> versa?
>> >>
>> >>
>> >> UPS tables live alongside KC tables on the same schema/database
>> >>
>> >>>
>> >>>>
>> >>>> 2) How to ensure we can safely get rid of the leftover tables on UPS
>> >>>> DataSource?
>> >>>>   I can easily provide migrations which just nuke the tables from the
>> >>>> face of the earth,
>> >>>
>> >>>
>> >>> that's good, but
>> >>>
>> >>>>
>> >>>> but how to do this without data loss?
>> >>>
>> >>>
>> >>> I don't know :-) I wonder if we just can not move the data to a new
>> >>> datasource.
>> >>
>> >>
>> >> We can, but you know how risky data migration is :)
>> >
>> >
>> > back to one schema, for 1.1.0 and do clean separation on 1.2.0?
>> >
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>>
>> >>>>
>> >>>> Thoughts?
>> >>>>
>> >>>> _______________________________________________
>> >>>> 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
>> >>>
>> >>> _______________________________________________
>> >>> 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
>> <javascript:_e(%7B%7D,'cvml','aerogear-dev at lists.jboss.org');>
>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>
>>
>> --
>> Cheers,
>>        Erik Jan
>> _______________________________________________
>> 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/20150507/509263e7/attachment.html 

From gorkem.ercan at gmail.com  Thu May  7 17:34:16 2015
From: gorkem.ercan at gmail.com (Gorkem Ercan)
Date: Thu, 07 May 2015 17:34:16 -0400
Subject: [aerogear-dev] PushPlugin release 1.0.3
In-Reply-To: <CAO2B-fbhsdS6DDGg-UgTJX-E+s09W-ospPWeA-GCB-Ba3Ldspw@mail.gmail.com>
References: <CAO2B-fbhsdS6DDGg-UgTJX-E+s09W-ospPWeA-GCB-Ba3Ldspw@mail.gmail.com>
Message-ID: <89BE9DA2-3B5A-439D-9C8E-7DC1E5EA0789@gmail.com>


Eric,
Can we make the id on plugin.xml and the name on the package.json to 
match each other. This is probably not causing any trouble because of 
the Cordova CLI mapper but I think on the long term it is best to have a 
single one.

I think this applies to the other aerogear cordova plugins too.
--
Gorkem


On 7 May 2015, at 5:15, Erik Jan de Wit wrote:

> Hi,
>
> This is a bug fix release of the push plugin for your testing pleasure 
> I've
> updated the 1.0.x branch to test you can run:
>
> cordova plugin add 
> https://github.com/aerogear/aerogear-cordova-push.git\#1.0.x
>
> Release notes:
> Bug
>
> - [AGCORDOVA-38 <https://issues.jboss.org/browse/AGCORDOVA-38>] -
> Authorisation error iOS is to big
>
> Feature Request
>
> - [AGCORDOVA-76 <https://issues.jboss.org/browse/AGCORDOVA-76>] - 
> Update
> Push SDK to Android 1.0.1
>
>
> -- 
> Cheers,
>     Erik Jan
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev

From dpassos at redhat.com  Thu May  7 17:58:50 2015
From: dpassos at redhat.com (Daniel Passos)
Date: Thu, 7 May 2015 18:58:50 -0300
Subject: [aerogear-dev] Metrics Endpoint (was: Re: Advanced Analtyics,
 new PR and call to the client tech leads)
In-Reply-To: <CAAg5f2SVYYtv+hTcH=JkDkbjvGDyvLj4aG98HzY8nhK2uKnKRg@mail.gmail.com>
References: <CAAg5f2SVYYtv+hTcH=JkDkbjvGDyvLj4aG98HzY8nhK2uKnKRg@mail.gmail.com>
Message-ID: <CADF=h2vfetc39f7xJyygHE5uj531tUc3xtzZu9=NePLD7DBtNg@mail.gmail.com>

Just to be clear, we are talking about metrics for messages delivered
(received on device) or about really read/open?

Because in Android land is not possible know when message was read/opened.
We delegate how the message will be delivered/showed to the
MessageHandler[1] and we don't have access to it.

Today we only have access when the message is delivered. Basically we
receive the message in a AeroGearGCMMessageReceiver[2] do some checks and
push the message for all Handles registered[3][4]

[1]
https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/MessageHandler.java
[2]
https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/gcm/AeroGearGCMMessageReceiver.java
[3]
https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/RegistrarManager.java#L118
[4]
https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/RegistrarManager.java#L130

-- Passos


On Wed, May 6, 2015 at 6:38 AM, Matthias Wessendorf <matzew at apache.org>
wrote:

> Hi,
>
> as discussed on the previous thread, there will be a new endpoint to
> 'track' the "App opened/launched due to received push notification".
>
> Internally, on the UPS, the Push Message has an ID, which get's append to
> the payload of the notification, like here:
>
> https://github.com/matzew/aerogear-unifiedpush-server/blob/analytics/push/sender/src/main/java/org/jboss/aerogear/unifiedpush/message/sender/APNsPushNotificationSender.java#L107-L108
>
> On the client SDKs this will be read and a HTTP call made to the soon
> introduced MetricsEndpoint. Currently this info is send to the
> RegistrationEndpoint, including the deviceToken/registrationId. However, I
> think that the deviceToken/registrationId is currently not needed for
> metrics, since we are just interested in anonymous "app launched/opened due
> to push", and not a specific "DEVICE X did open, while DEVICE Y did not yet
> open".
>
> So all we really need is the ID of the push notification, to be processed
> by our Metrics Service
>
> https://github.com/matzew/aerogear-unifiedpush-server/blob/analytics/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/registry/installations/InstallationRegistrationEndpoint.java#L128-L133
>
> Therefore my proposal is have an endpoint:
>
> PUT /metrics/pushmessage/{pushMessageID}
>
> I think PUT is good/best, because there is nothing really created on the
> server, it's more updating the 'counter' on the existing
> PushMessageInformation object.
>
> Thoughts?
> -Matthias
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20150507/c85d2242/attachment-0001.html 

From qmx at qmx.me  Fri May  8 00:08:09 2015
From: qmx at qmx.me (Douglas Campos)
Date: Fri, 8 May 2015 01:08:09 -0300
Subject: [aerogear-dev] Dealing with UPS Keycloak data
	post-datasource-split
In-Reply-To: <CAAg5f2TkXzUEVdtMN6vG0RxuaYOtrf0f+=E+jZXbmiQ14Z-T8w@mail.gmail.com>
References: <CAN-DfD5v6svHbP63QvhVHCzfKxY2Bmgy0Pq3jVYRND_jvKeN_w@mail.gmail.com>
	<CAAg5f2Trqwrg46PwY4+ZtUR9ymRvSoX3f0rYr5uxO7t2oRHpoQ@mail.gmail.com>
	<CAN-DfD65_++zPF1miik3EzJqZhsbsLENJC6WDKpaiufF_fR6aw@mail.gmail.com>
	<CAAg5f2TkXzUEVdtMN6vG0RxuaYOtrf0f+=E+jZXbmiQ14Z-T8w@mail.gmail.com>
Message-ID: <CAN-DfD4E9HavBrkBSoreVXcOnCFzwhNOwWPkFyqFDkyEGK8ASw@mail.gmail.com>

On Thu, May 7, 2015 at 2:22 AM, Matthias Wessendorf <matzew at apache.org>
wrote:

>
> back to one schema, for 1.1.0 and do clean separation on 1.2.0?
>

Worksforme(tm)

+1
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20150508/526cf913/attachment.html 

From matzew at apache.org  Fri May  8 01:10:43 2015
From: matzew at apache.org (Matthias Wessendorf)
Date: Fri, 8 May 2015 07:10:43 +0200
Subject: [aerogear-dev] Metrics Endpoint (was: Re: Advanced Analtyics,
 new PR and call to the client tech leads)
In-Reply-To: <CADF=h2vfetc39f7xJyygHE5uj531tUc3xtzZu9=NePLD7DBtNg@mail.gmail.com>
References: <CAAg5f2SVYYtv+hTcH=JkDkbjvGDyvLj4aG98HzY8nhK2uKnKRg@mail.gmail.com>
	<CADF=h2vfetc39f7xJyygHE5uj531tUc3xtzZu9=NePLD7DBtNg@mail.gmail.com>
Message-ID: <CAAg5f2QqLCmJjQAr9nJN-aG_4z-yp1p=G292aYEfUFTq=_CnRw@mail.gmail.com>

On Thu, May 7, 2015 at 11:58 PM, Daniel Passos <dpassos at redhat.com> wrote:

> Just to be clear, we are talking about metrics for messages delivered
> (received on device) or about really read/open?
>
> Because in Android land is not possible know when message was read/opened.
> We delegate how the message will be delivered/showed to the
> MessageHandler[1] and we don't have access to it.
>

when the user clicks on the message, the app opens. That's what we track w/
this PR, not the actual: I read the message - more "App was opened due to
push", see:
https://issues.jboss.org/browse/AGPUSH-971


>
> Today we only have access when the message is delivered. Basically we
> receive the message in a AeroGearGCMMessageReceiver[2] do some checks and
> push the message for all Handles registered[3][4]
>
> [1]
> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/MessageHandler.java
> [2]
> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/gcm/AeroGearGCMMessageReceiver.java
> [3]
> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/RegistrarManager.java#L118
> [4]
> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/RegistrarManager.java#L130
>
> -- Passos
>
>
> On Wed, May 6, 2015 at 6:38 AM, Matthias Wessendorf <matzew at apache.org>
> wrote:
>
>> Hi,
>>
>> as discussed on the previous thread, there will be a new endpoint to
>> 'track' the "App opened/launched due to received push notification".
>>
>> Internally, on the UPS, the Push Message has an ID, which get's append to
>> the payload of the notification, like here:
>>
>> https://github.com/matzew/aerogear-unifiedpush-server/blob/analytics/push/sender/src/main/java/org/jboss/aerogear/unifiedpush/message/sender/APNsPushNotificationSender.java#L107-L108
>>
>> On the client SDKs this will be read and a HTTP call made to the soon
>> introduced MetricsEndpoint. Currently this info is send to the
>> RegistrationEndpoint, including the deviceToken/registrationId. However, I
>> think that the deviceToken/registrationId is currently not needed for
>> metrics, since we are just interested in anonymous "app launched/opened due
>> to push", and not a specific "DEVICE X did open, while DEVICE Y did not yet
>> open".
>>
>> So all we really need is the ID of the push notification, to be processed
>> by our Metrics Service
>>
>> https://github.com/matzew/aerogear-unifiedpush-server/blob/analytics/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/registry/installations/InstallationRegistrationEndpoint.java#L128-L133
>>
>> Therefore my proposal is have an endpoint:
>>
>> PUT /metrics/pushmessage/{pushMessageID}
>>
>> I think PUT is good/best, because there is nothing really created on the
>> server, it's more updating the 'counter' on the existing
>> PushMessageInformation object.
>>
>> Thoughts?
>> -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/20150508/96018018/attachment.html 

From matzew at apache.org  Fri May  8 06:08:42 2015
From: matzew at apache.org (Matthias Wessendorf)
Date: Fri, 8 May 2015 12:08:42 +0200
Subject: [aerogear-dev] Dealing with UPS Keycloak data
	post-datasource-split
In-Reply-To: <CAN-DfD4E9HavBrkBSoreVXcOnCFzwhNOwWPkFyqFDkyEGK8ASw@mail.gmail.com>
References: <CAN-DfD5v6svHbP63QvhVHCzfKxY2Bmgy0Pq3jVYRND_jvKeN_w@mail.gmail.com>
	<CAAg5f2Trqwrg46PwY4+ZtUR9ymRvSoX3f0rYr5uxO7t2oRHpoQ@mail.gmail.com>
	<CAN-DfD65_++zPF1miik3EzJqZhsbsLENJC6WDKpaiufF_fR6aw@mail.gmail.com>
	<CAAg5f2TkXzUEVdtMN6vG0RxuaYOtrf0f+=E+jZXbmiQ14Z-T8w@mail.gmail.com>
	<CAN-DfD4E9HavBrkBSoreVXcOnCFzwhNOwWPkFyqFDkyEGK8ASw@mail.gmail.com>
Message-ID: <CAAg5f2S8JjYp5nsBqbazrOC8tC8x1e-iTB-G=GTiAnQ3vO2MdQ@mail.gmail.com>

Hi Doug,



On Fri, May 8, 2015 at 6:08 AM, Douglas Campos <qmx at qmx.me> wrote:

>
>
> On Thu, May 7, 2015 at 2:22 AM, Matthias Wessendorf <matzew at apache.org>
> wrote:
>
>>
>> back to one schema, for 1.1.0 and do clean separation on 1.2.0?
>>
>
> Worksforme(tm)
>
> +1
>

ok, cool - I'd say - let's do that.

So, since the KC part (e.g. new Keycloak versions), is covered by
themselves, something like this [1] is not a huge issue, right? At least
that's my understanding/assumption.

Related, we already have a vage epic to cover the separation, I have moved
that to 1.2.0

[1] https://github.com/aerogear/aerogear-unifiedpush-server/pull/547
[2] https://issues.jboss.org/browse/AGPUSH-1047



>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.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/20150508/ea591ffc/attachment.html 

From bruno at abstractj.org  Fri May  8 08:23:37 2015
From: bruno at abstractj.org (Bruno Oliveira)
Date: Fri, 8 May 2015 09:23:37 -0300
Subject: [aerogear-dev] Release of aerogear-parent with Keycloak 1.2.0.CR1
Message-ID: <20150508122337.GA90908@abstractj.org>

Happy Friday everyone,

A New release of aerogear-parent was staged at
https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-5484.

The update was necessary to fix
https://issues.jboss.org/browse/AGPUSH-1352.

I'm considering to release it on Monday, after some feedback. If you want
the release to be postoned to another day, let me know.

Thanks Matthias and Christos for testing the change.

--

abstractj
PGP: 0x84DC9914

From matzew at apache.org  Fri May  8 08:39:36 2015
From: matzew at apache.org (Matthias Wessendorf)
Date: Fri, 8 May 2015 14:39:36 +0200
Subject: [aerogear-dev] Release of aerogear-parent with Keycloak
	1.2.0.CR1
In-Reply-To: <20150508122337.GA90908@abstractj.org>
References: <20150508122337.GA90908@abstractj.org>
Message-ID: <CAAg5f2QptEBt5gOkTGxHKw0Ch-akDGxxBF++SC4=xMuqruHfKA@mail.gmail.com>

+1

On Fri, May 8, 2015 at 2:23 PM, Bruno Oliveira <bruno at abstractj.org> wrote:

> Happy Friday everyone,
>
> A New release of aerogear-parent was staged at
>
> https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-5484
> .
>
> The update was necessary to fix
> https://issues.jboss.org/browse/AGPUSH-1352.
>
> I'm considering to release it on Monday, after some feedback. If you want
> the release to be postoned to another day, let me know.
>
> Thanks Matthias and Christos for testing the change.
>
> --
>
> abstractj
> PGP: 0x84DC9914
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.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/20150508/fb7d9695/attachment.html 

From kpiwko at redhat.com  Mon May 11 04:50:13 2015
From: kpiwko at redhat.com (Karel Piwko)
Date: Mon, 11 May 2015 10:50:13 +0200
Subject: [aerogear-dev] UPS as WildFly Subsystem (was: UPS using JMS)
In-Reply-To: <CAEroY34r7puxiF0jZ78p-KzT7+bT90J6+BS9Q0EgJQHmRdD3Vg@mail.gmail.com>
References: <CAEroY34bhcGwsOf8RqBZt+M80nk+zvtNZ47Uwxrh9BLTOww4uQ@mail.gmail.com>
	<CAD_dpu3rnas6T7rn5SMotfWop5BFYkDvi0KfjB476wkysubCzw@mail.gmail.com>
	<CAAg5f2RVPhHT-iB5pWwg93F9ivcoMH69X_WuYVNa6FFR+sz-Fw@mail.gmail.com>
	<CAEroY37bqjTWEP3JhZshDJxdHqj4fLXb2LLBUVAqjEr_S0Zugg@mail.gmail.com>
	<CAAg5f2S3huJtYXW0ms7nHUwmnOLD9btcYnJzz200+s8yt1=Heg@mail.gmail.com>
	<CAEroY34r7puxiF0jZ78p-KzT7+bT90J6+BS9Q0EgJQHmRdD3Vg@mail.gmail.com>
Message-ID: <CAPXQee52T16XGe4ZS+R9V0tFiDX_V-9sj16k1w0YfhB+TaPWVw@mail.gmail.com>

On Tue, Apr 7, 2015 at 9:49 AM, Luk?? Fry? <lukas.fryc at gmail.com> wrote:

> I reached out to Stian in order to fully understand the "Why" behind
> Keycloak offering a subsystem, and he identified two benefits:
>
> * smaller appliance downloads
> * easier to patch modules than monolithic WAR
>
> Can you see anything else?
>

* Easier configuration. Subsystem can provide both CLI and GUI
configuration layer for very small effort.

https://docs.jboss.org/author/display/WFLY8/Example+subsystem


>
> The question is how much relevant are these benefits for us, since we
> depend much more on Java EE (especially with JMS coming).
>
>
>
> In case of UPS, we can definitely strip some download Megabytes for
> (potential) appliance distribution (good for microservices oriented
> architectures),
>
> while still providing installation of subsystem to existing Wildfly EE
> instances. We can continue shipping WAR just for sake of backwards
> compatibility in case it will appear to be effortless.
>
>
>
> However I agree that UPS as WF subsystem is a direction worth to explore!
>
> ~ Lukas
>
>
>
>
>
> ?t 7. 4. 2015 v 9:18 odes?latel Matthias Wessendorf <matzew at apache.org>
> napsal:
>
>> Not sure, I think that was my question though
>>
>> On Tue, Apr 7, 2015 at 9:08 AM, Luk?? Fry? <lukas.fryc at gmail.com> wrote:
>>
>>> Do I read well that the subsystem would be the ONLY distribution
>>> mechanism?
>>>
>>> Created https://issues.jboss.org/browse/AGPUSH-1354 btw. Feel free to
>>> comment there.
>>>
>>> ~ Lukas
>>>
>>> p? 3. 4. 2015 v 13:50 odes?latel Matthias Wessendorf <matzew at apache.org>
>>> napsal:
>>>
>>> Cool stuff
>>>>
>>>> I am totally fine having this tied ti wf/eap
>>>>
>>>> wondering: at some point, should we offer a dist as (only) subststem
>>>> for wf/eap?
>>>>
>>>>
>>>> On Friday, April 3, 2015, Sebastien Blanc <scm.blanc at gmail.com> wrote:
>>>>
>>>>> That all sounds very good :)
>>>>> Thanks for the headupate, I will soon give it a try.
>>>>>
>>>>> On Fri, Apr 3, 2015 at 10:34 AM, Luk?? Fry? <lukas.fryc at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hi guys,
>>>>>>
>>>>>> so as outlined in previous thread [1], I have prototyped a JMS
>>>>>> batching approach for push message delivery.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> We've discussed the approach with Matthias, Mirek Novak and Ondrej
>>>>>> Chaloupka (EAP QE & JMS/JTA experts, thank you guys!) and these documents
>>>>>> describes a concept that we have came with:
>>>>>>
>>>>>> Diagram:
>>>>>> https://docs.google.com/a/fryc.eu/drawings/d/13IsJWPSJNYXtst-UVxQYmzH36C_EXQMYYr_jcu7nFmE/edit?usp=sharing
>>>>>>
>>>>>> Text Doc:
>>>>>> https://docs.google.com/document/d/1X65P_U9O62Z5JZhKi9ZvBuZU1OrL4pNHNddlzJK6rMg/edit?usp=sharing
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Implementation-wise, I've so far prototyped the messaging part (split
>>>>>> SenderService functionality to two subsequent queues with MDBs as shown on
>>>>>> diagram),
>>>>>>
>>>>>> but that's just a start, since we must configure it appropriately for
>>>>>> efficiency (queue configuration and batch sizes) and verify that
>>>>>> configuration works as expected,
>>>>>>
>>>>>> the prototype lives on a branch (unpolished, to be squashed later):
>>>>>> https://github.com/lfryc/aerogear-unifiedpush-server/tree/jms-batching
>>>>>>
>>>>>> Off course, you can play with it already. :-)
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Apart from the new requirement of using Java EE full profile (JMS),
>>>>>> the prototype leverages implementation-specific configurations and APIs:
>>>>>>
>>>>>>    - org.hibernate.Query for token streaming / batch fetching
>>>>>>    - HornetQ configurations of queue size, blocking behavior and
>>>>>>    message de-duplication
>>>>>>
>>>>>> That pretty much binds us to WildFly/EAP - we can tweak it to run on
>>>>>> any compliant app server, but without specific configurations it won't work
>>>>>> properly.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Once configured and functionally tested (that can even wait for Beta2
>>>>>> I guess),
>>>>>>
>>>>>> we can cooperate with Mobile QE on testing (Stefan, Adam), their test
>>>>>> suite contains mocks of APNS/GCM against which we can load test.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Cheers!
>>>>>>
>>>>>> ~ Lukas
>>>>>>
>>>>>>
>>>>>> [1]
>>>>>> http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-UnifiedPush-new-requirement-JMS-Java-EE-Full-profile-tp11268.html
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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/20150511/df1b2f76/attachment-0001.html 

From matzew at apache.org  Mon May 11 08:27:46 2015
From: matzew at apache.org (Matthias Wessendorf)
Date: Mon, 11 May 2015 14:27:46 +0200
Subject: [aerogear-dev] FYI: Docker compose for our DBs
Message-ID: <CAAg5f2S1wS3gME7s4aBzBYo6N+gM-bzxKfwYLSFEdq5cm9p+bg@mail.gmail.com>

Hi,

atm we have (on master) two separeate DS. For testing I ususally spin them
up via two different 'docker run' commands.

I tried getting that into docker componse, using a single file:
https://gist.github.com/matzew/7314ecda1d42cf08f976

Sure, the setup of the DS needs to follow according the exposed MySQL ports
(and the Docker IP address).

Perhaps it's helpful

-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/20150511/3efffb97/attachment.html 

From matzew at apache.org  Mon May 11 09:07:24 2015
From: matzew at apache.org (Matthias Wessendorf)
Date: Mon, 11 May 2015 15:07:24 +0200
Subject: [aerogear-dev] Dealing with UPS Keycloak data
	post-datasource-split
In-Reply-To: <CAAg5f2S8JjYp5nsBqbazrOC8tC8x1e-iTB-G=GTiAnQ3vO2MdQ@mail.gmail.com>
References: <CAN-DfD5v6svHbP63QvhVHCzfKxY2Bmgy0Pq3jVYRND_jvKeN_w@mail.gmail.com>
	<CAAg5f2Trqwrg46PwY4+ZtUR9ymRvSoX3f0rYr5uxO7t2oRHpoQ@mail.gmail.com>
	<CAN-DfD65_++zPF1miik3EzJqZhsbsLENJC6WDKpaiufF_fR6aw@mail.gmail.com>
	<CAAg5f2TkXzUEVdtMN6vG0RxuaYOtrf0f+=E+jZXbmiQ14Z-T8w@mail.gmail.com>
	<CAN-DfD4E9HavBrkBSoreVXcOnCFzwhNOwWPkFyqFDkyEGK8ASw@mail.gmail.com>
	<CAAg5f2S8JjYp5nsBqbazrOC8tC8x1e-iTB-G=GTiAnQ3vO2MdQ@mail.gmail.com>
Message-ID: <CAAg5f2T1V92Fe1h2XdXPMhvQ2kY8YDY+M=iJEHKFWff-VPVijA@mail.gmail.com>

On Fri, May 8, 2015 at 12:08 PM, Matthias Wessendorf <matzew at apache.org>
wrote:

> Hi Doug,
>
>
>
> On Fri, May 8, 2015 at 6:08 AM, Douglas Campos <qmx at qmx.me> wrote:
>
>>
>>
>> On Thu, May 7, 2015 at 2:22 AM, Matthias Wessendorf <matzew at apache.org>
>> wrote:
>>
>>>
>>> back to one schema, for 1.1.0 and do clean separation on 1.2.0?
>>>
>>
>> Worksforme(tm)
>>
>> +1
>>
>
> ok, cool - I'd say - let's do that.
>
> So, since the KC part (e.g. new Keycloak versions), is covered by
> themselves, something like this [1] is not a huge issue, right? At least
> that's my understanding/assumption.
>

FYI - the KC version on master is now on 1.2.0.CR1 - but incase this has
_negative_ effect for your migration work, please let us know. I think
going back to an older version of KC is not a show stopper at all

-M

>
> Related, we already have a vage epic to cover the separation, I have moved
> that to 1.2.0
>
> [1] https://github.com/aerogear/aerogear-unifiedpush-server/pull/547
> [2] https://issues.jboss.org/browse/AGPUSH-1047
>
>
>
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.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/20150511/b0ae7ddd/attachment.html 

From bruno at abstractj.org  Mon May 11 09:10:15 2015
From: bruno at abstractj.org (Bruno Oliveira)
Date: Mon, 11 May 2015 10:10:15 -0300
Subject: [aerogear-dev] What's new this week on Security?
Message-ID: <20150511131015.GA99477@abstractj.org>

Last week we tested the integration with Keycloak 1.2.0.CR1 which fixes
https://issues.jboss.org/browse/AGPUSH-1352. On Sunday, I merged the updates were
merged into UPS.

Today you're free to test our brand new security pepper sauce.

Have fun

--

abstractj
PGP: 0x84DC9914

From dpassos at redhat.com  Mon May 11 09:22:15 2015
From: dpassos at redhat.com (Daniel Passos)
Date: Mon, 11 May 2015 10:22:15 -0300
Subject: [aerogear-dev] What's new this week on AeroGear Android?
Message-ID: <CADF=h2tdY12SxS7_qKb3fn14_mvkWBa3Y8v2h8bTPXC8UG3jPg@mail.gmail.com>

Last week

We started to change[1] our Offline PoC to use registration like our other
libraries
This week

We will work on the UPS metrics. See the thread about it here[2] on
maillist and track the progress on Jira[3]

[1] https://github.com/aerogear/aerogear-android-offline/pull/5
[2]
http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Metrics-Endpoint-was-Re-Advanced-Analtyics-new-PR-and-call-to-the-client-tech-leads-td11581.html
[3] https://issues.jboss.org/browse/AGPUSH-1234
?
-- 
-- Passos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20150511/f3efd287/attachment.html 

From dpassos at redhat.com  Mon May 11 09:30:32 2015
From: dpassos at redhat.com (Daniel Passos)
Date: Mon, 11 May 2015 10:30:32 -0300
Subject: [aerogear-dev] Metrics Endpoint (was: Re: Advanced Analtyics,
 new PR and call to the client tech leads)
In-Reply-To: <CAAg5f2QqLCmJjQAr9nJN-aG_4z-yp1p=G292aYEfUFTq=_CnRw@mail.gmail.com>
References: <CAAg5f2SVYYtv+hTcH=JkDkbjvGDyvLj4aG98HzY8nhK2uKnKRg@mail.gmail.com>
	<CADF=h2vfetc39f7xJyygHE5uj531tUc3xtzZu9=NePLD7DBtNg@mail.gmail.com>
	<CAAg5f2QqLCmJjQAr9nJN-aG_4z-yp1p=G292aYEfUFTq=_CnRw@mail.gmail.com>
Message-ID: <CADF=h2s+VH-UtHkiEA68MKhD=K0HjNzV+6iS1R88Q4nU9-=qew@mail.gmail.com>

On Fri, May 8, 2015 at 2:10 AM, Matthias Wessendorf <matzew at apache.org>
wrote:

>
>
> On Thu, May 7, 2015 at 11:58 PM, Daniel Passos <dpassos at redhat.com> wrote:
>
>> Just to be clear, we are talking about metrics for messages delivered
>> (received on device) or about really read/open?
>>
>> Because in Android land is not possible know when message was
>> read/opened. We delegate how the message will be delivered/showed to the
>> MessageHandler[1] and we don't have access to it.
>>
>
> when the user clicks on the message, the app opens. That's what we track
> w/ this PR, not the actual: I read the message - more "App was opened due
> to push", see:
> https://issues.jboss.org/browse/AGPUSH-971
>

I can't do that. I can't do an action when app was opened. To do that we
would need to create our own application[1] class, and all projects would
need to extend it. As I have told in my previous email, for now I only can
do something when the message is delivered to the device.

[1] http://developer.android.com/reference/android/app/Application.html


>
>>
>> Today we only have access when the message is delivered. Basically we
>> receive the message in a AeroGearGCMMessageReceiver[2] do some checks and
>> push the message for all Handles registered[3][4]
>>
>> [1]
>> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/MessageHandler.java
>> [2]
>> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/gcm/AeroGearGCMMessageReceiver.java
>> [3]
>> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/RegistrarManager.java#L118
>> [4]
>> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/RegistrarManager.java#L130
>>
>> -- Passos
>>
>>
>> On Wed, May 6, 2015 at 6:38 AM, Matthias Wessendorf <matzew at apache.org>
>> wrote:
>>
>>> Hi,
>>>
>>> as discussed on the previous thread, there will be a new endpoint to
>>> 'track' the "App opened/launched due to received push notification".
>>>
>>> Internally, on the UPS, the Push Message has an ID, which get's append
>>> to the payload of the notification, like here:
>>>
>>> https://github.com/matzew/aerogear-unifiedpush-server/blob/analytics/push/sender/src/main/java/org/jboss/aerogear/unifiedpush/message/sender/APNsPushNotificationSender.java#L107-L108
>>>
>>> On the client SDKs this will be read and a HTTP call made to the soon
>>> introduced MetricsEndpoint. Currently this info is send to the
>>> RegistrationEndpoint, including the deviceToken/registrationId. However, I
>>> think that the deviceToken/registrationId is currently not needed for
>>> metrics, since we are just interested in anonymous "app launched/opened due
>>> to push", and not a specific "DEVICE X did open, while DEVICE Y did not yet
>>> open".
>>>
>>> So all we really need is the ID of the push notification, to be
>>> processed by our Metrics Service
>>>
>>> https://github.com/matzew/aerogear-unifiedpush-server/blob/analytics/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/registry/installations/InstallationRegistrationEndpoint.java#L128-L133
>>>
>>> Therefore my proposal is have an endpoint:
>>>
>>> PUT /metrics/pushmessage/{pushMessageID}
>>>
>>> I think PUT is good/best, because there is nothing really created on the
>>> server, it's more updating the 'counter' on the existing
>>> PushMessageInformation object.
>>>
>>> Thoughts?
>>> -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
>



-- 
-- Passos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20150511/6f487ce7/attachment-0001.html 

From edewit at redhat.com  Mon May 11 09:37:24 2015
From: edewit at redhat.com (Erik Jan de Wit)
Date: Mon, 11 May 2015 15:37:24 +0200
Subject: [aerogear-dev] New and noteworthy Cordova and Windows
Message-ID: <CAO2B-faF6w48F7-zgcAOi2wTpd0LzyK=8uydewG0HeMWv-ZJaw@mail.gmail.com>

Hi,

Last week we prepared the release of the push plugin version 1.0.3
that is going to be released this week. We'll also going to publish
the feedhenry plugins to npm as cordova is going to abandon it's
plugins.cordova.io

On the windows side of things there is nothing to report

-- 
Cheers,
       Erik Jan

From scm.blanc at gmail.com  Mon May 11 09:38:00 2015
From: scm.blanc at gmail.com (Sebastien Blanc)
Date: Mon, 11 May 2015 15:38:00 +0200
Subject: [aerogear-dev] Metrics Endpoint (was: Re: Advanced Analtyics,
 new PR and call to the client tech leads)
In-Reply-To: <CADF=h2s+VH-UtHkiEA68MKhD=K0HjNzV+6iS1R88Q4nU9-=qew@mail.gmail.com>
References: <CAAg5f2SVYYtv+hTcH=JkDkbjvGDyvLj4aG98HzY8nhK2uKnKRg@mail.gmail.com>
	<CADF=h2vfetc39f7xJyygHE5uj531tUc3xtzZu9=NePLD7DBtNg@mail.gmail.com>
	<CAAg5f2QqLCmJjQAr9nJN-aG_4z-yp1p=G292aYEfUFTq=_CnRw@mail.gmail.com>
	<CADF=h2s+VH-UtHkiEA68MKhD=K0HjNzV+6iS1R88Q4nU9-=qew@mail.gmail.com>
Message-ID: <CAD_dpu1ERU7VO7+78NuiG6DL_41LUYxBE2s6rQC+C-mqs+tMnA@mail.gmail.com>

On Mon, May 11, 2015 at 3:30 PM, Daniel Passos <dpassos at redhat.com> wrote:

> On Fri, May 8, 2015 at 2:10 AM, Matthias Wessendorf <matzew at apache.org>
> wrote:
>
>>
>>
>> On Thu, May 7, 2015 at 11:58 PM, Daniel Passos <dpassos at redhat.com>
>> wrote:
>>
>>> Just to be clear, we are talking about metrics for messages delivered
>>> (received on device) or about really read/open?
>>>
>>> Because in Android land is not possible know when message was
>>> read/opened. We delegate how the message will be delivered/showed to the
>>> MessageHandler[1] and we don't have access to it.
>>>
>>
>> when the user clicks on the message, the app opens. That's what we track
>> w/ this PR, not the actual: I read the message - more "App was opened due
>> to push", see:
>> https://issues.jboss.org/browse/AGPUSH-971
>>
>
> I can't do that. I can't do an action when app was opened. To do that we
> would need to create our own application[1] class, and all projects would
> need to extend it. As I have told in my previous email, for now I only can
> do something when the message is delivered to the device.
>
But at least we could provide a (static) method that the developer can call
and that sends the analytics, right ?

>
> [1] http://developer.android.com/reference/android/app/Application.html
>
>
>>
>>>
>>> Today we only have access when the message is delivered. Basically we
>>> receive the message in a AeroGearGCMMessageReceiver[2] do some checks and
>>> push the message for all Handles registered[3][4]
>>>
>>> [1]
>>> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/MessageHandler.java
>>> [2]
>>> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/gcm/AeroGearGCMMessageReceiver.java
>>> [3]
>>> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/RegistrarManager.java#L118
>>> [4]
>>> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/RegistrarManager.java#L130
>>>
>>> -- Passos
>>>
>>>
>>> On Wed, May 6, 2015 at 6:38 AM, Matthias Wessendorf <matzew at apache.org>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> as discussed on the previous thread, there will be a new endpoint to
>>>> 'track' the "App opened/launched due to received push notification".
>>>>
>>>> Internally, on the UPS, the Push Message has an ID, which get's append
>>>> to the payload of the notification, like here:
>>>>
>>>> https://github.com/matzew/aerogear-unifiedpush-server/blob/analytics/push/sender/src/main/java/org/jboss/aerogear/unifiedpush/message/sender/APNsPushNotificationSender.java#L107-L108
>>>>
>>>> On the client SDKs this will be read and a HTTP call made to the soon
>>>> introduced MetricsEndpoint. Currently this info is send to the
>>>> RegistrationEndpoint, including the deviceToken/registrationId. However, I
>>>> think that the deviceToken/registrationId is currently not needed for
>>>> metrics, since we are just interested in anonymous "app launched/opened due
>>>> to push", and not a specific "DEVICE X did open, while DEVICE Y did not yet
>>>> open".
>>>>
>>>> So all we really need is the ID of the push notification, to be
>>>> processed by our Metrics Service
>>>>
>>>> https://github.com/matzew/aerogear-unifiedpush-server/blob/analytics/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/registry/installations/InstallationRegistrationEndpoint.java#L128-L133
>>>>
>>>> Therefore my proposal is have an endpoint:
>>>>
>>>> PUT /metrics/pushmessage/{pushMessageID}
>>>>
>>>> I think PUT is good/best, because there is nothing really created on
>>>> the server, it's more updating the 'counter' on the existing
>>>> PushMessageInformation object.
>>>>
>>>> Thoughts?
>>>> -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
>>
>
>
>
> --
> -- Passos
>
> _______________________________________________
> 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/20150511/148f45d6/attachment.html 

From edewit at redhat.com  Mon May 11 09:39:10 2015
From: edewit at redhat.com (Erik Jan de Wit)
Date: Mon, 11 May 2015 15:39:10 +0200
Subject: [aerogear-dev] Metrics Endpoint (was: Re: Advanced Analtyics,
 new PR and call to the client tech leads)
In-Reply-To: <CADF=h2s+VH-UtHkiEA68MKhD=K0HjNzV+6iS1R88Q4nU9-=qew@mail.gmail.com>
References: <CAAg5f2SVYYtv+hTcH=JkDkbjvGDyvLj4aG98HzY8nhK2uKnKRg@mail.gmail.com>
	<CADF=h2vfetc39f7xJyygHE5uj531tUc3xtzZu9=NePLD7DBtNg@mail.gmail.com>
	<CAAg5f2QqLCmJjQAr9nJN-aG_4z-yp1p=G292aYEfUFTq=_CnRw@mail.gmail.com>
	<CADF=h2s+VH-UtHkiEA68MKhD=K0HjNzV+6iS1R88Q4nU9-=qew@mail.gmail.com>
Message-ID: <CAO2B-fZ9d7P8gervDCGXnX703ZJ1a=UciwH1mMrg5rt75KzXxQ@mail.gmail.com>

but the android sdk could have a method for uploading the metrics, so
that a developer can opt for having that displayed on the dashboard.

This method can then also be used for cordova ;)

On Mon, May 11, 2015 at 3:30 PM, Daniel Passos <dpassos at redhat.com> wrote:
> On Fri, May 8, 2015 at 2:10 AM, Matthias Wessendorf <matzew at apache.org>
> wrote:
>>
>>
>>
>> On Thu, May 7, 2015 at 11:58 PM, Daniel Passos <dpassos at redhat.com> wrote:
>>>
>>> Just to be clear, we are talking about metrics for messages delivered
>>> (received on device) or about really read/open?
>>>
>>> Because in Android land is not possible know when message was
>>> read/opened. We delegate how the message will be delivered/showed to the
>>> MessageHandler[1] and we don't have access to it.
>>
>>
>> when the user clicks on the message, the app opens. That's what we track
>> w/ this PR, not the actual: I read the message - more "App was opened due to
>> push", see:
>> https://issues.jboss.org/browse/AGPUSH-971
>
>
> I can't do that. I can't do an action when app was opened. To do that we
> would need to create our own application[1] class, and all projects would
> need to extend it. As I have told in my previous email, for now I only can
> do something when the message is delivered to the device.
>
> [1] http://developer.android.com/reference/android/app/Application.html
>
>>
>>>
>>>
>>> Today we only have access when the message is delivered. Basically we
>>> receive the message in a AeroGearGCMMessageReceiver[2] do some checks and
>>> push the message for all Handles registered[3][4]
>>>
>>> [1]
>>> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/MessageHandler.java
>>> [2]
>>> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/gcm/AeroGearGCMMessageReceiver.java
>>> [3]
>>> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/RegistrarManager.java#L118
>>> [4]
>>> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/RegistrarManager.java#L130
>>>
>>> -- Passos
>>>
>>>
>>> On Wed, May 6, 2015 at 6:38 AM, Matthias Wessendorf <matzew at apache.org>
>>> wrote:
>>>>
>>>> Hi,
>>>>
>>>> as discussed on the previous thread, there will be a new endpoint to
>>>> 'track' the "App opened/launched due to received push notification".
>>>>
>>>> Internally, on the UPS, the Push Message has an ID, which get's append
>>>> to the payload of the notification, like here:
>>>>
>>>> https://github.com/matzew/aerogear-unifiedpush-server/blob/analytics/push/sender/src/main/java/org/jboss/aerogear/unifiedpush/message/sender/APNsPushNotificationSender.java#L107-L108
>>>>
>>>> On the client SDKs this will be read and a HTTP call made to the soon
>>>> introduced MetricsEndpoint. Currently this info is send to the
>>>> RegistrationEndpoint, including the deviceToken/registrationId. However, I
>>>> think that the deviceToken/registrationId is currently not needed for
>>>> metrics, since we are just interested in anonymous "app launched/opened due
>>>> to push", and not a specific "DEVICE X did open, while DEVICE Y did not yet
>>>> open".
>>>>
>>>> So all we really need is the ID of the push notification, to be
>>>> processed by our Metrics Service
>>>>
>>>> https://github.com/matzew/aerogear-unifiedpush-server/blob/analytics/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/registry/installations/InstallationRegistrationEndpoint.java#L128-L133
>>>>
>>>> Therefore my proposal is have an endpoint:
>>>>
>>>> PUT /metrics/pushmessage/{pushMessageID}
>>>>
>>>> I think PUT is good/best, because there is nothing really created on the
>>>> server, it's more updating the 'counter' on the existing
>>>> PushMessageInformation object.
>>>>
>>>> Thoughts?
>>>> -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
>
>
>
>
> --
> -- Passos
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev



-- 
Cheers,
       Erik Jan

From dpassos at redhat.com  Mon May 11 09:41:25 2015
From: dpassos at redhat.com (Daniel Passos)
Date: Mon, 11 May 2015 10:41:25 -0300
Subject: [aerogear-dev] Metrics Endpoint (was: Re: Advanced Analtyics,
 new PR and call to the client tech leads)
In-Reply-To: <CAO2B-fZ9d7P8gervDCGXnX703ZJ1a=UciwH1mMrg5rt75KzXxQ@mail.gmail.com>
References: <CAAg5f2SVYYtv+hTcH=JkDkbjvGDyvLj4aG98HzY8nhK2uKnKRg@mail.gmail.com>
	<CADF=h2vfetc39f7xJyygHE5uj531tUc3xtzZu9=NePLD7DBtNg@mail.gmail.com>
	<CAAg5f2QqLCmJjQAr9nJN-aG_4z-yp1p=G292aYEfUFTq=_CnRw@mail.gmail.com>
	<CADF=h2s+VH-UtHkiEA68MKhD=K0HjNzV+6iS1R88Q4nU9-=qew@mail.gmail.com>
	<CAO2B-fZ9d7P8gervDCGXnX703ZJ1a=UciwH1mMrg5rt75KzXxQ@mail.gmail.com>
Message-ID: <CADF=h2scyWsrpARbkCesQ=HVJWJXHJkka3v9kr-DRcvFdprTxg@mail.gmail.com>

Of course. My point was just to be clear we can't do it "automatic" :)

On Mon, May 11, 2015 at 10:39 AM, Erik Jan de Wit <edewit at redhat.com> wrote:

> but the android sdk could have a method for uploading the metrics, so
> that a developer can opt for having that displayed on the dashboard.
>
> This method can then also be used for cordova ;)
>
> On Mon, May 11, 2015 at 3:30 PM, Daniel Passos <dpassos at redhat.com> wrote:
> > On Fri, May 8, 2015 at 2:10 AM, Matthias Wessendorf <matzew at apache.org>
> > wrote:
> >>
> >>
> >>
> >> On Thu, May 7, 2015 at 11:58 PM, Daniel Passos <dpassos at redhat.com>
> wrote:
> >>>
> >>> Just to be clear, we are talking about metrics for messages delivered
> >>> (received on device) or about really read/open?
> >>>
> >>> Because in Android land is not possible know when message was
> >>> read/opened. We delegate how the message will be delivered/showed to
> the
> >>> MessageHandler[1] and we don't have access to it.
> >>
> >>
> >> when the user clicks on the message, the app opens. That's what we track
> >> w/ this PR, not the actual: I read the message - more "App was opened
> due to
> >> push", see:
> >> https://issues.jboss.org/browse/AGPUSH-971
> >
> >
> > I can't do that. I can't do an action when app was opened. To do that we
> > would need to create our own application[1] class, and all projects would
> > need to extend it. As I have told in my previous email, for now I only
> can
> > do something when the message is delivered to the device.
> >
> > [1] http://developer.android.com/reference/android/app/Application.html
> >
> >>
> >>>
> >>>
> >>> Today we only have access when the message is delivered. Basically we
> >>> receive the message in a AeroGearGCMMessageReceiver[2] do some checks
> and
> >>> push the message for all Handles registered[3][4]
> >>>
> >>> [1]
> >>>
> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/MessageHandler.java
> >>> [2]
> >>>
> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/gcm/AeroGearGCMMessageReceiver.java
> >>> [3]
> >>>
> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/RegistrarManager.java#L118
> >>> [4]
> >>>
> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/RegistrarManager.java#L130
> >>>
> >>> -- Passos
> >>>
> >>>
> >>> On Wed, May 6, 2015 at 6:38 AM, Matthias Wessendorf <matzew at apache.org
> >
> >>> wrote:
> >>>>
> >>>> Hi,
> >>>>
> >>>> as discussed on the previous thread, there will be a new endpoint to
> >>>> 'track' the "App opened/launched due to received push notification".
> >>>>
> >>>> Internally, on the UPS, the Push Message has an ID, which get's append
> >>>> to the payload of the notification, like here:
> >>>>
> >>>>
> https://github.com/matzew/aerogear-unifiedpush-server/blob/analytics/push/sender/src/main/java/org/jboss/aerogear/unifiedpush/message/sender/APNsPushNotificationSender.java#L107-L108
> >>>>
> >>>> On the client SDKs this will be read and a HTTP call made to the soon
> >>>> introduced MetricsEndpoint. Currently this info is send to the
> >>>> RegistrationEndpoint, including the deviceToken/registrationId.
> However, I
> >>>> think that the deviceToken/registrationId is currently not needed for
> >>>> metrics, since we are just interested in anonymous "app
> launched/opened due
> >>>> to push", and not a specific "DEVICE X did open, while DEVICE Y did
> not yet
> >>>> open".
> >>>>
> >>>> So all we really need is the ID of the push notification, to be
> >>>> processed by our Metrics Service
> >>>>
> >>>>
> https://github.com/matzew/aerogear-unifiedpush-server/blob/analytics/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/registry/installations/InstallationRegistrationEndpoint.java#L128-L133
> >>>>
> >>>> Therefore my proposal is have an endpoint:
> >>>>
> >>>> PUT /metrics/pushmessage/{pushMessageID}
> >>>>
> >>>> I think PUT is good/best, because there is nothing really created on
> the
> >>>> server, it's more updating the 'counter' on the existing
> >>>> PushMessageInformation object.
> >>>>
> >>>> Thoughts?
> >>>> -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
> >
> >
> >
> >
> > --
> > -- Passos
> >
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
> --
> Cheers,
>        Erik Jan
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>



-- 
-- Passos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20150511/40bbc203/attachment-0001.html 

From matzew at apache.org  Mon May 11 09:44:25 2015
From: matzew at apache.org (Matthias Wessendorf)
Date: Mon, 11 May 2015 15:44:25 +0200
Subject: [aerogear-dev] Metrics Endpoint (was: Re: Advanced Analtyics,
 new PR and call to the client tech leads)
In-Reply-To: <CADF=h2scyWsrpARbkCesQ=HVJWJXHJkka3v9kr-DRcvFdprTxg@mail.gmail.com>
References: <CAAg5f2SVYYtv+hTcH=JkDkbjvGDyvLj4aG98HzY8nhK2uKnKRg@mail.gmail.com>
	<CADF=h2vfetc39f7xJyygHE5uj531tUc3xtzZu9=NePLD7DBtNg@mail.gmail.com>
	<CAAg5f2QqLCmJjQAr9nJN-aG_4z-yp1p=G292aYEfUFTq=_CnRw@mail.gmail.com>
	<CADF=h2s+VH-UtHkiEA68MKhD=K0HjNzV+6iS1R88Q4nU9-=qew@mail.gmail.com>
	<CAO2B-fZ9d7P8gervDCGXnX703ZJ1a=UciwH1mMrg5rt75KzXxQ@mail.gmail.com>
	<CADF=h2scyWsrpARbkCesQ=HVJWJXHJkka3v9kr-DRcvFdprTxg@mail.gmail.com>
Message-ID: <CAAg5f2ToKhNvJomxTN2PNqarN+JA_FRr4V_3GB+DutGmE8CZqw@mail.gmail.com>

iOS is also semi automatic ;-)

On Mon, May 11, 2015 at 3:41 PM, Daniel Passos <dpassos at redhat.com> wrote:

> Of course. My point was just to be clear we can't do it "automatic" :)
>
> On Mon, May 11, 2015 at 10:39 AM, Erik Jan de Wit <edewit at redhat.com>
> wrote:
>
>> but the android sdk could have a method for uploading the metrics, so
>> that a developer can opt for having that displayed on the dashboard.
>>
>> This method can then also be used for cordova ;)
>>
>> On Mon, May 11, 2015 at 3:30 PM, Daniel Passos <dpassos at redhat.com>
>> wrote:
>> > On Fri, May 8, 2015 at 2:10 AM, Matthias Wessendorf <matzew at apache.org>
>> > wrote:
>> >>
>> >>
>> >>
>> >> On Thu, May 7, 2015 at 11:58 PM, Daniel Passos <dpassos at redhat.com>
>> wrote:
>> >>>
>> >>> Just to be clear, we are talking about metrics for messages delivered
>> >>> (received on device) or about really read/open?
>> >>>
>> >>> Because in Android land is not possible know when message was
>> >>> read/opened. We delegate how the message will be delivered/showed to
>> the
>> >>> MessageHandler[1] and we don't have access to it.
>> >>
>> >>
>> >> when the user clicks on the message, the app opens. That's what we
>> track
>> >> w/ this PR, not the actual: I read the message - more "App was opened
>> due to
>> >> push", see:
>> >> https://issues.jboss.org/browse/AGPUSH-971
>> >
>> >
>> > I can't do that. I can't do an action when app was opened. To do that we
>> > would need to create our own application[1] class, and all projects
>> would
>> > need to extend it. As I have told in my previous email, for now I only
>> can
>> > do something when the message is delivered to the device.
>> >
>> > [1] http://developer.android.com/reference/android/app/Application.html
>> >
>> >>
>> >>>
>> >>>
>> >>> Today we only have access when the message is delivered. Basically we
>> >>> receive the message in a AeroGearGCMMessageReceiver[2] do some checks
>> and
>> >>> push the message for all Handles registered[3][4]
>> >>>
>> >>> [1]
>> >>>
>> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/MessageHandler.java
>> >>> [2]
>> >>>
>> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/gcm/AeroGearGCMMessageReceiver.java
>> >>> [3]
>> >>>
>> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/RegistrarManager.java#L118
>> >>> [4]
>> >>>
>> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/RegistrarManager.java#L130
>> >>>
>> >>> -- Passos
>> >>>
>> >>>
>> >>> On Wed, May 6, 2015 at 6:38 AM, Matthias Wessendorf <
>> matzew at apache.org>
>> >>> wrote:
>> >>>>
>> >>>> Hi,
>> >>>>
>> >>>> as discussed on the previous thread, there will be a new endpoint to
>> >>>> 'track' the "App opened/launched due to received push notification".
>> >>>>
>> >>>> Internally, on the UPS, the Push Message has an ID, which get's
>> append
>> >>>> to the payload of the notification, like here:
>> >>>>
>> >>>>
>> https://github.com/matzew/aerogear-unifiedpush-server/blob/analytics/push/sender/src/main/java/org/jboss/aerogear/unifiedpush/message/sender/APNsPushNotificationSender.java#L107-L108
>> >>>>
>> >>>> On the client SDKs this will be read and a HTTP call made to the soon
>> >>>> introduced MetricsEndpoint. Currently this info is send to the
>> >>>> RegistrationEndpoint, including the deviceToken/registrationId.
>> However, I
>> >>>> think that the deviceToken/registrationId is currently not needed for
>> >>>> metrics, since we are just interested in anonymous "app
>> launched/opened due
>> >>>> to push", and not a specific "DEVICE X did open, while DEVICE Y did
>> not yet
>> >>>> open".
>> >>>>
>> >>>> So all we really need is the ID of the push notification, to be
>> >>>> processed by our Metrics Service
>> >>>>
>> >>>>
>> https://github.com/matzew/aerogear-unifiedpush-server/blob/analytics/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/registry/installations/InstallationRegistrationEndpoint.java#L128-L133
>> >>>>
>> >>>> Therefore my proposal is have an endpoint:
>> >>>>
>> >>>> PUT /metrics/pushmessage/{pushMessageID}
>> >>>>
>> >>>> I think PUT is good/best, because there is nothing really created on
>> the
>> >>>> server, it's more updating the 'counter' on the existing
>> >>>> PushMessageInformation object.
>> >>>>
>> >>>> Thoughts?
>> >>>> -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
>> >
>> >
>> >
>> >
>> > --
>> > -- Passos
>> >
>> > _______________________________________________
>> > aerogear-dev mailing list
>> > aerogear-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>
>>
>> --
>> Cheers,
>>        Erik Jan
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
>
> --
> -- Passos
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.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/20150511/d01ec2d1/attachment.html 

From corinnekrych at gmail.com  Mon May 11 09:48:52 2015
From: corinnekrych at gmail.com (Corinne Krych)
Date: Mon, 11 May 2015 15:48:52 +0200
Subject: [aerogear-dev] Metrics Endpoint (was: Re: Advanced Analtyics,
 new PR and call to the client tech leads)
In-Reply-To: <CAAg5f2ToKhNvJomxTN2PNqarN+JA_FRr4V_3GB+DutGmE8CZqw@mail.gmail.com>
References: <CAAg5f2SVYYtv+hTcH=JkDkbjvGDyvLj4aG98HzY8nhK2uKnKRg@mail.gmail.com>
	<CADF=h2vfetc39f7xJyygHE5uj531tUc3xtzZu9=NePLD7DBtNg@mail.gmail.com>
	<CAAg5f2QqLCmJjQAr9nJN-aG_4z-yp1p=G292aYEfUFTq=_CnRw@mail.gmail.com>
	<CADF=h2s+VH-UtHkiEA68MKhD=K0HjNzV+6iS1R88Q4nU9-=qew@mail.gmail.com>
	<CAO2B-fZ9d7P8gervDCGXnX703ZJ1a=UciwH1mMrg5rt75KzXxQ@mail.gmail.com>
	<CADF=h2scyWsrpARbkCesQ=HVJWJXHJkka3v9kr-DRcvFdprTxg@mail.gmail.com>
	<CAAg5f2ToKhNvJomxTN2PNqarN+JA_FRr4V_3GB+DutGmE8CZqw@mail.gmail.com>
Message-ID: <CAL8vO=cvkk-fZAmvuSkf+jKaY3j5MLmqSWSPbdpbqcop9BPOhA@mail.gmail.com>

Yeap all is in "semi".
for iOs we'll have 2 public static methods:

AGPushAnalytics.sendMetricWhenAppLaunched(serverURL: NSURL, launchOptions: [
NSObject:AnyObject]?)
AGPushAnalytics.sendMetricsWhenAppAwoken(serverURL: NSURL,
applicationState: UIApplicationState, userInfo: [NSObject:AnyObject])

If we want all automation we have to provide more wrapping around native
life cycle, which can be quite intrusive.

++
Corinne

On 11 May 2015 at 15:44, Matthias Wessendorf <matzew at apache.org> wrote:

> iOS is also semi automatic ;-)
>
> On Mon, May 11, 2015 at 3:41 PM, Daniel Passos <dpassos at redhat.com> wrote:
>
>> Of course. My point was just to be clear we can't do it "automatic" :)
>>
>> On Mon, May 11, 2015 at 10:39 AM, Erik Jan de Wit <edewit at redhat.com>
>> wrote:
>>
>>> but the android sdk could have a method for uploading the metrics, so
>>> that a developer can opt for having that displayed on the dashboard.
>>>
>>> This method can then also be used for cordova ;)
>>>
>>> On Mon, May 11, 2015 at 3:30 PM, Daniel Passos <dpassos at redhat.com>
>>> wrote:
>>> > On Fri, May 8, 2015 at 2:10 AM, Matthias Wessendorf <matzew at apache.org
>>> >
>>> > wrote:
>>> >>
>>> >>
>>> >>
>>> >> On Thu, May 7, 2015 at 11:58 PM, Daniel Passos <dpassos at redhat.com>
>>> wrote:
>>> >>>
>>> >>> Just to be clear, we are talking about metrics for messages delivered
>>> >>> (received on device) or about really read/open?
>>> >>>
>>> >>> Because in Android land is not possible know when message was
>>> >>> read/opened. We delegate how the message will be delivered/showed to
>>> the
>>> >>> MessageHandler[1] and we don't have access to it.
>>> >>
>>> >>
>>> >> when the user clicks on the message, the app opens. That's what we
>>> track
>>> >> w/ this PR, not the actual: I read the message - more "App was opened
>>> due to
>>> >> push", see:
>>> >> https://issues.jboss.org/browse/AGPUSH-971
>>> >
>>> >
>>> > I can't do that. I can't do an action when app was opened. To do that
>>> we
>>> > would need to create our own application[1] class, and all projects
>>> would
>>> > need to extend it. As I have told in my previous email, for now I only
>>> can
>>> > do something when the message is delivered to the device.
>>> >
>>> > [1]
>>> http://developer.android.com/reference/android/app/Application.html
>>> >
>>> >>
>>> >>>
>>> >>>
>>> >>> Today we only have access when the message is delivered. Basically we
>>> >>> receive the message in a AeroGearGCMMessageReceiver[2] do some
>>> checks and
>>> >>> push the message for all Handles registered[3][4]
>>> >>>
>>> >>> [1]
>>> >>>
>>> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/MessageHandler.java
>>> >>> [2]
>>> >>>
>>> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/gcm/AeroGearGCMMessageReceiver.java
>>> >>> [3]
>>> >>>
>>> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/RegistrarManager.java#L118
>>> >>> [4]
>>> >>>
>>> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/RegistrarManager.java#L130
>>> >>>
>>> >>> -- Passos
>>> >>>
>>> >>>
>>> >>> On Wed, May 6, 2015 at 6:38 AM, Matthias Wessendorf <
>>> matzew at apache.org>
>>> >>> wrote:
>>> >>>>
>>> >>>> Hi,
>>> >>>>
>>> >>>> as discussed on the previous thread, there will be a new endpoint to
>>> >>>> 'track' the "App opened/launched due to received push notification".
>>> >>>>
>>> >>>> Internally, on the UPS, the Push Message has an ID, which get's
>>> append
>>> >>>> to the payload of the notification, like here:
>>> >>>>
>>> >>>>
>>> https://github.com/matzew/aerogear-unifiedpush-server/blob/analytics/push/sender/src/main/java/org/jboss/aerogear/unifiedpush/message/sender/APNsPushNotificationSender.java#L107-L108
>>> >>>>
>>> >>>> On the client SDKs this will be read and a HTTP call made to the
>>> soon
>>> >>>> introduced MetricsEndpoint. Currently this info is send to the
>>> >>>> RegistrationEndpoint, including the deviceToken/registrationId.
>>> However, I
>>> >>>> think that the deviceToken/registrationId is currently not needed
>>> for
>>> >>>> metrics, since we are just interested in anonymous "app
>>> launched/opened due
>>> >>>> to push", and not a specific "DEVICE X did open, while DEVICE Y did
>>> not yet
>>> >>>> open".
>>> >>>>
>>> >>>> So all we really need is the ID of the push notification, to be
>>> >>>> processed by our Metrics Service
>>> >>>>
>>> >>>>
>>> https://github.com/matzew/aerogear-unifiedpush-server/blob/analytics/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/registry/installations/InstallationRegistrationEndpoint.java#L128-L133
>>> >>>>
>>> >>>> Therefore my proposal is have an endpoint:
>>> >>>>
>>> >>>> PUT /metrics/pushmessage/{pushMessageID}
>>> >>>>
>>> >>>> I think PUT is good/best, because there is nothing really created
>>> on the
>>> >>>> server, it's more updating the 'counter' on the existing
>>> >>>> PushMessageInformation object.
>>> >>>>
>>> >>>> Thoughts?
>>> >>>> -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
>>> >
>>> >
>>> >
>>> >
>>> > --
>>> > -- Passos
>>> >
>>> > _______________________________________________
>>> > aerogear-dev mailing list
>>> > aerogear-dev at lists.jboss.org
>>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>>
>>>
>>> --
>>> Cheers,
>>>        Erik Jan
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>
>>
>>
>> --
>> -- Passos
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/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/20150511/8871ed58/attachment-0001.html 

From scm.blanc at gmail.com  Mon May 11 09:51:53 2015
From: scm.blanc at gmail.com (Sebastien Blanc)
Date: Mon, 11 May 2015 15:51:53 +0200
Subject: [aerogear-dev] Metrics Endpoint (was: Re: Advanced Analtyics,
 new PR and call to the client tech leads)
In-Reply-To: <CAL8vO=cvkk-fZAmvuSkf+jKaY3j5MLmqSWSPbdpbqcop9BPOhA@mail.gmail.com>
References: <CAAg5f2SVYYtv+hTcH=JkDkbjvGDyvLj4aG98HzY8nhK2uKnKRg@mail.gmail.com>
	<CADF=h2vfetc39f7xJyygHE5uj531tUc3xtzZu9=NePLD7DBtNg@mail.gmail.com>
	<CAAg5f2QqLCmJjQAr9nJN-aG_4z-yp1p=G292aYEfUFTq=_CnRw@mail.gmail.com>
	<CADF=h2s+VH-UtHkiEA68MKhD=K0HjNzV+6iS1R88Q4nU9-=qew@mail.gmail.com>
	<CAO2B-fZ9d7P8gervDCGXnX703ZJ1a=UciwH1mMrg5rt75KzXxQ@mail.gmail.com>
	<CADF=h2scyWsrpARbkCesQ=HVJWJXHJkka3v9kr-DRcvFdprTxg@mail.gmail.com>
	<CAAg5f2ToKhNvJomxTN2PNqarN+JA_FRr4V_3GB+DutGmE8CZqw@mail.gmail.com>
	<CAL8vO=cvkk-fZAmvuSkf+jKaY3j5MLmqSWSPbdpbqcop9BPOhA@mail.gmail.com>
Message-ID: <CAD_dpu2TXgzgcSomqVNSM-RAboir0_E+MdmwBXguLb9jSXroDA@mail.gmail.com>

Let's start with the "semi-automatic" approach ;)
@passos : maybe you can use the same method's name to keep it unified ? (we
can always change the names later)


On Mon, May 11, 2015 at 3:48 PM, Corinne Krych <corinnekrych at gmail.com>
wrote:

> Yeap all is in "semi".
> for iOs we'll have 2 public static methods:
>
> AGPushAnalytics.sendMetricWhenAppLaunched(serverURL: NSURL,
> launchOptions: [NSObject:AnyObject]?)
> AGPushAnalytics.sendMetricsWhenAppAwoken(serverURL: NSURL,
> applicationState: UIApplicationState, userInfo: [NSObject:AnyObject])
>
> If we want all automation we have to provide more wrapping around native
> life cycle, which can be quite intrusive.
>
> ++
> Corinne
>
> On 11 May 2015 at 15:44, Matthias Wessendorf <matzew at apache.org> wrote:
>
>> iOS is also semi automatic ;-)
>>
>> On Mon, May 11, 2015 at 3:41 PM, Daniel Passos <dpassos at redhat.com>
>> wrote:
>>
>>> Of course. My point was just to be clear we can't do it "automatic" :)
>>>
>>> On Mon, May 11, 2015 at 10:39 AM, Erik Jan de Wit <edewit at redhat.com>
>>> wrote:
>>>
>>>> but the android sdk could have a method for uploading the metrics, so
>>>> that a developer can opt for having that displayed on the dashboard.
>>>>
>>>> This method can then also be used for cordova ;)
>>>>
>>>> On Mon, May 11, 2015 at 3:30 PM, Daniel Passos <dpassos at redhat.com>
>>>> wrote:
>>>> > On Fri, May 8, 2015 at 2:10 AM, Matthias Wessendorf <
>>>> matzew at apache.org>
>>>> > wrote:
>>>> >>
>>>> >>
>>>> >>
>>>> >> On Thu, May 7, 2015 at 11:58 PM, Daniel Passos <dpassos at redhat.com>
>>>> wrote:
>>>> >>>
>>>> >>> Just to be clear, we are talking about metrics for messages
>>>> delivered
>>>> >>> (received on device) or about really read/open?
>>>> >>>
>>>> >>> Because in Android land is not possible know when message was
>>>> >>> read/opened. We delegate how the message will be delivered/showed
>>>> to the
>>>> >>> MessageHandler[1] and we don't have access to it.
>>>> >>
>>>> >>
>>>> >> when the user clicks on the message, the app opens. That's what we
>>>> track
>>>> >> w/ this PR, not the actual: I read the message - more "App was
>>>> opened due to
>>>> >> push", see:
>>>> >> https://issues.jboss.org/browse/AGPUSH-971
>>>> >
>>>> >
>>>> > I can't do that. I can't do an action when app was opened. To do that
>>>> we
>>>> > would need to create our own application[1] class, and all projects
>>>> would
>>>> > need to extend it. As I have told in my previous email, for now I
>>>> only can
>>>> > do something when the message is delivered to the device.
>>>> >
>>>> > [1]
>>>> http://developer.android.com/reference/android/app/Application.html
>>>> >
>>>> >>
>>>> >>>
>>>> >>>
>>>> >>> Today we only have access when the message is delivered. Basically
>>>> we
>>>> >>> receive the message in a AeroGearGCMMessageReceiver[2] do some
>>>> checks and
>>>> >>> push the message for all Handles registered[3][4]
>>>> >>>
>>>> >>> [1]
>>>> >>>
>>>> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/MessageHandler.java
>>>> >>> [2]
>>>> >>>
>>>> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/gcm/AeroGearGCMMessageReceiver.java
>>>> >>> [3]
>>>> >>>
>>>> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/RegistrarManager.java#L118
>>>> >>> [4]
>>>> >>>
>>>> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/RegistrarManager.java#L130
>>>> >>>
>>>> >>> -- Passos
>>>> >>>
>>>> >>>
>>>> >>> On Wed, May 6, 2015 at 6:38 AM, Matthias Wessendorf <
>>>> matzew at apache.org>
>>>> >>> wrote:
>>>> >>>>
>>>> >>>> Hi,
>>>> >>>>
>>>> >>>> as discussed on the previous thread, there will be a new endpoint
>>>> to
>>>> >>>> 'track' the "App opened/launched due to received push
>>>> notification".
>>>> >>>>
>>>> >>>> Internally, on the UPS, the Push Message has an ID, which get's
>>>> append
>>>> >>>> to the payload of the notification, like here:
>>>> >>>>
>>>> >>>>
>>>> https://github.com/matzew/aerogear-unifiedpush-server/blob/analytics/push/sender/src/main/java/org/jboss/aerogear/unifiedpush/message/sender/APNsPushNotificationSender.java#L107-L108
>>>> >>>>
>>>> >>>> On the client SDKs this will be read and a HTTP call made to the
>>>> soon
>>>> >>>> introduced MetricsEndpoint. Currently this info is send to the
>>>> >>>> RegistrationEndpoint, including the deviceToken/registrationId.
>>>> However, I
>>>> >>>> think that the deviceToken/registrationId is currently not needed
>>>> for
>>>> >>>> metrics, since we are just interested in anonymous "app
>>>> launched/opened due
>>>> >>>> to push", and not a specific "DEVICE X did open, while DEVICE Y
>>>> did not yet
>>>> >>>> open".
>>>> >>>>
>>>> >>>> So all we really need is the ID of the push notification, to be
>>>> >>>> processed by our Metrics Service
>>>> >>>>
>>>> >>>>
>>>> https://github.com/matzew/aerogear-unifiedpush-server/blob/analytics/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/registry/installations/InstallationRegistrationEndpoint.java#L128-L133
>>>> >>>>
>>>> >>>> Therefore my proposal is have an endpoint:
>>>> >>>>
>>>> >>>> PUT /metrics/pushmessage/{pushMessageID}
>>>> >>>>
>>>> >>>> I think PUT is good/best, because there is nothing really created
>>>> on the
>>>> >>>> server, it's more updating the 'counter' on the existing
>>>> >>>> PushMessageInformation object.
>>>> >>>>
>>>> >>>> Thoughts?
>>>> >>>> -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
>>>> >
>>>> >
>>>> >
>>>> >
>>>> > --
>>>> > -- Passos
>>>> >
>>>> > _______________________________________________
>>>> > aerogear-dev mailing list
>>>> > aerogear-dev at lists.jboss.org
>>>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>
>>>>
>>>>
>>>> --
>>>> Cheers,
>>>>        Erik Jan
>>>> _______________________________________________
>>>> aerogear-dev mailing list
>>>> aerogear-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>
>>>
>>>
>>>
>>> --
>>> -- Passos
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>
>>
>>
>> --
>> Matthias Wessendorf
>>
>> blog: http://matthiaswessendorf.wordpress.com/
>> sessions: http://www.slideshare.net/mwessendorf
>> twitter: http://twitter.com/mwessendorf
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.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/20150511/b4ac0e7d/attachment.html 

From matzew at apache.org  Mon May 11 09:53:19 2015
From: matzew at apache.org (Matthias Wessendorf)
Date: Mon, 11 May 2015 15:53:19 +0200
Subject: [aerogear-dev] status of IRC meetings
Message-ID: <CAAg5f2Qx__YxwteeykcV6JTznowW8=VfVL51WthesGp3N8npWA@mail.gmail.com>

Hi,

we are always on #aerogear on freenode to discuss topics. However we are
skipping the weekly team meeting, since it was most the form of a report.

Instead you will see some sort of weekly update status mails, about the
different aspects of the AeroGear project.

This also makes it easier for community members to follow up on specific
topics, instead of jumping through the IRC meeting log file.

Let me know if there are any questions.

-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/20150511/b133b3b6/attachment.html 

From matzew at apache.org  Mon May 11 09:54:14 2015
From: matzew at apache.org (Matthias Wessendorf)
Date: Mon, 11 May 2015 15:54:14 +0200
Subject: [aerogear-dev] Metrics Endpoint (was: Re: Advanced Analtyics,
 new PR and call to the client tech leads)
In-Reply-To: <CAD_dpu2TXgzgcSomqVNSM-RAboir0_E+MdmwBXguLb9jSXroDA@mail.gmail.com>
References: <CAAg5f2SVYYtv+hTcH=JkDkbjvGDyvLj4aG98HzY8nhK2uKnKRg@mail.gmail.com>
	<CADF=h2vfetc39f7xJyygHE5uj531tUc3xtzZu9=NePLD7DBtNg@mail.gmail.com>
	<CAAg5f2QqLCmJjQAr9nJN-aG_4z-yp1p=G292aYEfUFTq=_CnRw@mail.gmail.com>
	<CADF=h2s+VH-UtHkiEA68MKhD=K0HjNzV+6iS1R88Q4nU9-=qew@mail.gmail.com>
	<CAO2B-fZ9d7P8gervDCGXnX703ZJ1a=UciwH1mMrg5rt75KzXxQ@mail.gmail.com>
	<CADF=h2scyWsrpARbkCesQ=HVJWJXHJkka3v9kr-DRcvFdprTxg@mail.gmail.com>
	<CAAg5f2ToKhNvJomxTN2PNqarN+JA_FRr4V_3GB+DutGmE8CZqw@mail.gmail.com>
	<CAL8vO=cvkk-fZAmvuSkf+jKaY3j5MLmqSWSPbdpbqcop9BPOhA@mail.gmail.com>
	<CAD_dpu2TXgzgcSomqVNSM-RAboir0_E+MdmwBXguLb9jSXroDA@mail.gmail.com>
Message-ID: <CAAg5f2SFBvkiH+qjDJU0jFW21g4H14EXAtP3S2YCMDEq+XUrLQ@mail.gmail.com>

On Mon, May 11, 2015 at 3:51 PM, Sebastien Blanc <scm.blanc at gmail.com>
wrote:

> Let's start with the "semi-automatic" approach ;)
> @passos : maybe you can use the same method's name to keep it unified ?
> (we can always change the names later)
>

I think summers had a good API though on the other thread already


>
>
> On Mon, May 11, 2015 at 3:48 PM, Corinne Krych <corinnekrych at gmail.com>
> wrote:
>
>> Yeap all is in "semi".
>> for iOs we'll have 2 public static methods:
>>
>> AGPushAnalytics.sendMetricWhenAppLaunched(serverURL: NSURL,
>> launchOptions: [NSObject:AnyObject]?)
>> AGPushAnalytics.sendMetricsWhenAppAwoken(serverURL: NSURL,
>> applicationState: UIApplicationState, userInfo: [NSObject:AnyObject])
>>
>> If we want all automation we have to provide more wrapping around native
>> life cycle, which can be quite intrusive.
>>
>> ++
>> Corinne
>>
>> On 11 May 2015 at 15:44, Matthias Wessendorf <matzew at apache.org> wrote:
>>
>>> iOS is also semi automatic ;-)
>>>
>>> On Mon, May 11, 2015 at 3:41 PM, Daniel Passos <dpassos at redhat.com>
>>> wrote:
>>>
>>>> Of course. My point was just to be clear we can't do it "automatic" :)
>>>>
>>>> On Mon, May 11, 2015 at 10:39 AM, Erik Jan de Wit <edewit at redhat.com>
>>>> wrote:
>>>>
>>>>> but the android sdk could have a method for uploading the metrics, so
>>>>> that a developer can opt for having that displayed on the dashboard.
>>>>>
>>>>> This method can then also be used for cordova ;)
>>>>>
>>>>> On Mon, May 11, 2015 at 3:30 PM, Daniel Passos <dpassos at redhat.com>
>>>>> wrote:
>>>>> > On Fri, May 8, 2015 at 2:10 AM, Matthias Wessendorf <
>>>>> matzew at apache.org>
>>>>> > wrote:
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >> On Thu, May 7, 2015 at 11:58 PM, Daniel Passos <dpassos at redhat.com>
>>>>> wrote:
>>>>> >>>
>>>>> >>> Just to be clear, we are talking about metrics for messages
>>>>> delivered
>>>>> >>> (received on device) or about really read/open?
>>>>> >>>
>>>>> >>> Because in Android land is not possible know when message was
>>>>> >>> read/opened. We delegate how the message will be delivered/showed
>>>>> to the
>>>>> >>> MessageHandler[1] and we don't have access to it.
>>>>> >>
>>>>> >>
>>>>> >> when the user clicks on the message, the app opens. That's what we
>>>>> track
>>>>> >> w/ this PR, not the actual: I read the message - more "App was
>>>>> opened due to
>>>>> >> push", see:
>>>>> >> https://issues.jboss.org/browse/AGPUSH-971
>>>>> >
>>>>> >
>>>>> > I can't do that. I can't do an action when app was opened. To do
>>>>> that we
>>>>> > would need to create our own application[1] class, and all projects
>>>>> would
>>>>> > need to extend it. As I have told in my previous email, for now I
>>>>> only can
>>>>> > do something when the message is delivered to the device.
>>>>> >
>>>>> > [1]
>>>>> http://developer.android.com/reference/android/app/Application.html
>>>>> >
>>>>> >>
>>>>> >>>
>>>>> >>>
>>>>> >>> Today we only have access when the message is delivered. Basically
>>>>> we
>>>>> >>> receive the message in a AeroGearGCMMessageReceiver[2] do some
>>>>> checks and
>>>>> >>> push the message for all Handles registered[3][4]
>>>>> >>>
>>>>> >>> [1]
>>>>> >>>
>>>>> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/MessageHandler.java
>>>>> >>> [2]
>>>>> >>>
>>>>> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/gcm/AeroGearGCMMessageReceiver.java
>>>>> >>> [3]
>>>>> >>>
>>>>> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/RegistrarManager.java#L118
>>>>> >>> [4]
>>>>> >>>
>>>>> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/RegistrarManager.java#L130
>>>>> >>>
>>>>> >>> -- Passos
>>>>> >>>
>>>>> >>>
>>>>> >>> On Wed, May 6, 2015 at 6:38 AM, Matthias Wessendorf <
>>>>> matzew at apache.org>
>>>>> >>> wrote:
>>>>> >>>>
>>>>> >>>> Hi,
>>>>> >>>>
>>>>> >>>> as discussed on the previous thread, there will be a new endpoint
>>>>> to
>>>>> >>>> 'track' the "App opened/launched due to received push
>>>>> notification".
>>>>> >>>>
>>>>> >>>> Internally, on the UPS, the Push Message has an ID, which get's
>>>>> append
>>>>> >>>> to the payload of the notification, like here:
>>>>> >>>>
>>>>> >>>>
>>>>> https://github.com/matzew/aerogear-unifiedpush-server/blob/analytics/push/sender/src/main/java/org/jboss/aerogear/unifiedpush/message/sender/APNsPushNotificationSender.java#L107-L108
>>>>> >>>>
>>>>> >>>> On the client SDKs this will be read and a HTTP call made to the
>>>>> soon
>>>>> >>>> introduced MetricsEndpoint. Currently this info is send to the
>>>>> >>>> RegistrationEndpoint, including the deviceToken/registrationId.
>>>>> However, I
>>>>> >>>> think that the deviceToken/registrationId is currently not needed
>>>>> for
>>>>> >>>> metrics, since we are just interested in anonymous "app
>>>>> launched/opened due
>>>>> >>>> to push", and not a specific "DEVICE X did open, while DEVICE Y
>>>>> did not yet
>>>>> >>>> open".
>>>>> >>>>
>>>>> >>>> So all we really need is the ID of the push notification, to be
>>>>> >>>> processed by our Metrics Service
>>>>> >>>>
>>>>> >>>>
>>>>> https://github.com/matzew/aerogear-unifiedpush-server/blob/analytics/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/registry/installations/InstallationRegistrationEndpoint.java#L128-L133
>>>>> >>>>
>>>>> >>>> Therefore my proposal is have an endpoint:
>>>>> >>>>
>>>>> >>>> PUT /metrics/pushmessage/{pushMessageID}
>>>>> >>>>
>>>>> >>>> I think PUT is good/best, because there is nothing really created
>>>>> on the
>>>>> >>>> server, it's more updating the 'counter' on the existing
>>>>> >>>> PushMessageInformation object.
>>>>> >>>>
>>>>> >>>> Thoughts?
>>>>> >>>> -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
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> > --
>>>>> > -- Passos
>>>>> >
>>>>> > _______________________________________________
>>>>> > aerogear-dev mailing list
>>>>> > aerogear-dev at lists.jboss.org
>>>>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Cheers,
>>>>>        Erik Jan
>>>>> _______________________________________________
>>>>> aerogear-dev mailing list
>>>>> aerogear-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> -- Passos
>>>>
>>>> _______________________________________________
>>>> aerogear-dev mailing list
>>>> aerogear-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>
>>>
>>>
>>>
>>> --
>>> Matthias Wessendorf
>>>
>>> blog: http://matthiaswessendorf.wordpress.com/
>>> sessions: http://www.slideshare.net/mwessendorf
>>> twitter: http://twitter.com/mwessendorf
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev at lists.jboss.org
>>> https://lists.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/20150511/493666e9/attachment-0001.html 

From lholmqui at redhat.com  Mon May 11 09:56:26 2015
From: lholmqui at redhat.com (Luke Holmquist)
Date: Mon, 11 May 2015 09:56:26 -0400
Subject: [aerogear-dev] Whats new in AeroGear Javascript
Message-ID: <CALD3Fd06SG4twuv_vRbxAjQHDidM=xqScZWrMZniGmsAkdD_mQ@mail.gmail.com>

Javascript in Aerogear has been a little quite lately,

There is nothing really new and exciting to report this week.


Incase you missed it though,  there is a new example on Sync from a
community member that uses canvas.  It is pretty awesome

https://github.com/aerogear/aerogear-js-cookbook/tree/master/diff-sync-canvas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20150511/bcd9ef23/attachment.html 

From corinnekrych at gmail.com  Mon May 11 11:20:41 2015
From: corinnekrych at gmail.com (Corinne Krych)
Date: Mon, 11 May 2015 17:20:41 +0200
Subject: [aerogear-dev] What's new this week on AeroGear iOS?
Message-ID: <CAL8vO=frKXG5HOggfeWps8ZUnTMgWneQHavvNU2qd1LBwoitUA@mail.gmail.com>

Hello iOS Lovers,

Last week we started some discussion on iOS Push analytics. The API is
getting defined atm. You can follow progress on mailing list and on opened
PR [1] and it usage HelloWorld sample [2].

This week, we should come up with final proposal in Swift and Objective-C.

++
Corinne
[1] https://github.com/aerogear/aerogear-ios-push/pull/56
[2]
https://github.com/corinnekrych/unified-push-helloworld/blob/AGPUSH-1232.sendMetrics.swift/ios-swift%2FHelloWorldSwift%2FAppDelegate.swift
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20150511/5e60146e/attachment.html 

From bruno at abstractj.org  Mon May 11 16:56:26 2015
From: bruno at abstractj.org (Bruno Oliveira)
Date: Mon, 11 May 2015 17:56:26 -0300
Subject: [aerogear-dev] Metrics Endpoint (was: Re: Advanced Analtyics,
 new PR and call to the client tech leads)
In-Reply-To: <CAD_dpu2TXgzgcSomqVNSM-RAboir0_E+MdmwBXguLb9jSXroDA@mail.gmail.com>
References: <CAAg5f2SVYYtv+hTcH=JkDkbjvGDyvLj4aG98HzY8nhK2uKnKRg@mail.gmail.com>
	<CADF=h2vfetc39f7xJyygHE5uj531tUc3xtzZu9=NePLD7DBtNg@mail.gmail.com>
	<CAAg5f2QqLCmJjQAr9nJN-aG_4z-yp1p=G292aYEfUFTq=_CnRw@mail.gmail.com>
	<CADF=h2s+VH-UtHkiEA68MKhD=K0HjNzV+6iS1R88Q4nU9-=qew@mail.gmail.com>
	<CAO2B-fZ9d7P8gervDCGXnX703ZJ1a=UciwH1mMrg5rt75KzXxQ@mail.gmail.com>
	<CADF=h2scyWsrpARbkCesQ=HVJWJXHJkka3v9kr-DRcvFdprTxg@mail.gmail.com>
	<CAAg5f2ToKhNvJomxTN2PNqarN+JA_FRr4V_3GB+DutGmE8CZqw@mail.gmail.com>
	<CAL8vO=cvkk-fZAmvuSkf+jKaY3j5MLmqSWSPbdpbqcop9BPOhA@mail.gmail.com>
	<CAD_dpu2TXgzgcSomqVNSM-RAboir0_E+MdmwBXguLb9jSXroDA@mail.gmail.com>
Message-ID: <20150511205626.GB99477@abstractj.org>

On 2015-05-11, Sebastien Blanc wrote:
> Let's start with the "semi-automatic" approach ;)

I think by "semi-automatic" you mean "it's up to the developer", right?
If yes, +1.

Another question is: Is another HTTP request required only
to feed metrics? I'm thinking about people with very limited data plans.
If yes, that's definitely must be optional.

Also, do we have documented in some place what we are collecting?
>From our guide I have:

"For analytic purposes on our Dashboard we store the content of the
alert key sent to the UnifiedPush Server. The content of the alert key
belongs to the metadata, which is deleted after 30 days, using a nightly
job within the UnifiedPush Server."

If we reach an agreement on it, test the endpoint against DDoS might be
required.

> @passos : maybe you can use the same method's name to keep it unified ? (we
> can always change the names later)
>
>
> On Mon, May 11, 2015 at 3:48 PM, Corinne Krych <corinnekrych at gmail.com>
> wrote:
>
> > Yeap all is in "semi".
> > for iOs we'll have 2 public static methods:
> >
> > AGPushAnalytics.sendMetricWhenAppLaunched(serverURL: NSURL,
> > launchOptions: [NSObject:AnyObject]?)
> > AGPushAnalytics.sendMetricsWhenAppAwoken(serverURL: NSURL,
> > applicationState: UIApplicationState, userInfo: [NSObject:AnyObject])
> >
> > If we want all automation we have to provide more wrapping around native
> > life cycle, which can be quite intrusive.
> >
> > ++
> > Corinne
> >
> > On 11 May 2015 at 15:44, Matthias Wessendorf <matzew at apache.org> wrote:
> >
> >> iOS is also semi automatic ;-)
> >>
> >> On Mon, May 11, 2015 at 3:41 PM, Daniel Passos <dpassos at redhat.com>
> >> wrote:
> >>
> >>> Of course. My point was just to be clear we can't do it "automatic" :)
> >>>
> >>> On Mon, May 11, 2015 at 10:39 AM, Erik Jan de Wit <edewit at redhat.com>
> >>> wrote:
> >>>
> >>>> but the android sdk could have a method for uploading the metrics, so
> >>>> that a developer can opt for having that displayed on the dashboard.
> >>>>
> >>>> This method can then also be used for cordova ;)
> >>>>
> >>>> On Mon, May 11, 2015 at 3:30 PM, Daniel Passos <dpassos at redhat.com>
> >>>> wrote:
> >>>> > On Fri, May 8, 2015 at 2:10 AM, Matthias Wessendorf <
> >>>> matzew at apache.org>
> >>>> > wrote:
> >>>> >>
> >>>> >>
> >>>> >>
> >>>> >> On Thu, May 7, 2015 at 11:58 PM, Daniel Passos <dpassos at redhat.com>
> >>>> wrote:
> >>>> >>>
> >>>> >>> Just to be clear, we are talking about metrics for messages
> >>>> delivered
> >>>> >>> (received on device) or about really read/open?
> >>>> >>>
> >>>> >>> Because in Android land is not possible know when message was
> >>>> >>> read/opened. We delegate how the message will be delivered/showed
> >>>> to the
> >>>> >>> MessageHandler[1] and we don't have access to it.
> >>>> >>
> >>>> >>
> >>>> >> when the user clicks on the message, the app opens. That's what we
> >>>> track
> >>>> >> w/ this PR, not the actual: I read the message - more "App was
> >>>> opened due to
> >>>> >> push", see:
> >>>> >> https://issues.jboss.org/browse/AGPUSH-971
> >>>> >
> >>>> >
> >>>> > I can't do that. I can't do an action when app was opened. To do that
> >>>> we
> >>>> > would need to create our own application[1] class, and all projects
> >>>> would
> >>>> > need to extend it. As I have told in my previous email, for now I
> >>>> only can
> >>>> > do something when the message is delivered to the device.
> >>>> >
> >>>> > [1]
> >>>> http://developer.android.com/reference/android/app/Application.html
> >>>> >
> >>>> >>
> >>>> >>>
> >>>> >>>
> >>>> >>> Today we only have access when the message is delivered. Basically
> >>>> we
> >>>> >>> receive the message in a AeroGearGCMMessageReceiver[2] do some
> >>>> checks and
> >>>> >>> push the message for all Handles registered[3][4]
> >>>> >>>
> >>>> >>> [1]
> >>>> >>>
> >>>> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/MessageHandler.java
> >>>> >>> [2]
> >>>> >>>
> >>>> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/gcm/AeroGearGCMMessageReceiver.java
> >>>> >>> [3]
> >>>> >>>
> >>>> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/RegistrarManager.java#L118
> >>>> >>> [4]
> >>>> >>>
> >>>> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/RegistrarManager.java#L130
> >>>> >>>
> >>>> >>> -- Passos
> >>>> >>>
> >>>> >>>
> >>>> >>> On Wed, May 6, 2015 at 6:38 AM, Matthias Wessendorf <
> >>>> matzew at apache.org>
> >>>> >>> wrote:
> >>>> >>>>
> >>>> >>>> Hi,
> >>>> >>>>
> >>>> >>>> as discussed on the previous thread, there will be a new endpoint
> >>>> to
> >>>> >>>> 'track' the "App opened/launched due to received push
> >>>> notification".
> >>>> >>>>
> >>>> >>>> Internally, on the UPS, the Push Message has an ID, which get's
> >>>> append
> >>>> >>>> to the payload of the notification, like here:
> >>>> >>>>
> >>>> >>>>
> >>>> https://github.com/matzew/aerogear-unifiedpush-server/blob/analytics/push/sender/src/main/java/org/jboss/aerogear/unifiedpush/message/sender/APNsPushNotificationSender.java#L107-L108
> >>>> >>>>
> >>>> >>>> On the client SDKs this will be read and a HTTP call made to the
> >>>> soon
> >>>> >>>> introduced MetricsEndpoint. Currently this info is send to the
> >>>> >>>> RegistrationEndpoint, including the deviceToken/registrationId.
> >>>> However, I
> >>>> >>>> think that the deviceToken/registrationId is currently not needed
> >>>> for
> >>>> >>>> metrics, since we are just interested in anonymous "app
> >>>> launched/opened due
> >>>> >>>> to push", and not a specific "DEVICE X did open, while DEVICE Y
> >>>> did not yet
> >>>> >>>> open".
> >>>> >>>>
> >>>> >>>> So all we really need is the ID of the push notification, to be
> >>>> >>>> processed by our Metrics Service
> >>>> >>>>
> >>>> >>>>
> >>>> https://github.com/matzew/aerogear-unifiedpush-server/blob/analytics/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/registry/installations/InstallationRegistrationEndpoint.java#L128-L133
> >>>> >>>>
> >>>> >>>> Therefore my proposal is have an endpoint:
> >>>> >>>>
> >>>> >>>> PUT /metrics/pushmessage/{pushMessageID}
> >>>> >>>>
> >>>> >>>> I think PUT is good/best, because there is nothing really created
> >>>> on the
> >>>> >>>> server, it's more updating the 'counter' on the existing
> >>>> >>>> PushMessageInformation object.
> >>>> >>>>
> >>>> >>>> Thoughts?
> >>>> >>>> -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
> >>>> >
> >>>> >
> >>>> >
> >>>> >
> >>>> > --
> >>>> > -- Passos
> >>>> >
> >>>> > _______________________________________________
> >>>> > aerogear-dev mailing list
> >>>> > aerogear-dev at lists.jboss.org
> >>>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Cheers,
> >>>>        Erik Jan
> >>>> _______________________________________________
> >>>> aerogear-dev mailing list
> >>>> aerogear-dev at lists.jboss.org
> >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> -- Passos
> >>>
> >>> _______________________________________________
> >>> aerogear-dev mailing list
> >>> aerogear-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >>>
> >>
> >>
> >>
> >> --
> >> Matthias Wessendorf
> >>
> >> blog: http://matthiaswessendorf.wordpress.com/
> >> sessions: http://www.slideshare.net/mwessendorf
> >> twitter: http://twitter.com/mwessendorf
> >>
> >> _______________________________________________
> >> aerogear-dev mailing list
> >> aerogear-dev at lists.jboss.org
> >> https://lists.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


--

abstractj
PGP: 0x84DC9914

From scm.blanc at gmail.com  Mon May 11 17:08:23 2015
From: scm.blanc at gmail.com (Sebastien Blanc)
Date: Mon, 11 May 2015 23:08:23 +0200
Subject: [aerogear-dev] Metrics Endpoint (was: Re: Advanced Analtyics,
 new PR and call to the client tech leads)
In-Reply-To: <20150511205626.GB99477@abstractj.org>
References: <CAAg5f2SVYYtv+hTcH=JkDkbjvGDyvLj4aG98HzY8nhK2uKnKRg@mail.gmail.com>
	<CADF=h2vfetc39f7xJyygHE5uj531tUc3xtzZu9=NePLD7DBtNg@mail.gmail.com>
	<CAAg5f2QqLCmJjQAr9nJN-aG_4z-yp1p=G292aYEfUFTq=_CnRw@mail.gmail.com>
	<CADF=h2s+VH-UtHkiEA68MKhD=K0HjNzV+6iS1R88Q4nU9-=qew@mail.gmail.com>
	<CAO2B-fZ9d7P8gervDCGXnX703ZJ1a=UciwH1mMrg5rt75KzXxQ@mail.gmail.com>
	<CADF=h2scyWsrpARbkCesQ=HVJWJXHJkka3v9kr-DRcvFdprTxg@mail.gmail.com>
	<CAAg5f2ToKhNvJomxTN2PNqarN+JA_FRr4V_3GB+DutGmE8CZqw@mail.gmail.com>
	<CAL8vO=cvkk-fZAmvuSkf+jKaY3j5MLmqSWSPbdpbqcop9BPOhA@mail.gmail.com>
	<CAD_dpu2TXgzgcSomqVNSM-RAboir0_E+MdmwBXguLb9jSXroDA@mail.gmail.com>
	<20150511205626.GB99477@abstractj.org>
Message-ID: <CAD_dpu1qj4UaCSJ+dkv8Fjh9Vzj+f5JDLs3ztxAPbBaMVyi2vw@mail.gmail.com>

On Mon, May 11, 2015 at 10:56 PM, Bruno Oliveira <bruno at abstractj.org>
wrote:

> On 2015-05-11, Sebastien Blanc wrote:
> > Let's start with the "semi-automatic" approach ;)
>
> I think by "semi-automatic" you mean "it's up to the developer", right?
>
right :)

> If yes, +1.
>
> Another question is: Is another HTTP request required only
> to feed metrics? I'm thinking about people with very limited data plans.
> If yes, that's definitely must be optional.
>
Yes since we have to collect when a specific action occurs (open an app or
bring to foreground) the only way is do a http request

>
> Also, do we have documented in some place what we are collecting?
>
We are not collecting anything with this advanced metrics, we are just
"counting" anonymously.

> >From our guide I have:
>
> "For analytic purposes on our Dashboard we store the content of the
> alert key sent to the UnifiedPush Server. The content of the alert key
> belongs to the metadata, which is deleted after 30 days, using a nightly
> job within the UnifiedPush Server."
>
> If we reach an agreement on it, test the endpoint against DDoS might be
> required.
>
Agreed.
we should even test DDoS against all our "open" endpoints (registration,
import, sender)

>
> > @passos : maybe you can use the same method's name to keep it unified ?
> (we
> > can always change the names later)
> >
> >
> > On Mon, May 11, 2015 at 3:48 PM, Corinne Krych <corinnekrych at gmail.com>
> > wrote:
> >
> > > Yeap all is in "semi".
> > > for iOs we'll have 2 public static methods:
> > >
> > > AGPushAnalytics.sendMetricWhenAppLaunched(serverURL: NSURL,
> > > launchOptions: [NSObject:AnyObject]?)
> > > AGPushAnalytics.sendMetricsWhenAppAwoken(serverURL: NSURL,
> > > applicationState: UIApplicationState, userInfo: [NSObject:AnyObject])
> > >
> > > If we want all automation we have to provide more wrapping around
> native
> > > life cycle, which can be quite intrusive.
> > >
> > > ++
> > > Corinne
> > >
> > > On 11 May 2015 at 15:44, Matthias Wessendorf <matzew at apache.org>
> wrote:
> > >
> > >> iOS is also semi automatic ;-)
> > >>
> > >> On Mon, May 11, 2015 at 3:41 PM, Daniel Passos <dpassos at redhat.com>
> > >> wrote:
> > >>
> > >>> Of course. My point was just to be clear we can't do it "automatic"
> :)
> > >>>
> > >>> On Mon, May 11, 2015 at 10:39 AM, Erik Jan de Wit <edewit at redhat.com
> >
> > >>> wrote:
> > >>>
> > >>>> but the android sdk could have a method for uploading the metrics,
> so
> > >>>> that a developer can opt for having that displayed on the dashboard.
> > >>>>
> > >>>> This method can then also be used for cordova ;)
> > >>>>
> > >>>> On Mon, May 11, 2015 at 3:30 PM, Daniel Passos <dpassos at redhat.com>
> > >>>> wrote:
> > >>>> > On Fri, May 8, 2015 at 2:10 AM, Matthias Wessendorf <
> > >>>> matzew at apache.org>
> > >>>> > wrote:
> > >>>> >>
> > >>>> >>
> > >>>> >>
> > >>>> >> On Thu, May 7, 2015 at 11:58 PM, Daniel Passos <
> dpassos at redhat.com>
> > >>>> wrote:
> > >>>> >>>
> > >>>> >>> Just to be clear, we are talking about metrics for messages
> > >>>> delivered
> > >>>> >>> (received on device) or about really read/open?
> > >>>> >>>
> > >>>> >>> Because in Android land is not possible know when message was
> > >>>> >>> read/opened. We delegate how the message will be
> delivered/showed
> > >>>> to the
> > >>>> >>> MessageHandler[1] and we don't have access to it.
> > >>>> >>
> > >>>> >>
> > >>>> >> when the user clicks on the message, the app opens. That's what
> we
> > >>>> track
> > >>>> >> w/ this PR, not the actual: I read the message - more "App was
> > >>>> opened due to
> > >>>> >> push", see:
> > >>>> >> https://issues.jboss.org/browse/AGPUSH-971
> > >>>> >
> > >>>> >
> > >>>> > I can't do that. I can't do an action when app was opened. To do
> that
> > >>>> we
> > >>>> > would need to create our own application[1] class, and all
> projects
> > >>>> would
> > >>>> > need to extend it. As I have told in my previous email, for now I
> > >>>> only can
> > >>>> > do something when the message is delivered to the device.
> > >>>> >
> > >>>> > [1]
> > >>>> http://developer.android.com/reference/android/app/Application.html
> > >>>> >
> > >>>> >>
> > >>>> >>>
> > >>>> >>>
> > >>>> >>> Today we only have access when the message is delivered.
> Basically
> > >>>> we
> > >>>> >>> receive the message in a AeroGearGCMMessageReceiver[2] do some
> > >>>> checks and
> > >>>> >>> push the message for all Handles registered[3][4]
> > >>>> >>>
> > >>>> >>> [1]
> > >>>> >>>
> > >>>>
> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/MessageHandler.java
> > >>>> >>> [2]
> > >>>> >>>
> > >>>>
> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/gcm/AeroGearGCMMessageReceiver.java
> > >>>> >>> [3]
> > >>>> >>>
> > >>>>
> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/RegistrarManager.java#L118
> > >>>> >>> [4]
> > >>>> >>>
> > >>>>
> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/RegistrarManager.java#L130
> > >>>> >>>
> > >>>> >>> -- Passos
> > >>>> >>>
> > >>>> >>>
> > >>>> >>> On Wed, May 6, 2015 at 6:38 AM, Matthias Wessendorf <
> > >>>> matzew at apache.org>
> > >>>> >>> wrote:
> > >>>> >>>>
> > >>>> >>>> Hi,
> > >>>> >>>>
> > >>>> >>>> as discussed on the previous thread, there will be a new
> endpoint
> > >>>> to
> > >>>> >>>> 'track' the "App opened/launched due to received push
> > >>>> notification".
> > >>>> >>>>
> > >>>> >>>> Internally, on the UPS, the Push Message has an ID, which get's
> > >>>> append
> > >>>> >>>> to the payload of the notification, like here:
> > >>>> >>>>
> > >>>> >>>>
> > >>>>
> https://github.com/matzew/aerogear-unifiedpush-server/blob/analytics/push/sender/src/main/java/org/jboss/aerogear/unifiedpush/message/sender/APNsPushNotificationSender.java#L107-L108
> > >>>> >>>>
> > >>>> >>>> On the client SDKs this will be read and a HTTP call made to
> the
> > >>>> soon
> > >>>> >>>> introduced MetricsEndpoint. Currently this info is send to the
> > >>>> >>>> RegistrationEndpoint, including the deviceToken/registrationId.
> > >>>> However, I
> > >>>> >>>> think that the deviceToken/registrationId is currently not
> needed
> > >>>> for
> > >>>> >>>> metrics, since we are just interested in anonymous "app
> > >>>> launched/opened due
> > >>>> >>>> to push", and not a specific "DEVICE X did open, while DEVICE Y
> > >>>> did not yet
> > >>>> >>>> open".
> > >>>> >>>>
> > >>>> >>>> So all we really need is the ID of the push notification, to be
> > >>>> >>>> processed by our Metrics Service
> > >>>> >>>>
> > >>>> >>>>
> > >>>>
> https://github.com/matzew/aerogear-unifiedpush-server/blob/analytics/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/registry/installations/InstallationRegistrationEndpoint.java#L128-L133
> > >>>> >>>>
> > >>>> >>>> Therefore my proposal is have an endpoint:
> > >>>> >>>>
> > >>>> >>>> PUT /metrics/pushmessage/{pushMessageID}
> > >>>> >>>>
> > >>>> >>>> I think PUT is good/best, because there is nothing really
> created
> > >>>> on the
> > >>>> >>>> server, it's more updating the 'counter' on the existing
> > >>>> >>>> PushMessageInformation object.
> > >>>> >>>>
> > >>>> >>>> Thoughts?
> > >>>> >>>> -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
> > >>>> >
> > >>>> >
> > >>>> >
> > >>>> >
> > >>>> > --
> > >>>> > -- Passos
> > >>>> >
> > >>>> > _______________________________________________
> > >>>> > aerogear-dev mailing list
> > >>>> > aerogear-dev at lists.jboss.org
> > >>>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > >>>>
> > >>>>
> > >>>>
> > >>>> --
> > >>>> Cheers,
> > >>>>        Erik Jan
> > >>>> _______________________________________________
> > >>>> aerogear-dev mailing list
> > >>>> aerogear-dev at lists.jboss.org
> > >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > >>>>
> > >>>
> > >>>
> > >>>
> > >>> --
> > >>> -- Passos
> > >>>
> > >>> _______________________________________________
> > >>> aerogear-dev mailing list
> > >>> aerogear-dev at lists.jboss.org
> > >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > >>>
> > >>
> > >>
> > >>
> > >> --
> > >> Matthias Wessendorf
> > >>
> > >> blog: http://matthiaswessendorf.wordpress.com/
> > >> sessions: http://www.slideshare.net/mwessendorf
> > >> twitter: http://twitter.com/mwessendorf
> > >>
> > >> _______________________________________________
> > >> aerogear-dev mailing list
> > >> aerogear-dev at lists.jboss.org
> > >> https://lists.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
>
>
> --
>
> abstractj
> PGP: 0x84DC9914
> _______________________________________________
> 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/20150511/cfe61d7e/attachment-0001.html 

From qmx at qmx.me  Mon May 11 17:10:34 2015
From: qmx at qmx.me (Douglas Campos)
Date: Mon, 11 May 2015 18:10:34 -0300
Subject: [aerogear-dev] Metrics Endpoint (was: Re: Advanced Analtyics,
 new PR and call to the client tech leads)
In-Reply-To: <CAD_dpu1qj4UaCSJ+dkv8Fjh9Vzj+f5JDLs3ztxAPbBaMVyi2vw@mail.gmail.com>
References: <CAAg5f2SVYYtv+hTcH=JkDkbjvGDyvLj4aG98HzY8nhK2uKnKRg@mail.gmail.com>
	<CADF=h2vfetc39f7xJyygHE5uj531tUc3xtzZu9=NePLD7DBtNg@mail.gmail.com>
	<CAAg5f2QqLCmJjQAr9nJN-aG_4z-yp1p=G292aYEfUFTq=_CnRw@mail.gmail.com>
	<CADF=h2s+VH-UtHkiEA68MKhD=K0HjNzV+6iS1R88Q4nU9-=qew@mail.gmail.com>
	<CAO2B-fZ9d7P8gervDCGXnX703ZJ1a=UciwH1mMrg5rt75KzXxQ@mail.gmail.com>
	<CADF=h2scyWsrpARbkCesQ=HVJWJXHJkka3v9kr-DRcvFdprTxg@mail.gmail.com>
	<CAAg5f2ToKhNvJomxTN2PNqarN+JA_FRr4V_3GB+DutGmE8CZqw@mail.gmail.com>
	<CAL8vO=cvkk-fZAmvuSkf+jKaY3j5MLmqSWSPbdpbqcop9BPOhA@mail.gmail.com>
	<CAD_dpu2TXgzgcSomqVNSM-RAboir0_E+MdmwBXguLb9jSXroDA@mail.gmail.com>
	<20150511205626.GB99477@abstractj.org>
	<CAD_dpu1qj4UaCSJ+dkv8Fjh9Vzj+f5JDLs3ztxAPbBaMVyi2vw@mail.gmail.com>
Message-ID: <CAN-DfD4QmWSz3jT4EbsFELyho_rT77WPbkmUnD6+_yA2LJqnXg@mail.gmail.com>

On Mon, May 11, 2015 at 6:08 PM, Sebastien Blanc <scm.blanc at gmail.com>
wrote:

>
>
> On Mon, May 11, 2015 at 10:56 PM, Bruno Oliveira <bruno at abstractj.org>
> wrote:
>
>> On 2015-05-11, Sebastien Blanc wrote:
>> > Let's start with the "semi-automatic" approach ;)
>>
>> I think by "semi-automatic" you mean "it's up to the developer", right?
>>
> right :)
>
>> If yes, +1.
>>
>> Another question is: Is another HTTP request required only
>> to feed metrics? I'm thinking about people with very limited data plans.
>> If yes, that's definitely must be optional.
>>
> Yes since we have to collect when a specific action occurs (open an app or
> bring to foreground) the only way is do a http request
>
What about making this thing async? Storing statistics locally and flushing
them out once a given threshold is crossed...


>
>> Also, do we have documented in some place what we are collecting?
>>
> We are not collecting anything with this advanced metrics, we are just
> "counting" anonymously.
>
>> >From our guide I have:
>>
>> "For analytic purposes on our Dashboard we store the content of the
>> alert key sent to the UnifiedPush Server. The content of the alert key
>> belongs to the metadata, which is deleted after 30 days, using a nightly
>> job within the UnifiedPush Server."
>>
>> If we reach an agreement on it, test the endpoint against DDoS might be
>> required.
>>
> Agreed.
> we should even test DDoS against all our "open" endpoints (registration,
> import, sender)
>
>>
>> > @passos : maybe you can use the same method's name to keep it unified ?
>> (we
>> > can always change the names later)
>> >
>> >
>> > On Mon, May 11, 2015 at 3:48 PM, Corinne Krych <corinnekrych at gmail.com>
>> > wrote:
>> >
>> > > Yeap all is in "semi".
>> > > for iOs we'll have 2 public static methods:
>> > >
>> > > AGPushAnalytics.sendMetricWhenAppLaunched(serverURL: NSURL,
>> > > launchOptions: [NSObject:AnyObject]?)
>> > > AGPushAnalytics.sendMetricsWhenAppAwoken(serverURL: NSURL,
>> > > applicationState: UIApplicationState, userInfo: [NSObject:AnyObject])
>> > >
>> > > If we want all automation we have to provide more wrapping around
>> native
>> > > life cycle, which can be quite intrusive.
>> > >
>> > > ++
>> > > Corinne
>> > >
>> > > On 11 May 2015 at 15:44, Matthias Wessendorf <matzew at apache.org>
>> wrote:
>> > >
>> > >> iOS is also semi automatic ;-)
>> > >>
>> > >> On Mon, May 11, 2015 at 3:41 PM, Daniel Passos <dpassos at redhat.com>
>> > >> wrote:
>> > >>
>> > >>> Of course. My point was just to be clear we can't do it "automatic"
>> :)
>> > >>>
>> > >>> On Mon, May 11, 2015 at 10:39 AM, Erik Jan de Wit <
>> edewit at redhat.com>
>> > >>> wrote:
>> > >>>
>> > >>>> but the android sdk could have a method for uploading the metrics,
>> so
>> > >>>> that a developer can opt for having that displayed on the
>> dashboard.
>> > >>>>
>> > >>>> This method can then also be used for cordova ;)
>> > >>>>
>> > >>>> On Mon, May 11, 2015 at 3:30 PM, Daniel Passos <dpassos at redhat.com
>> >
>> > >>>> wrote:
>> > >>>> > On Fri, May 8, 2015 at 2:10 AM, Matthias Wessendorf <
>> > >>>> matzew at apache.org>
>> > >>>> > wrote:
>> > >>>> >>
>> > >>>> >>
>> > >>>> >>
>> > >>>> >> On Thu, May 7, 2015 at 11:58 PM, Daniel Passos <
>> dpassos at redhat.com>
>> > >>>> wrote:
>> > >>>> >>>
>> > >>>> >>> Just to be clear, we are talking about metrics for messages
>> > >>>> delivered
>> > >>>> >>> (received on device) or about really read/open?
>> > >>>> >>>
>> > >>>> >>> Because in Android land is not possible know when message was
>> > >>>> >>> read/opened. We delegate how the message will be
>> delivered/showed
>> > >>>> to the
>> > >>>> >>> MessageHandler[1] and we don't have access to it.
>> > >>>> >>
>> > >>>> >>
>> > >>>> >> when the user clicks on the message, the app opens. That's what
>> we
>> > >>>> track
>> > >>>> >> w/ this PR, not the actual: I read the message - more "App was
>> > >>>> opened due to
>> > >>>> >> push", see:
>> > >>>> >> https://issues.jboss.org/browse/AGPUSH-971
>> > >>>> >
>> > >>>> >
>> > >>>> > I can't do that. I can't do an action when app was opened. To do
>> that
>> > >>>> we
>> > >>>> > would need to create our own application[1] class, and all
>> projects
>> > >>>> would
>> > >>>> > need to extend it. As I have told in my previous email, for now I
>> > >>>> only can
>> > >>>> > do something when the message is delivered to the device.
>> > >>>> >
>> > >>>> > [1]
>> > >>>>
>> http://developer.android.com/reference/android/app/Application.html
>> > >>>> >
>> > >>>> >>
>> > >>>> >>>
>> > >>>> >>>
>> > >>>> >>> Today we only have access when the message is delivered.
>> Basically
>> > >>>> we
>> > >>>> >>> receive the message in a AeroGearGCMMessageReceiver[2] do some
>> > >>>> checks and
>> > >>>> >>> push the message for all Handles registered[3][4]
>> > >>>> >>>
>> > >>>> >>> [1]
>> > >>>> >>>
>> > >>>>
>> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/MessageHandler.java
>> > >>>> >>> [2]
>> > >>>> >>>
>> > >>>>
>> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/gcm/AeroGearGCMMessageReceiver.java
>> > >>>> >>> [3]
>> > >>>> >>>
>> > >>>>
>> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/RegistrarManager.java#L118
>> > >>>> >>> [4]
>> > >>>> >>>
>> > >>>>
>> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/RegistrarManager.java#L130
>> > >>>> >>>
>> > >>>> >>> -- Passos
>> > >>>> >>>
>> > >>>> >>>
>> > >>>> >>> On Wed, May 6, 2015 at 6:38 AM, Matthias Wessendorf <
>> > >>>> matzew at apache.org>
>> > >>>> >>> wrote:
>> > >>>> >>>>
>> > >>>> >>>> Hi,
>> > >>>> >>>>
>> > >>>> >>>> as discussed on the previous thread, there will be a new
>> endpoint
>> > >>>> to
>> > >>>> >>>> 'track' the "App opened/launched due to received push
>> > >>>> notification".
>> > >>>> >>>>
>> > >>>> >>>> Internally, on the UPS, the Push Message has an ID, which
>> get's
>> > >>>> append
>> > >>>> >>>> to the payload of the notification, like here:
>> > >>>> >>>>
>> > >>>> >>>>
>> > >>>>
>> https://github.com/matzew/aerogear-unifiedpush-server/blob/analytics/push/sender/src/main/java/org/jboss/aerogear/unifiedpush/message/sender/APNsPushNotificationSender.java#L107-L108
>> > >>>> >>>>
>> > >>>> >>>> On the client SDKs this will be read and a HTTP call made to
>> the
>> > >>>> soon
>> > >>>> >>>> introduced MetricsEndpoint. Currently this info is send to the
>> > >>>> >>>> RegistrationEndpoint, including the
>> deviceToken/registrationId.
>> > >>>> However, I
>> > >>>> >>>> think that the deviceToken/registrationId is currently not
>> needed
>> > >>>> for
>> > >>>> >>>> metrics, since we are just interested in anonymous "app
>> > >>>> launched/opened due
>> > >>>> >>>> to push", and not a specific "DEVICE X did open, while DEVICE
>> Y
>> > >>>> did not yet
>> > >>>> >>>> open".
>> > >>>> >>>>
>> > >>>> >>>> So all we really need is the ID of the push notification, to
>> be
>> > >>>> >>>> processed by our Metrics Service
>> > >>>> >>>>
>> > >>>> >>>>
>> > >>>>
>> https://github.com/matzew/aerogear-unifiedpush-server/blob/analytics/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/registry/installations/InstallationRegistrationEndpoint.java#L128-L133
>> > >>>> >>>>
>> > >>>> >>>> Therefore my proposal is have an endpoint:
>> > >>>> >>>>
>> > >>>> >>>> PUT /metrics/pushmessage/{pushMessageID}
>> > >>>> >>>>
>> > >>>> >>>> I think PUT is good/best, because there is nothing really
>> created
>> > >>>> on the
>> > >>>> >>>> server, it's more updating the 'counter' on the existing
>> > >>>> >>>> PushMessageInformation object.
>> > >>>> >>>>
>> > >>>> >>>> Thoughts?
>> > >>>> >>>> -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
>> > >>>> >
>> > >>>> >
>> > >>>> >
>> > >>>> >
>> > >>>> > --
>> > >>>> > -- Passos
>> > >>>> >
>> > >>>> > _______________________________________________
>> > >>>> > aerogear-dev mailing list
>> > >>>> > aerogear-dev at lists.jboss.org
>> > >>>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>> > >>>>
>> > >>>>
>> > >>>>
>> > >>>> --
>> > >>>> Cheers,
>> > >>>>        Erik Jan
>> > >>>> _______________________________________________
>> > >>>> aerogear-dev mailing list
>> > >>>> aerogear-dev at lists.jboss.org
>> > >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>> > >>>>
>> > >>>
>> > >>>
>> > >>>
>> > >>> --
>> > >>> -- Passos
>> > >>>
>> > >>> _______________________________________________
>> > >>> aerogear-dev mailing list
>> > >>> aerogear-dev at lists.jboss.org
>> > >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>> > >>>
>> > >>
>> > >>
>> > >>
>> > >> --
>> > >> Matthias Wessendorf
>> > >>
>> > >> blog: http://matthiaswessendorf.wordpress.com/
>> > >> sessions: http://www.slideshare.net/mwessendorf
>> > >> twitter: http://twitter.com/mwessendorf
>> > >>
>> > >> _______________________________________________
>> > >> aerogear-dev mailing list
>> > >> aerogear-dev at lists.jboss.org
>> > >> https://lists.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
>>
>>
>> --
>>
>> abstractj
>> PGP: 0x84DC9914
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.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/20150511/b68572e6/attachment-0001.html 

From bruno at abstractj.org  Mon May 11 17:11:49 2015
From: bruno at abstractj.org (Bruno Oliveira)
Date: Mon, 11 May 2015 18:11:49 -0300
Subject: [aerogear-dev] Dealing with UPS Keycloak data
 post-datasource-split
In-Reply-To: <CAAg5f2T7zOkVQU8oKptCOJCb1nd8Um9jLo-5FqTHSSufgzdrkA@mail.gmail.com>
References: <CAN-DfD5v6svHbP63QvhVHCzfKxY2Bmgy0Pq3jVYRND_jvKeN_w@mail.gmail.com>
	<CAAg5f2Trqwrg46PwY4+ZtUR9ymRvSoX3f0rYr5uxO7t2oRHpoQ@mail.gmail.com>
	<CAAg5f2T7zOkVQU8oKptCOJCb1nd8Um9jLo-5FqTHSSufgzdrkA@mail.gmail.com>
Message-ID: <20150511211149.GC99477@abstractj.org>

Sorry if I'm late for this discussion.

On 2015-05-07, Matthias Wessendorf wrote:
> How about the following, not optimal, proposal:
>
> * get back to one data-source

I'm not against about it, if it's for the benefit of the project.

> * stick w/ Keycloak-1.1.0-final (in case updating to KC-1.2.0 makes above
> item harder)

I don't get why master must be reverted to 1.1.0 final. I think stable
release of KC must go in 1.0.x series of UPS, but on master, we must
stick with the latest greatest release of KC. Because is the only way to
work closely with KC team.

>
> I understand that a separation of the two is needed on the longer run - it
> would be good if that's something on our agenda post 1.1.0 e.g. for 1.2.0
>
> I think the above is a 'work around', which I could live with and buys us
> time to truly think about a perfect separation.

My 2 cents here and my humble opinion is the fact that we don't need perfection,
only the correct. Today, split Keycloak and UPS would the most
correct thing to do. I'm not saying what we're doing here is dead wrong, but
sooner or later the problem will hit us anyway.

So maybe we should attack the problem now?

>
>
>
>
>
>
> On Thu, May 7, 2015 at 3:26 AM, Matthias Wessendorf <matzew at apache.org>
> wrote:
>
> >
> >
> > On Wed, May 6, 2015 at 8:27 PM, Douglas Campos <qmx at qmx.me> wrote:
> >
> >> Howdy y'all!
> >>
> >> I'm revisiting migration strategies for UPS master, and we have a tough
> >> situation to deal with.
> >>
> >> Since we have moved keycloak to its own DataSource, there are KC
> >> leftovers at UPS database which need to be cleaned up.
> >>
> >> 1) Any suggestions on how to provide a migration path?
> >>   Since the tables are intertwined with UPS tables, it's not a matter of
> >> doing a db dump/restore...
> >>
> >
> > how are they intertwined? Is UPS stuff stored in KC tables, or vice versa?
> >
> >
> >> 2) How to ensure we can safely get rid of the leftover tables on UPS
> >> DataSource?
> >>   I can easily provide migrations which just nuke the tables from the
> >> face of the earth,
> >>
> >
> > that's good, but
> >
> >
> >> but how to do this without data loss?
> >>
> >
> > I don't know :-) I wonder if we just can not move the data to a new
> > datasource.
> >
> >
> >
> >
> >
> >>
> >> Thoughts?
> >>
> >> _______________________________________________
> >> aerogear-dev mailing list
> >> aerogear-dev at lists.jboss.org
> >> https://lists.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


--

abstractj
PGP: 0x84DC9914

From scm.blanc at gmail.com  Mon May 11 17:26:11 2015
From: scm.blanc at gmail.com (Sebastien Blanc)
Date: Mon, 11 May 2015 23:26:11 +0200
Subject: [aerogear-dev] Dealing with UPS Keycloak data
	post-datasource-split
In-Reply-To: <20150511211149.GC99477@abstractj.org>
References: <CAN-DfD5v6svHbP63QvhVHCzfKxY2Bmgy0Pq3jVYRND_jvKeN_w@mail.gmail.com>
	<CAAg5f2Trqwrg46PwY4+ZtUR9ymRvSoX3f0rYr5uxO7t2oRHpoQ@mail.gmail.com>
	<CAAg5f2T7zOkVQU8oKptCOJCb1nd8Um9jLo-5FqTHSSufgzdrkA@mail.gmail.com>
	<20150511211149.GC99477@abstractj.org>
Message-ID: <CAD_dpu2RUbh_2Yt6dc5+nf_ykyUX2msKUiR1XDfLNky-MbaNtw@mail.gmail.com>

What about dumping only the KC tables (they have no relation with the UPS
table)  restore them on the KC separate datasource, apply migration on this
datasource and then  nuke the old KC  tables on the initial DB. And finally
applying the UPS migration path ?


On Mon, May 11, 2015 at 11:11 PM, Bruno Oliveira <bruno at abstractj.org>
wrote:

> Sorry if I'm late for this discussion.
>
> On 2015-05-07, Matthias Wessendorf wrote:
> > How about the following, not optimal, proposal:
> >
> > * get back to one data-source
>
> I'm not against about it, if it's for the benefit of the project.
>
> > * stick w/ Keycloak-1.1.0-final (in case updating to KC-1.2.0 makes above
> > item harder)
>
> I don't get why master must be reverted to 1.1.0 final. I think stable
> release of KC must go in 1.0.x series of UPS, but on master, we must
> stick with the latest greatest release of KC. Because is the only way to
> work closely with KC team.
>
> >
> > I understand that a separation of the two is needed on the longer run -
> it
> > would be good if that's something on our agenda post 1.1.0 e.g. for 1.2.0
> >
> > I think the above is a 'work around', which I could live with and buys us
> > time to truly think about a perfect separation.
>
> My 2 cents here and my humble opinion is the fact that we don't need
> perfection,
> only the correct. Today, split Keycloak and UPS would the most
> correct thing to do. I'm not saying what we're doing here is dead wrong,
> but
> sooner or later the problem will hit us anyway.
>
> So maybe we should attack the problem now?
>
> >
> >
> >
> >
> >
> >
> > On Thu, May 7, 2015 at 3:26 AM, Matthias Wessendorf <matzew at apache.org>
> > wrote:
> >
> > >
> > >
> > > On Wed, May 6, 2015 at 8:27 PM, Douglas Campos <qmx at qmx.me> wrote:
> > >
> > >> Howdy y'all!
> > >>
> > >> I'm revisiting migration strategies for UPS master, and we have a
> tough
> > >> situation to deal with.
> > >>
> > >> Since we have moved keycloak to its own DataSource, there are KC
> > >> leftovers at UPS database which need to be cleaned up.
> > >>
> > >> 1) Any suggestions on how to provide a migration path?
> > >>   Since the tables are intertwined with UPS tables, it's not a matter
> of
> > >> doing a db dump/restore...
> > >>
> > >
> > > how are they intertwined? Is UPS stuff stored in KC tables, or vice
> versa?
> > >
> > >
> > >> 2) How to ensure we can safely get rid of the leftover tables on UPS
> > >> DataSource?
> > >>   I can easily provide migrations which just nuke the tables from the
> > >> face of the earth,
> > >>
> > >
> > > that's good, but
> > >
> > >
> > >> but how to do this without data loss?
> > >>
> > >
> > > I don't know :-) I wonder if we just can not move the data to a new
> > > datasource.
> > >
> > >
> > >
> > >
> > >
> > >>
> > >> Thoughts?
> > >>
> > >> _______________________________________________
> > >> aerogear-dev mailing list
> > >> aerogear-dev at lists.jboss.org
> > >> https://lists.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
>
>
> --
>
> abstractj
> PGP: 0x84DC9914
> _______________________________________________
> 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/20150511/71880924/attachment.html 

From qmx at qmx.me  Mon May 11 17:29:48 2015
From: qmx at qmx.me (Douglas Campos)
Date: Mon, 11 May 2015 18:29:48 -0300
Subject: [aerogear-dev] Dealing with UPS Keycloak data
	post-datasource-split
In-Reply-To: <CAD_dpu2RUbh_2Yt6dc5+nf_ykyUX2msKUiR1XDfLNky-MbaNtw@mail.gmail.com>
References: <CAN-DfD5v6svHbP63QvhVHCzfKxY2Bmgy0Pq3jVYRND_jvKeN_w@mail.gmail.com>
	<CAAg5f2Trqwrg46PwY4+ZtUR9ymRvSoX3f0rYr5uxO7t2oRHpoQ@mail.gmail.com>
	<CAAg5f2T7zOkVQU8oKptCOJCb1nd8Um9jLo-5FqTHSSufgzdrkA@mail.gmail.com>
	<20150511211149.GC99477@abstractj.org>
	<CAD_dpu2RUbh_2Yt6dc5+nf_ykyUX2msKUiR1XDfLNky-MbaNtw@mail.gmail.com>
Message-ID: <CAN-DfD61J9wQjWw5pzGkRkAATOQs5d4TGT8YbKE6Rnu-ziiODw@mail.gmail.com>

On Mon, May 11, 2015 at 6:26 PM, Sebastien Blanc <scm.blanc at gmail.com>
wrote:

> What about dumping only the KC tables (they have no relation with the UPS
> table)  restore them on the KC separate datasource, apply migration on this
> datasource and then  nuke the old KC  tables on the initial DB. And finally
> applying the UPS migration path ?
>
Migrator tool has no support for moving data between databases. TL;DR is
that this would be a PITA to get right. Better call would be KC having
something like export/import in JSON or somesuch.


>
>
> On Mon, May 11, 2015 at 11:11 PM, Bruno Oliveira <bruno at abstractj.org>
> wrote:
>
>> Sorry if I'm late for this discussion.
>>
>> On 2015-05-07, Matthias Wessendorf wrote:
>> > How about the following, not optimal, proposal:
>> >
>> > * get back to one data-source
>>
>> I'm not against about it, if it's for the benefit of the project.
>>
>> > * stick w/ Keycloak-1.1.0-final (in case updating to KC-1.2.0 makes
>> above
>> > item harder)
>>
>> I don't get why master must be reverted to 1.1.0 final. I think stable
>> release of KC must go in 1.0.x series of UPS, but on master, we must
>> stick with the latest greatest release of KC. Because is the only way to
>> work closely with KC team.
>>
>> >
>> > I understand that a separation of the two is needed on the longer run -
>> it
>> > would be good if that's something on our agenda post 1.1.0 e.g. for
>> 1.2.0
>> >
>> > I think the above is a 'work around', which I could live with and buys
>> us
>> > time to truly think about a perfect separation.
>>
>> My 2 cents here and my humble opinion is the fact that we don't need
>> perfection,
>> only the correct. Today, split Keycloak and UPS would the most
>> correct thing to do. I'm not saying what we're doing here is dead wrong,
>> but
>> sooner or later the problem will hit us anyway.
>>
>> So maybe we should attack the problem now?
>>
>> >
>> >
>> >
>> >
>> >
>> >
>> > On Thu, May 7, 2015 at 3:26 AM, Matthias Wessendorf <matzew at apache.org>
>> > wrote:
>> >
>> > >
>> > >
>> > > On Wed, May 6, 2015 at 8:27 PM, Douglas Campos <qmx at qmx.me> wrote:
>> > >
>> > >> Howdy y'all!
>> > >>
>> > >> I'm revisiting migration strategies for UPS master, and we have a
>> tough
>> > >> situation to deal with.
>> > >>
>> > >> Since we have moved keycloak to its own DataSource, there are KC
>> > >> leftovers at UPS database which need to be cleaned up.
>> > >>
>> > >> 1) Any suggestions on how to provide a migration path?
>> > >>   Since the tables are intertwined with UPS tables, it's not a
>> matter of
>> > >> doing a db dump/restore...
>> > >>
>> > >
>> > > how are they intertwined? Is UPS stuff stored in KC tables, or vice
>> versa?
>> > >
>> > >
>> > >> 2) How to ensure we can safely get rid of the leftover tables on UPS
>> > >> DataSource?
>> > >>   I can easily provide migrations which just nuke the tables from the
>> > >> face of the earth,
>> > >>
>> > >
>> > > that's good, but
>> > >
>> > >
>> > >> but how to do this without data loss?
>> > >>
>> > >
>> > > I don't know :-) I wonder if we just can not move the data to a new
>> > > datasource.
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >>
>> > >> Thoughts?
>> > >>
>> > >> _______________________________________________
>> > >> aerogear-dev mailing list
>> > >> aerogear-dev at lists.jboss.org
>> > >> https://lists.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
>>
>>
>> --
>>
>> abstractj
>> PGP: 0x84DC9914
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.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/20150511/92bda91d/attachment-0001.html 

From scm.blanc at gmail.com  Mon May 11 17:32:52 2015
From: scm.blanc at gmail.com (Sebastien Blanc)
Date: Mon, 11 May 2015 23:32:52 +0200
Subject: [aerogear-dev] Dealing with UPS Keycloak data
	post-datasource-split
In-Reply-To: <CAN-DfD61J9wQjWw5pzGkRkAATOQs5d4TGT8YbKE6Rnu-ziiODw@mail.gmail.com>
References: <CAN-DfD5v6svHbP63QvhVHCzfKxY2Bmgy0Pq3jVYRND_jvKeN_w@mail.gmail.com>
	<CAAg5f2Trqwrg46PwY4+ZtUR9ymRvSoX3f0rYr5uxO7t2oRHpoQ@mail.gmail.com>
	<CAAg5f2T7zOkVQU8oKptCOJCb1nd8Um9jLo-5FqTHSSufgzdrkA@mail.gmail.com>
	<20150511211149.GC99477@abstractj.org>
	<CAD_dpu2RUbh_2Yt6dc5+nf_ykyUX2msKUiR1XDfLNky-MbaNtw@mail.gmail.com>
	<CAN-DfD61J9wQjWw5pzGkRkAATOQs5d4TGT8YbKE6Rnu-ziiODw@mail.gmail.com>
Message-ID: <CAD_dpu1bJu=UdqAmJe7QvE2Xbf2UpDwqJrRLHLtj462mUoqS7w@mail.gmail.com>

That could be our solution no ?
http://docs.jboss.org/keycloak/docs/1.2.0.CR1/userguide/html/Migration_from_older_versions.html#d4e3089


On Mon, May 11, 2015 at 11:29 PM, Douglas Campos <qmx at qmx.me> wrote:

>
>
> On Mon, May 11, 2015 at 6:26 PM, Sebastien Blanc <scm.blanc at gmail.com>
> wrote:
>
>> What about dumping only the KC tables (they have no relation with the UPS
>> table)  restore them on the KC separate datasource, apply migration on this
>> datasource and then  nuke the old KC  tables on the initial DB. And finally
>> applying the UPS migration path ?
>>
> Migrator tool has no support for moving data between databases. TL;DR is
> that this would be a PITA to get right. Better call would be KC having
> something like export/import in JSON or somesuch.
>
>
>>
>>
>> On Mon, May 11, 2015 at 11:11 PM, Bruno Oliveira <bruno at abstractj.org>
>> wrote:
>>
>>> Sorry if I'm late for this discussion.
>>>
>>> On 2015-05-07, Matthias Wessendorf wrote:
>>> > How about the following, not optimal, proposal:
>>> >
>>> > * get back to one data-source
>>>
>>> I'm not against about it, if it's for the benefit of the project.
>>>
>>> > * stick w/ Keycloak-1.1.0-final (in case updating to KC-1.2.0 makes
>>> above
>>> > item harder)
>>>
>>> I don't get why master must be reverted to 1.1.0 final. I think stable
>>> release of KC must go in 1.0.x series of UPS, but on master, we must
>>> stick with the latest greatest release of KC. Because is the only way to
>>> work closely with KC team.
>>>
>>> >
>>> > I understand that a separation of the two is needed on the longer run
>>> - it
>>> > would be good if that's something on our agenda post 1.1.0 e.g. for
>>> 1.2.0
>>> >
>>> > I think the above is a 'work around', which I could live with and buys
>>> us
>>> > time to truly think about a perfect separation.
>>>
>>> My 2 cents here and my humble opinion is the fact that we don't need
>>> perfection,
>>> only the correct. Today, split Keycloak and UPS would the most
>>> correct thing to do. I'm not saying what we're doing here is dead wrong,
>>> but
>>> sooner or later the problem will hit us anyway.
>>>
>>> So maybe we should attack the problem now?
>>>
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > On Thu, May 7, 2015 at 3:26 AM, Matthias Wessendorf <matzew at apache.org
>>> >
>>> > wrote:
>>> >
>>> > >
>>> > >
>>> > > On Wed, May 6, 2015 at 8:27 PM, Douglas Campos <qmx at qmx.me> wrote:
>>> > >
>>> > >> Howdy y'all!
>>> > >>
>>> > >> I'm revisiting migration strategies for UPS master, and we have a
>>> tough
>>> > >> situation to deal with.
>>> > >>
>>> > >> Since we have moved keycloak to its own DataSource, there are KC
>>> > >> leftovers at UPS database which need to be cleaned up.
>>> > >>
>>> > >> 1) Any suggestions on how to provide a migration path?
>>> > >>   Since the tables are intertwined with UPS tables, it's not a
>>> matter of
>>> > >> doing a db dump/restore...
>>> > >>
>>> > >
>>> > > how are they intertwined? Is UPS stuff stored in KC tables, or vice
>>> versa?
>>> > >
>>> > >
>>> > >> 2) How to ensure we can safely get rid of the leftover tables on UPS
>>> > >> DataSource?
>>> > >>   I can easily provide migrations which just nuke the tables from
>>> the
>>> > >> face of the earth,
>>> > >>
>>> > >
>>> > > that's good, but
>>> > >
>>> > >
>>> > >> but how to do this without data loss?
>>> > >>
>>> > >
>>> > > I don't know :-) I wonder if we just can not move the data to a new
>>> > > datasource.
>>> > >
>>> > >
>>> > >
>>> > >
>>> > >
>>> > >>
>>> > >> Thoughts?
>>> > >>
>>> > >> _______________________________________________
>>> > >> aerogear-dev mailing list
>>> > >> aerogear-dev at lists.jboss.org
>>> > >> https://lists.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
>>>
>>>
>>> --
>>>
>>> abstractj
>>> PGP: 0x84DC9914
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev at lists.jboss.org
>>> https://lists.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/20150511/42ffc358/attachment.html 

From qmx at qmx.me  Mon May 11 17:38:04 2015
From: qmx at qmx.me (Douglas Campos)
Date: Mon, 11 May 2015 18:38:04 -0300
Subject: [aerogear-dev] Dealing with UPS Keycloak data
	post-datasource-split
In-Reply-To: <CAD_dpu1bJu=UdqAmJe7QvE2Xbf2UpDwqJrRLHLtj462mUoqS7w@mail.gmail.com>
References: <CAN-DfD5v6svHbP63QvhVHCzfKxY2Bmgy0Pq3jVYRND_jvKeN_w@mail.gmail.com>
	<CAAg5f2Trqwrg46PwY4+ZtUR9ymRvSoX3f0rYr5uxO7t2oRHpoQ@mail.gmail.com>
	<CAAg5f2T7zOkVQU8oKptCOJCb1nd8Um9jLo-5FqTHSSufgzdrkA@mail.gmail.com>
	<20150511211149.GC99477@abstractj.org>
	<CAD_dpu2RUbh_2Yt6dc5+nf_ykyUX2msKUiR1XDfLNky-MbaNtw@mail.gmail.com>
	<CAN-DfD61J9wQjWw5pzGkRkAATOQs5d4TGT8YbKE6Rnu-ziiODw@mail.gmail.com>
	<CAD_dpu1bJu=UdqAmJe7QvE2Xbf2UpDwqJrRLHLtj462mUoqS7w@mail.gmail.com>
Message-ID: <CAN-DfD5NRk6zJRVzaQ0m0=E0GCF44wokGH=vwmaFZT1ZNVabwA@mail.gmail.com>

On Mon, May 11, 2015 at 6:32 PM, Sebastien Blanc <scm.blanc at gmail.com>
wrote:

> That could be our solution no ?
> http://docs.jboss.org/keycloak/docs/1.2.0.CR1/userguide/html/Migration_from_older_versions.html#d4e3089
>
nope - the thing is moving data **between** datasources - this is only for
updating the DB schema to one datasource


>
>
> On Mon, May 11, 2015 at 11:29 PM, Douglas Campos <qmx at qmx.me> wrote:
>
>>
>>
>> On Mon, May 11, 2015 at 6:26 PM, Sebastien Blanc <scm.blanc at gmail.com>
>> wrote:
>>
>>> What about dumping only the KC tables (they have no relation with the
>>> UPS table)  restore them on the KC separate datasource, apply migration on
>>> this datasource and then  nuke the old KC  tables on the initial DB. And
>>> finally applying the UPS migration path ?
>>>
>> Migrator tool has no support for moving data between databases. TL;DR is
>> that this would be a PITA to get right. Better call would be KC having
>> something like export/import in JSON or somesuch.
>>
>>
>>>
>>>
>>> On Mon, May 11, 2015 at 11:11 PM, Bruno Oliveira <bruno at abstractj.org>
>>> wrote:
>>>
>>>> Sorry if I'm late for this discussion.
>>>>
>>>> On 2015-05-07, Matthias Wessendorf wrote:
>>>> > How about the following, not optimal, proposal:
>>>> >
>>>> > * get back to one data-source
>>>>
>>>> I'm not against about it, if it's for the benefit of the project.
>>>>
>>>> > * stick w/ Keycloak-1.1.0-final (in case updating to KC-1.2.0 makes
>>>> above
>>>> > item harder)
>>>>
>>>> I don't get why master must be reverted to 1.1.0 final. I think stable
>>>> release of KC must go in 1.0.x series of UPS, but on master, we must
>>>> stick with the latest greatest release of KC. Because is the only way to
>>>> work closely with KC team.
>>>>
>>>> >
>>>> > I understand that a separation of the two is needed on the longer run
>>>> - it
>>>> > would be good if that's something on our agenda post 1.1.0 e.g. for
>>>> 1.2.0
>>>> >
>>>> > I think the above is a 'work around', which I could live with and
>>>> buys us
>>>> > time to truly think about a perfect separation.
>>>>
>>>> My 2 cents here and my humble opinion is the fact that we don't need
>>>> perfection,
>>>> only the correct. Today, split Keycloak and UPS would the most
>>>> correct thing to do. I'm not saying what we're doing here is dead
>>>> wrong, but
>>>> sooner or later the problem will hit us anyway.
>>>>
>>>> So maybe we should attack the problem now?
>>>>
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> > On Thu, May 7, 2015 at 3:26 AM, Matthias Wessendorf <
>>>> matzew at apache.org>
>>>> > wrote:
>>>> >
>>>> > >
>>>> > >
>>>> > > On Wed, May 6, 2015 at 8:27 PM, Douglas Campos <qmx at qmx.me> wrote:
>>>> > >
>>>> > >> Howdy y'all!
>>>> > >>
>>>> > >> I'm revisiting migration strategies for UPS master, and we have a
>>>> tough
>>>> > >> situation to deal with.
>>>> > >>
>>>> > >> Since we have moved keycloak to its own DataSource, there are KC
>>>> > >> leftovers at UPS database which need to be cleaned up.
>>>> > >>
>>>> > >> 1) Any suggestions on how to provide a migration path?
>>>> > >>   Since the tables are intertwined with UPS tables, it's not a
>>>> matter of
>>>> > >> doing a db dump/restore...
>>>> > >>
>>>> > >
>>>> > > how are they intertwined? Is UPS stuff stored in KC tables, or vice
>>>> versa?
>>>> > >
>>>> > >
>>>> > >> 2) How to ensure we can safely get rid of the leftover tables on
>>>> UPS
>>>> > >> DataSource?
>>>> > >>   I can easily provide migrations which just nuke the tables from
>>>> the
>>>> > >> face of the earth,
>>>> > >>
>>>> > >
>>>> > > that's good, but
>>>> > >
>>>> > >
>>>> > >> but how to do this without data loss?
>>>> > >>
>>>> > >
>>>> > > I don't know :-) I wonder if we just can not move the data to a new
>>>> > > datasource.
>>>> > >
>>>> > >
>>>> > >
>>>> > >
>>>> > >
>>>> > >>
>>>> > >> Thoughts?
>>>> > >>
>>>> > >> _______________________________________________
>>>> > >> aerogear-dev mailing list
>>>> > >> aerogear-dev at lists.jboss.org
>>>> > >> https://lists.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
>>>>
>>>>
>>>> --
>>>>
>>>> abstractj
>>>> PGP: 0x84DC9914
>>>> _______________________________________________
>>>> aerogear-dev mailing list
>>>> aerogear-dev at lists.jboss.org
>>>> https://lists.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/20150511/9275c94e/attachment-0001.html 

From matzew at apache.org  Tue May 12 01:14:35 2015
From: matzew at apache.org (Matthias Wessendorf)
Date: Tue, 12 May 2015 07:14:35 +0200
Subject: [aerogear-dev] Dealing with UPS Keycloak data
	post-datasource-split
In-Reply-To: <20150511211149.GC99477@abstractj.org>
References: <CAN-DfD5v6svHbP63QvhVHCzfKxY2Bmgy0Pq3jVYRND_jvKeN_w@mail.gmail.com>
	<CAAg5f2Trqwrg46PwY4+ZtUR9ymRvSoX3f0rYr5uxO7t2oRHpoQ@mail.gmail.com>
	<CAAg5f2T7zOkVQU8oKptCOJCb1nd8Um9jLo-5FqTHSSufgzdrkA@mail.gmail.com>
	<20150511211149.GC99477@abstractj.org>
Message-ID: <CAAg5f2TRT0k7hRvMPmVYnYPfQEWE8J2Uc5aiU2SFEEft1FNXWQ@mail.gmail.com>

On Mon, May 11, 2015 at 11:11 PM, Bruno Oliveira <bruno at abstractj.org>
wrote:

> Sorry if I'm late for this discussion.
>
> On 2015-05-07, Matthias Wessendorf wrote:
> > How about the following, not optimal, proposal:
> >
> > * get back to one data-source
>
> I'm not against about it, if it's for the benefit of the project.
>
> > * stick w/ Keycloak-1.1.0-final (in case updating to KC-1.2.0 makes above
> > item harder)
>
> I don't get why master must be reverted to 1.1.0 final. I think stable
> release of KC must go in 1.0.x series of UPS, but on master, we must
> stick with the latest greatest release of KC. Because is the only way to
> work closely with KC team.
>

does their DB migration from their 1.0.5.Final to 1.2.0.CR1 work?
If yes -> alright, let's go w/ KC 1.2..CR - if not, well it's not the end
of the world to go back :-)


Or, we just do NOT support any KC db migration, just ours - that's fine w/
me...


>
> >
> > I understand that a separation of the two is needed on the longer run -
> it
> > would be good if that's something on our agenda post 1.1.0 e.g. for 1.2.0
> >
> > I think the above is a 'work around', which I could live with and buys us
> > time to truly think about a perfect separation.
>
> My 2 cents here and my humble opinion is the fact that we don't need
> perfection,
> only the correct. Today, split Keycloak and UPS would the most
> correct thing to do. I'm not saying what we're doing here is dead wrong,
> but
> sooner or later the problem will hit us anyway.
>
> So maybe we should attack the problem now?
>
> >
> >
> >
> >
> >
> >
> > On Thu, May 7, 2015 at 3:26 AM, Matthias Wessendorf <matzew at apache.org>
> > wrote:
> >
> > >
> > >
> > > On Wed, May 6, 2015 at 8:27 PM, Douglas Campos <qmx at qmx.me> wrote:
> > >
> > >> Howdy y'all!
> > >>
> > >> I'm revisiting migration strategies for UPS master, and we have a
> tough
> > >> situation to deal with.
> > >>
> > >> Since we have moved keycloak to its own DataSource, there are KC
> > >> leftovers at UPS database which need to be cleaned up.
> > >>
> > >> 1) Any suggestions on how to provide a migration path?
> > >>   Since the tables are intertwined with UPS tables, it's not a matter
> of
> > >> doing a db dump/restore...
> > >>
> > >
> > > how are they intertwined? Is UPS stuff stored in KC tables, or vice
> versa?
> > >
> > >
> > >> 2) How to ensure we can safely get rid of the leftover tables on UPS
> > >> DataSource?
> > >>   I can easily provide migrations which just nuke the tables from the
> > >> face of the earth,
> > >>
> > >
> > > that's good, but
> > >
> > >
> > >> but how to do this without data loss?
> > >>
> > >
> > > I don't know :-) I wonder if we just can not move the data to a new
> > > datasource.
> > >
> > >
> > >
> > >
> > >
> > >>
> > >> Thoughts?
> > >>
> > >> _______________________________________________
> > >> aerogear-dev mailing list
> > >> aerogear-dev at lists.jboss.org
> > >> https://lists.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
>
>
> --
>
> abstractj
> PGP: 0x84DC9914
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.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/20150512/37395f9f/attachment.html 

From matzew at apache.org  Tue May 12 01:24:24 2015
From: matzew at apache.org (Matthias Wessendorf)
Date: Tue, 12 May 2015 07:24:24 +0200
Subject: [aerogear-dev] Dealing with UPS Keycloak data
	post-datasource-split
In-Reply-To: <CAAg5f2TRT0k7hRvMPmVYnYPfQEWE8J2Uc5aiU2SFEEft1FNXWQ@mail.gmail.com>
References: <CAN-DfD5v6svHbP63QvhVHCzfKxY2Bmgy0Pq3jVYRND_jvKeN_w@mail.gmail.com>
	<CAAg5f2Trqwrg46PwY4+ZtUR9ymRvSoX3f0rYr5uxO7t2oRHpoQ@mail.gmail.com>
	<CAAg5f2T7zOkVQU8oKptCOJCb1nd8Um9jLo-5FqTHSSufgzdrkA@mail.gmail.com>
	<20150511211149.GC99477@abstractj.org>
	<CAAg5f2TRT0k7hRvMPmVYnYPfQEWE8J2Uc5aiU2SFEEft1FNXWQ@mail.gmail.com>
Message-ID: <CAAg5f2TNTW=LxWphFgDCEUccXDk8Yc5cvqDg65UbF9ov5yb9Vw@mail.gmail.com>

>From Stian on IRC

[07:20:00] *<matzew>* *stianst* DB migration from 1.0.5.Final to KC
1.2.0.CR1 is not working, like you hinted last night, right ? /cc
*abstractj*

[07:20:21] *<stianst>* matzew: yep, there's no chance it'll work



So, what does that mean? It means no DB migration support for KC database.
Perhaps that is OK,

I can't wrap my head around this now.


But the migration for our own schema should be possible w/ the help of the
migration tool - let's focus on that for now



On Tue, May 12, 2015 at 7:14 AM, Matthias Wessendorf <matzew at apache.org>
wrote:

>
>
> On Mon, May 11, 2015 at 11:11 PM, Bruno Oliveira <bruno at abstractj.org>
> wrote:
>
>> Sorry if I'm late for this discussion.
>>
>> On 2015-05-07, Matthias Wessendorf wrote:
>> > How about the following, not optimal, proposal:
>> >
>> > * get back to one data-source
>>
>> I'm not against about it, if it's for the benefit of the project.
>>
>> > * stick w/ Keycloak-1.1.0-final (in case updating to KC-1.2.0 makes
>> above
>> > item harder)
>>
>> I don't get why master must be reverted to 1.1.0 final. I think stable
>> release of KC must go in 1.0.x series of UPS, but on master, we must
>> stick with the latest greatest release of KC. Because is the only way to
>> work closely with KC team.
>>
>
> does their DB migration from their 1.0.5.Final to 1.2.0.CR1 work?
> If yes -> alright, let's go w/ KC 1.2..CR - if not, well it's not the end
> of the world to go back :-)
>
>
> Or, we just do NOT support any KC db migration, just ours - that's fine w/
> me...
>
>
>>
>> >
>> > I understand that a separation of the two is needed on the longer run -
>> it
>> > would be good if that's something on our agenda post 1.1.0 e.g. for
>> 1.2.0
>> >
>> > I think the above is a 'work around', which I could live with and buys
>> us
>> > time to truly think about a perfect separation.
>>
>> My 2 cents here and my humble opinion is the fact that we don't need
>> perfection,
>> only the correct. Today, split Keycloak and UPS would the most
>> correct thing to do. I'm not saying what we're doing here is dead wrong,
>> but
>> sooner or later the problem will hit us anyway.
>>
>> So maybe we should attack the problem now?
>>
>> >
>> >
>> >
>> >
>> >
>> >
>> > On Thu, May 7, 2015 at 3:26 AM, Matthias Wessendorf <matzew at apache.org>
>> > wrote:
>> >
>> > >
>> > >
>> > > On Wed, May 6, 2015 at 8:27 PM, Douglas Campos <qmx at qmx.me> wrote:
>> > >
>> > >> Howdy y'all!
>> > >>
>> > >> I'm revisiting migration strategies for UPS master, and we have a
>> tough
>> > >> situation to deal with.
>> > >>
>> > >> Since we have moved keycloak to its own DataSource, there are KC
>> > >> leftovers at UPS database which need to be cleaned up.
>> > >>
>> > >> 1) Any suggestions on how to provide a migration path?
>> > >>   Since the tables are intertwined with UPS tables, it's not a
>> matter of
>> > >> doing a db dump/restore...
>> > >>
>> > >
>> > > how are they intertwined? Is UPS stuff stored in KC tables, or vice
>> versa?
>> > >
>> > >
>> > >> 2) How to ensure we can safely get rid of the leftover tables on UPS
>> > >> DataSource?
>> > >>   I can easily provide migrations which just nuke the tables from the
>> > >> face of the earth,
>> > >>
>> > >
>> > > that's good, but
>> > >
>> > >
>> > >> but how to do this without data loss?
>> > >>
>> > >
>> > > I don't know :-) I wonder if we just can not move the data to a new
>> > > datasource.
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >>
>> > >> Thoughts?
>> > >>
>> > >> _______________________________________________
>> > >> aerogear-dev mailing list
>> > >> aerogear-dev at lists.jboss.org
>> > >> https://lists.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
>>
>>
>> --
>>
>> abstractj
>> PGP: 0x84DC9914
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.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/20150512/05dcf374/attachment.html 

From matzew at apache.org  Tue May 12 01:33:59 2015
From: matzew at apache.org (Matthias Wessendorf)
Date: Tue, 12 May 2015 07:33:59 +0200
Subject: [aerogear-dev] Dealing with UPS Keycloak data
	post-datasource-split
In-Reply-To: <CAAg5f2TNTW=LxWphFgDCEUccXDk8Yc5cvqDg65UbF9ov5yb9Vw@mail.gmail.com>
References: <CAN-DfD5v6svHbP63QvhVHCzfKxY2Bmgy0Pq3jVYRND_jvKeN_w@mail.gmail.com>
	<CAAg5f2Trqwrg46PwY4+ZtUR9ymRvSoX3f0rYr5uxO7t2oRHpoQ@mail.gmail.com>
	<CAAg5f2T7zOkVQU8oKptCOJCb1nd8Um9jLo-5FqTHSSufgzdrkA@mail.gmail.com>
	<20150511211149.GC99477@abstractj.org>
	<CAAg5f2TRT0k7hRvMPmVYnYPfQEWE8J2Uc5aiU2SFEEft1FNXWQ@mail.gmail.com>
	<CAAg5f2TNTW=LxWphFgDCEUccXDk8Yc5cvqDg65UbF9ov5yb9Vw@mail.gmail.com>
Message-ID: <CAAg5f2RFVEhyAzj0Bp6HNrY2DQOekhgaQcekJ6t5DOeBQ5yo+Q@mail.gmail.com>

I think this means:
* go w/ KC 1.2.0
* keep the separate KC datasource

For migration: I will write some text for KC db part: e.g. do some
export/import before getting on to UPS-1.1.0. IMO that's good enough...

On Tue, May 12, 2015 at 7:24 AM, Matthias Wessendorf <matzew at apache.org>
wrote:

> From Stian on IRC
>
> [07:20:00] *<matzew>* *stianst* DB migration from 1.0.5.Final to KC
> 1.2.0.CR1 is not working, like you hinted last night, right ? /cc
> *abstractj*
>
> [07:20:21] *<stianst>* matzew: yep, there's no chance it'll work
>
>
>
> So, what does that mean? It means no DB migration support for KC database.
> Perhaps that is OK,
>
> I can't wrap my head around this now.
>
>
> But the migration for our own schema should be possible w/ the help of the
> migration tool - let's focus on that for now
>
>
>
> On Tue, May 12, 2015 at 7:14 AM, Matthias Wessendorf <matzew at apache.org>
> wrote:
>
>>
>>
>> On Mon, May 11, 2015 at 11:11 PM, Bruno Oliveira <bruno at abstractj.org>
>> wrote:
>>
>>> Sorry if I'm late for this discussion.
>>>
>>> On 2015-05-07, Matthias Wessendorf wrote:
>>> > How about the following, not optimal, proposal:
>>> >
>>> > * get back to one data-source
>>>
>>> I'm not against about it, if it's for the benefit of the project.
>>>
>>> > * stick w/ Keycloak-1.1.0-final (in case updating to KC-1.2.0 makes
>>> above
>>> > item harder)
>>>
>>> I don't get why master must be reverted to 1.1.0 final. I think stable
>>> release of KC must go in 1.0.x series of UPS, but on master, we must
>>> stick with the latest greatest release of KC. Because is the only way to
>>> work closely with KC team.
>>>
>>
>> does their DB migration from their 1.0.5.Final to 1.2.0.CR1 work?
>> If yes -> alright, let's go w/ KC 1.2..CR - if not, well it's not the end
>> of the world to go back :-)
>>
>>
>> Or, we just do NOT support any KC db migration, just ours - that's fine
>> w/ me...
>>
>>
>>>
>>> >
>>> > I understand that a separation of the two is needed on the longer run
>>> - it
>>> > would be good if that's something on our agenda post 1.1.0 e.g. for
>>> 1.2.0
>>> >
>>> > I think the above is a 'work around', which I could live with and buys
>>> us
>>> > time to truly think about a perfect separation.
>>>
>>> My 2 cents here and my humble opinion is the fact that we don't need
>>> perfection,
>>> only the correct. Today, split Keycloak and UPS would the most
>>> correct thing to do. I'm not saying what we're doing here is dead wrong,
>>> but
>>> sooner or later the problem will hit us anyway.
>>>
>>> So maybe we should attack the problem now?
>>>
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > On Thu, May 7, 2015 at 3:26 AM, Matthias Wessendorf <matzew at apache.org
>>> >
>>> > wrote:
>>> >
>>> > >
>>> > >
>>> > > On Wed, May 6, 2015 at 8:27 PM, Douglas Campos <qmx at qmx.me> wrote:
>>> > >
>>> > >> Howdy y'all!
>>> > >>
>>> > >> I'm revisiting migration strategies for UPS master, and we have a
>>> tough
>>> > >> situation to deal with.
>>> > >>
>>> > >> Since we have moved keycloak to its own DataSource, there are KC
>>> > >> leftovers at UPS database which need to be cleaned up.
>>> > >>
>>> > >> 1) Any suggestions on how to provide a migration path?
>>> > >>   Since the tables are intertwined with UPS tables, it's not a
>>> matter of
>>> > >> doing a db dump/restore...
>>> > >>
>>> > >
>>> > > how are they intertwined? Is UPS stuff stored in KC tables, or vice
>>> versa?
>>> > >
>>> > >
>>> > >> 2) How to ensure we can safely get rid of the leftover tables on UPS
>>> > >> DataSource?
>>> > >>   I can easily provide migrations which just nuke the tables from
>>> the
>>> > >> face of the earth,
>>> > >>
>>> > >
>>> > > that's good, but
>>> > >
>>> > >
>>> > >> but how to do this without data loss?
>>> > >>
>>> > >
>>> > > I don't know :-) I wonder if we just can not move the data to a new
>>> > > datasource.
>>> > >
>>> > >
>>> > >
>>> > >
>>> > >
>>> > >>
>>> > >> Thoughts?
>>> > >>
>>> > >> _______________________________________________
>>> > >> aerogear-dev mailing list
>>> > >> aerogear-dev at lists.jboss.org
>>> > >> https://lists.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
>>>
>>>
>>> --
>>>
>>> abstractj
>>> PGP: 0x84DC9914
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev at lists.jboss.org
>>> https://lists.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
>



-- 
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/20150512/cd3c38d2/attachment-0001.html 

From matzew at apache.org  Tue May 12 01:38:22 2015
From: matzew at apache.org (Matthias Wessendorf)
Date: Tue, 12 May 2015 07:38:22 +0200
Subject: [aerogear-dev] Metrics Endpoint (was: Re: Advanced Analtyics,
 new PR and call to the client tech leads)
In-Reply-To: <20150511205626.GB99477@abstractj.org>
References: <CAAg5f2SVYYtv+hTcH=JkDkbjvGDyvLj4aG98HzY8nhK2uKnKRg@mail.gmail.com>
	<CADF=h2vfetc39f7xJyygHE5uj531tUc3xtzZu9=NePLD7DBtNg@mail.gmail.com>
	<CAAg5f2QqLCmJjQAr9nJN-aG_4z-yp1p=G292aYEfUFTq=_CnRw@mail.gmail.com>
	<CADF=h2s+VH-UtHkiEA68MKhD=K0HjNzV+6iS1R88Q4nU9-=qew@mail.gmail.com>
	<CAO2B-fZ9d7P8gervDCGXnX703ZJ1a=UciwH1mMrg5rt75KzXxQ@mail.gmail.com>
	<CADF=h2scyWsrpARbkCesQ=HVJWJXHJkka3v9kr-DRcvFdprTxg@mail.gmail.com>
	<CAAg5f2ToKhNvJomxTN2PNqarN+JA_FRr4V_3GB+DutGmE8CZqw@mail.gmail.com>
	<CAL8vO=cvkk-fZAmvuSkf+jKaY3j5MLmqSWSPbdpbqcop9BPOhA@mail.gmail.com>
	<CAD_dpu2TXgzgcSomqVNSM-RAboir0_E+MdmwBXguLb9jSXroDA@mail.gmail.com>
	<20150511205626.GB99477@abstractj.org>
Message-ID: <CAAg5f2QXzPGMZRtzH3XMhbYjaPqrKinuqci3-rMFGmqSHT1n-A@mail.gmail.com>

On Mon, May 11, 2015 at 10:56 PM, Bruno Oliveira <bruno at abstractj.org>
wrote:

> On 2015-05-11, Sebastien Blanc wrote:
> > Let's start with the "semi-automatic" approach ;)
>
> I think by "semi-automatic" you mean "it's up to the developer", right?
> If yes, +1.
>
> Another question is: Is another HTTP request required only
> to feed metrics? I'm thinking about people with very limited data plans.
> If yes, that's definitely must be optional.
>
> Also, do we have documented in some place what we are collecting?
> >From our guide I have:
>
> "For analytic purposes on our Dashboard we store the content of the
> alert key sent to the UnifiedPush Server. The content of the alert key
> belongs to the metadata, which is deleted after 30 days, using a nightly
> job within the UnifiedPush Server."
>

the collecting of pay, which you quoted is documented, yes (it is true for
1.0.3 already)

That we collect the open is NOT yet documented. It is part of 1.1.0.Fianl
doc, of the new UI.
I will update the "warning" section on the begining as well, not just
mention the new stats on the UI parts.

makes sense ?



>
> If we reach an agreement on it, test the endpoint against DDoS might be
> required.
>
> > @passos : maybe you can use the same method's name to keep it unified ?
> (we
> > can always change the names later)
> >
> >
> > On Mon, May 11, 2015 at 3:48 PM, Corinne Krych <corinnekrych at gmail.com>
> > wrote:
> >
> > > Yeap all is in "semi".
> > > for iOs we'll have 2 public static methods:
> > >
> > > AGPushAnalytics.sendMetricWhenAppLaunched(serverURL: NSURL,
> > > launchOptions: [NSObject:AnyObject]?)
> > > AGPushAnalytics.sendMetricsWhenAppAwoken(serverURL: NSURL,
> > > applicationState: UIApplicationState, userInfo: [NSObject:AnyObject])
> > >
> > > If we want all automation we have to provide more wrapping around
> native
> > > life cycle, which can be quite intrusive.
> > >
> > > ++
> > > Corinne
> > >
> > > On 11 May 2015 at 15:44, Matthias Wessendorf <matzew at apache.org>
> wrote:
> > >
> > >> iOS is also semi automatic ;-)
> > >>
> > >> On Mon, May 11, 2015 at 3:41 PM, Daniel Passos <dpassos at redhat.com>
> > >> wrote:
> > >>
> > >>> Of course. My point was just to be clear we can't do it "automatic"
> :)
> > >>>
> > >>> On Mon, May 11, 2015 at 10:39 AM, Erik Jan de Wit <edewit at redhat.com
> >
> > >>> wrote:
> > >>>
> > >>>> but the android sdk could have a method for uploading the metrics,
> so
> > >>>> that a developer can opt for having that displayed on the dashboard.
> > >>>>
> > >>>> This method can then also be used for cordova ;)
> > >>>>
> > >>>> On Mon, May 11, 2015 at 3:30 PM, Daniel Passos <dpassos at redhat.com>
> > >>>> wrote:
> > >>>> > On Fri, May 8, 2015 at 2:10 AM, Matthias Wessendorf <
> > >>>> matzew at apache.org>
> > >>>> > wrote:
> > >>>> >>
> > >>>> >>
> > >>>> >>
> > >>>> >> On Thu, May 7, 2015 at 11:58 PM, Daniel Passos <
> dpassos at redhat.com>
> > >>>> wrote:
> > >>>> >>>
> > >>>> >>> Just to be clear, we are talking about metrics for messages
> > >>>> delivered
> > >>>> >>> (received on device) or about really read/open?
> > >>>> >>>
> > >>>> >>> Because in Android land is not possible know when message was
> > >>>> >>> read/opened. We delegate how the message will be
> delivered/showed
> > >>>> to the
> > >>>> >>> MessageHandler[1] and we don't have access to it.
> > >>>> >>
> > >>>> >>
> > >>>> >> when the user clicks on the message, the app opens. That's what
> we
> > >>>> track
> > >>>> >> w/ this PR, not the actual: I read the message - more "App was
> > >>>> opened due to
> > >>>> >> push", see:
> > >>>> >> https://issues.jboss.org/browse/AGPUSH-971
> > >>>> >
> > >>>> >
> > >>>> > I can't do that. I can't do an action when app was opened. To do
> that
> > >>>> we
> > >>>> > would need to create our own application[1] class, and all
> projects
> > >>>> would
> > >>>> > need to extend it. As I have told in my previous email, for now I
> > >>>> only can
> > >>>> > do something when the message is delivered to the device.
> > >>>> >
> > >>>> > [1]
> > >>>> http://developer.android.com/reference/android/app/Application.html
> > >>>> >
> > >>>> >>
> > >>>> >>>
> > >>>> >>>
> > >>>> >>> Today we only have access when the message is delivered.
> Basically
> > >>>> we
> > >>>> >>> receive the message in a AeroGearGCMMessageReceiver[2] do some
> > >>>> checks and
> > >>>> >>> push the message for all Handles registered[3][4]
> > >>>> >>>
> > >>>> >>> [1]
> > >>>> >>>
> > >>>>
> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/MessageHandler.java
> > >>>> >>> [2]
> > >>>> >>>
> > >>>>
> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/gcm/AeroGearGCMMessageReceiver.java
> > >>>> >>> [3]
> > >>>> >>>
> > >>>>
> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/RegistrarManager.java#L118
> > >>>> >>> [4]
> > >>>> >>>
> > >>>>
> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/RegistrarManager.java#L130
> > >>>> >>>
> > >>>> >>> -- Passos
> > >>>> >>>
> > >>>> >>>
> > >>>> >>> On Wed, May 6, 2015 at 6:38 AM, Matthias Wessendorf <
> > >>>> matzew at apache.org>
> > >>>> >>> wrote:
> > >>>> >>>>
> > >>>> >>>> Hi,
> > >>>> >>>>
> > >>>> >>>> as discussed on the previous thread, there will be a new
> endpoint
> > >>>> to
> > >>>> >>>> 'track' the "App opened/launched due to received push
> > >>>> notification".
> > >>>> >>>>
> > >>>> >>>> Internally, on the UPS, the Push Message has an ID, which get's
> > >>>> append
> > >>>> >>>> to the payload of the notification, like here:
> > >>>> >>>>
> > >>>> >>>>
> > >>>>
> https://github.com/matzew/aerogear-unifiedpush-server/blob/analytics/push/sender/src/main/java/org/jboss/aerogear/unifiedpush/message/sender/APNsPushNotificationSender.java#L107-L108
> > >>>> >>>>
> > >>>> >>>> On the client SDKs this will be read and a HTTP call made to
> the
> > >>>> soon
> > >>>> >>>> introduced MetricsEndpoint. Currently this info is send to the
> > >>>> >>>> RegistrationEndpoint, including the deviceToken/registrationId.
> > >>>> However, I
> > >>>> >>>> think that the deviceToken/registrationId is currently not
> needed
> > >>>> for
> > >>>> >>>> metrics, since we are just interested in anonymous "app
> > >>>> launched/opened due
> > >>>> >>>> to push", and not a specific "DEVICE X did open, while DEVICE Y
> > >>>> did not yet
> > >>>> >>>> open".
> > >>>> >>>>
> > >>>> >>>> So all we really need is the ID of the push notification, to be
> > >>>> >>>> processed by our Metrics Service
> > >>>> >>>>
> > >>>> >>>>
> > >>>>
> https://github.com/matzew/aerogear-unifiedpush-server/blob/analytics/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/registry/installations/InstallationRegistrationEndpoint.java#L128-L133
> > >>>> >>>>
> > >>>> >>>> Therefore my proposal is have an endpoint:
> > >>>> >>>>
> > >>>> >>>> PUT /metrics/pushmessage/{pushMessageID}
> > >>>> >>>>
> > >>>> >>>> I think PUT is good/best, because there is nothing really
> created
> > >>>> on the
> > >>>> >>>> server, it's more updating the 'counter' on the existing
> > >>>> >>>> PushMessageInformation object.
> > >>>> >>>>
> > >>>> >>>> Thoughts?
> > >>>> >>>> -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
> > >>>> >
> > >>>> >
> > >>>> >
> > >>>> >
> > >>>> > --
> > >>>> > -- Passos
> > >>>> >
> > >>>> > _______________________________________________
> > >>>> > aerogear-dev mailing list
> > >>>> > aerogear-dev at lists.jboss.org
> > >>>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > >>>>
> > >>>>
> > >>>>
> > >>>> --
> > >>>> Cheers,
> > >>>>        Erik Jan
> > >>>> _______________________________________________
> > >>>> aerogear-dev mailing list
> > >>>> aerogear-dev at lists.jboss.org
> > >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > >>>>
> > >>>
> > >>>
> > >>>
> > >>> --
> > >>> -- Passos
> > >>>
> > >>> _______________________________________________
> > >>> aerogear-dev mailing list
> > >>> aerogear-dev at lists.jboss.org
> > >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > >>>
> > >>
> > >>
> > >>
> > >> --
> > >> Matthias Wessendorf
> > >>
> > >> blog: http://matthiaswessendorf.wordpress.com/
> > >> sessions: http://www.slideshare.net/mwessendorf
> > >> twitter: http://twitter.com/mwessendorf
> > >>
> > >> _______________________________________________
> > >> aerogear-dev mailing list
> > >> aerogear-dev at lists.jboss.org
> > >> https://lists.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
>
>
> --
>
> abstractj
> PGP: 0x84DC9914
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.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/20150512/5bd4e446/attachment-0001.html 

From cvasilak at gmail.com  Tue May 12 05:18:05 2015
From: cvasilak at gmail.com (Christos Vasilakis)
Date: Tue, 12 May 2015 12:18:05 +0300
Subject: [aerogear-dev] Push HelloWorld demo
Message-ID: <CAKVvow-MnQaHqQnC6ryNwFpchEui0bsxXsiYO4bURceVeknA7A@mail.gmail.com>

Hi there,

currently on our iOS push guide[1] we use a generic HelloWorld demo located
in [2]. What do you think if we replace it with the more polished one in
[3]. If so can open PR to update the guide too.

Thoughts?

-
Christos


[1] https://aerogear.org/docs/unifiedpush/aerogear-push-ios/guides/#ios-app
[2] https://github.com/aerogear/aerogear-push-ios-demo
[3] https://github.com/jboss-mobile/unified-push-helloworld.git
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20150512/99778f8a/attachment.html 

From scm.blanc at gmail.com  Tue May 12 05:20:27 2015
From: scm.blanc at gmail.com (Sebastien Blanc)
Date: Tue, 12 May 2015 11:20:27 +0200
Subject: [aerogear-dev] Push HelloWorld demo
In-Reply-To: <CAKVvow-MnQaHqQnC6ryNwFpchEui0bsxXsiYO4bURceVeknA7A@mail.gmail.com>
References: <CAKVvow-MnQaHqQnC6ryNwFpchEui0bsxXsiYO4bURceVeknA7A@mail.gmail.com>
Message-ID: <CAD_dpu0cC1DLh-xZqgyxLAut7=67oDScozUG_NZSMStQS-tdZA@mail.gmail.com>

+1
Easier to maintain


On Tue, May 12, 2015 at 11:18 AM, Christos Vasilakis <cvasilak at gmail.com>
wrote:

> Hi there,
>
> currently on our iOS push guide[1] we use a generic HelloWorld demo
> located in [2]. What do you think if we replace it with the more polished
> one in [3]. If so can open PR to update the guide too.
>
> Thoughts?
>
> -
> Christos
>
>
> [1]
> https://aerogear.org/docs/unifiedpush/aerogear-push-ios/guides/#ios-app
> [2] https://github.com/aerogear/aerogear-push-ios-demo
> [3] https://github.com/jboss-mobile/unified-push-helloworld.git
>
> _______________________________________________
> 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/20150512/9e88f785/attachment.html 

From corinnekrych at gmail.com  Tue May 12 05:31:38 2015
From: corinnekrych at gmail.com (Corinne Krych)
Date: Tue, 12 May 2015 11:31:38 +0200
Subject: [aerogear-dev] Push HelloWorld demo
In-Reply-To: <CAKVvow-MnQaHqQnC6ryNwFpchEui0bsxXsiYO4bURceVeknA7A@mail.gmail.com>
References: <CAKVvow-MnQaHqQnC6ryNwFpchEui0bsxXsiYO4bURceVeknA7A@mail.gmail.com>
Message-ID: <CAL8vO=cRPZeieM8DhPW+ArSXCs_6WTPFNSgGEZg7Ab5=T2YLOw@mail.gmail.com>

+1 let's deprecate https://github.com/aerogear/aerogear-push-ios-demo in
favor of HelloWorld.
++
Corinne


On 12 May 2015 at 11:18, Christos Vasilakis <cvasilak at gmail.com> wrote:

> Hi there,
>
> currently on our iOS push guide[1] we use a generic HelloWorld demo
> located in [2]. What do you think if we replace it with the more polished
> one in [3]. If so can open PR to update the guide too.
>
> Thoughts?
>
> -
> Christos
>
>
> [1]
> https://aerogear.org/docs/unifiedpush/aerogear-push-ios/guides/#ios-app
> [2] https://github.com/aerogear/aerogear-push-ios-demo
> [3] https://github.com/jboss-mobile/unified-push-helloworld.git
>
> _______________________________________________
> 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/20150512/2acc9bc7/attachment.html 

From dpassos at redhat.com  Tue May 12 08:10:13 2015
From: dpassos at redhat.com (Daniel Passos)
Date: Tue, 12 May 2015 09:10:13 -0300
Subject: [aerogear-dev] Push HelloWorld demo
In-Reply-To: <CAL8vO=cRPZeieM8DhPW+ArSXCs_6WTPFNSgGEZg7Ab5=T2YLOw@mail.gmail.com>
References: <CAKVvow-MnQaHqQnC6ryNwFpchEui0bsxXsiYO4bURceVeknA7A@mail.gmail.com>
	<CAL8vO=cRPZeieM8DhPW+ArSXCs_6WTPFNSgGEZg7Ab5=T2YLOw@mail.gmail.com>
Message-ID: <CADF=h2uHQ=ErMq9N42=aAd2GYuws5VjBuqoQNApVyOHGu+NHyg@mail.gmail.com>

+1

On Tue, May 12, 2015 at 6:31 AM, Corinne Krych <corinnekrych at gmail.com>
wrote:

> +1 let's deprecate https://github.com/aerogear/aerogear-push-ios-demo in
> favor of HelloWorld.
> ++
> Corinne
>
>
> On 12 May 2015 at 11:18, Christos Vasilakis <cvasilak at gmail.com> wrote:
>
>> Hi there,
>>
>> currently on our iOS push guide[1] we use a generic HelloWorld demo
>> located in [2]. What do you think if we replace it with the more polished
>> one in [3]. If so can open PR to update the guide too.
>>
>> Thoughts?
>>
>> -
>> Christos
>>
>>
>> [1]
>> https://aerogear.org/docs/unifiedpush/aerogear-push-ios/guides/#ios-app
>> [2] https://github.com/aerogear/aerogear-push-ios-demo
>> [3] https://github.com/jboss-mobile/unified-push-helloworld.git
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>



-- 
-- Passos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20150512/8174874e/attachment.html 

From bruno at abstractj.org  Tue May 12 09:18:19 2015
From: bruno at abstractj.org (Bruno Oliveira)
Date: Tue, 12 May 2015 06:18:19 -0700 (PDT)
Subject: [aerogear-dev] Push HelloWorld demo
In-Reply-To: <CAD_dpu0cC1DLh-xZqgyxLAut7=67oDScozUG_NZSMStQS-tdZA@mail.gmail.com>
References: <CAD_dpu0cC1DLh-xZqgyxLAut7=67oDScozUG_NZSMStQS-tdZA@mail.gmail.com>
Message-ID: <1431436698576.1c5588c3@Nodemailer>

+1



?
abstractj 
PGP: 0x84DC9914

On Tue, May 12, 2015 at 6:20 AM, Sebastien Blanc <scm.blanc at gmail.com>
wrote:

> +1
> Easier to maintain
> On Tue, May 12, 2015 at 11:18 AM, Christos Vasilakis <cvasilak at gmail.com>
> wrote:
>> Hi there,
>>
>> currently on our iOS push guide[1] we use a generic HelloWorld demo
>> located in [2]. What do you think if we replace it with the more polished
>> one in [3]. If so can open PR to update the guide too.
>>
>> Thoughts?
>>
>> -
>> Christos
>>
>>
>> [1]
>> https://aerogear.org/docs/unifiedpush/aerogear-push-ios/guides/#ios-app
>> [2] https://github.com/aerogear/aerogear-push-ios-demo
>> [3] https://github.com/jboss-mobile/unified-push-helloworld.git
>>
>> _______________________________________________
>> 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/20150512/b550bfa0/attachment.html 

From edewit at redhat.com  Wed May 13 04:26:11 2015
From: edewit at redhat.com (Erik Jan de Wit)
Date: Wed, 13 May 2015 10:26:11 +0200
Subject: [aerogear-dev] Fwd: PushPlugin release 1.0.3
In-Reply-To: <CAO2B-fbhsdS6DDGg-UgTJX-E+s09W-ospPWeA-GCB-Ba3Ldspw@mail.gmail.com>
References: <CAO2B-fbhsdS6DDGg-UgTJX-E+s09W-ospPWeA-GCB-Ba3Ldspw@mail.gmail.com>
Message-ID: <CAO2B-fauiCuWypZFKRM_NWU9fzg3i4y3oCQGb1C3Fu2AZjTUAQ@mail.gmail.com>

Hi,

Where pleased to announce that the plugin version 1.0.3 has been released.

Release notes:

Bug

[AGCORDOVA-38] - Authorisation error iOS is to big

Feature Request

[AGCORDOVA-76] - Update Push SDK to Android 1.0.1


--
Cheers,
       Erik Jan

From matzew at apache.org  Wed May 13 04:47:39 2015
From: matzew at apache.org (Matthias Wessendorf)
Date: Wed, 13 May 2015 10:47:39 +0200
Subject: [aerogear-dev] [Aerogear-users] Fwd: PushPlugin release 1.0.3
In-Reply-To: <CAO2B-fauiCuWypZFKRM_NWU9fzg3i4y3oCQGb1C3Fu2AZjTUAQ@mail.gmail.com>
References: <CAO2B-fbhsdS6DDGg-UgTJX-E+s09W-ospPWeA-GCB-Ba3Ldspw@mail.gmail.com>
	<CAO2B-fauiCuWypZFKRM_NWU9fzg3i4y3oCQGb1C3Fu2AZjTUAQ@mail.gmail.com>
Message-ID: <CAAg5f2SqwNVC2Ld9hMd2JaQiepxcXxJuhAcyOPfz2KnQZYu0WQ@mail.gmail.com>

yay!!

On Wed, May 13, 2015 at 10:26 AM, Erik Jan de Wit <edewit at redhat.com> wrote:

> Hi,
>
> Where pleased to announce that the plugin version 1.0.3 has been released.
>
> Release notes:
>
> Bug
>
> [AGCORDOVA-38] - Authorisation error iOS is to big
>
> Feature Request
>
> [AGCORDOVA-76] - Update Push SDK to Android 1.0.1
>
>
> --
> Cheers,
>        Erik Jan
> _______________________________________________
> Aerogear-users mailing list
> Aerogear-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-users
>



-- 
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/20150513/80a92c5b/attachment-0001.html 

From matzew at apache.org  Wed May 13 09:20:06 2015
From: matzew at apache.org (Matthias Wessendorf)
Date: Wed, 13 May 2015 15:20:06 +0200
Subject: [aerogear-dev] Dealing with UPS Keycloak data
	post-datasource-split
In-Reply-To: <CAAg5f2RFVEhyAzj0Bp6HNrY2DQOekhgaQcekJ6t5DOeBQ5yo+Q@mail.gmail.com>
References: <CAN-DfD5v6svHbP63QvhVHCzfKxY2Bmgy0Pq3jVYRND_jvKeN_w@mail.gmail.com>
	<CAAg5f2Trqwrg46PwY4+ZtUR9ymRvSoX3f0rYr5uxO7t2oRHpoQ@mail.gmail.com>
	<CAAg5f2T7zOkVQU8oKptCOJCb1nd8Um9jLo-5FqTHSSufgzdrkA@mail.gmail.com>
	<20150511211149.GC99477@abstractj.org>
	<CAAg5f2TRT0k7hRvMPmVYnYPfQEWE8J2Uc5aiU2SFEEft1FNXWQ@mail.gmail.com>
	<CAAg5f2TNTW=LxWphFgDCEUccXDk8Yc5cvqDg65UbF9ov5yb9Vw@mail.gmail.com>
	<CAAg5f2RFVEhyAzj0Bp6HNrY2DQOekhgaQcekJ6t5DOeBQ5yo+Q@mail.gmail.com>
Message-ID: <CAAg5f2Rx-0NKOeo1HC36K8MD-ZuG4ZpRnRVk5eypstfQpiKy_g@mail.gmail.com>

Hi,

a few questions:
- are we all still OK w/ going w/ 1.2.0 for our own 1.1.0 release?
- are we all still OK to keep KC data in a separate schema?


Now, a migration specific question: coming from UPS 1.0.3 to 1.1.0. _and_
going w/ a separate KC schema means:

* this equal to a new/fresh install of the Keycloak server
* the admin would be back to the default password
* we can remove the KC tables from our own schema

Now, before just removing the KC tables, I wonder why we can not just 'raw
copy' them to a different schema and have the KC build-in migration handle
its data?

If that's really not possible, ok. I am fine than with not having a proper
KC migration story, when coming from 1.0.3 to 1.1.0 (yes, it will be
documented)...
I also noticed  that Keycloak does not support user export/import atm.

Moving forward, the next logical steps are an even stronger isolation (yes,
we know that since a while)!

Best would be that we no longer need to distribute our own custom
auth-server.war file. A few thoughts around that are captured in [1]. But
that's something we won't be doing for 1.1.0 time frame of UPS.


[1] https://issues.jboss.org/browse/AGPUSH-1047




On Tue, May 12, 2015 at 7:33 AM, Matthias Wessendorf <matzew at apache.org>
wrote:

> I think this means:
> * go w/ KC 1.2.0
> * keep the separate KC datasource
>
> For migration: I will write some text for KC db part: e.g. do some
> export/import before getting on to UPS-1.1.0. IMO that's good enough...
>
> On Tue, May 12, 2015 at 7:24 AM, Matthias Wessendorf <matzew at apache.org>
> wrote:
>
>> From Stian on IRC
>>
>> [07:20:00] *<matzew>* *stianst* DB migration from 1.0.5.Final to KC
>> 1.2.0.CR1 is not working, like you hinted last night, right ? /cc
>> *abstractj*
>>
>> [07:20:21] *<stianst>* matzew: yep, there's no chance it'll work
>>
>>
>>
>> So, what does that mean? It means no DB migration support for KC
>> database. Perhaps that is OK,
>>
>> I can't wrap my head around this now.
>>
>>
>> But the migration for our own schema should be possible w/ the help of
>> the migration tool - let's focus on that for now
>>
>>
>>
>> On Tue, May 12, 2015 at 7:14 AM, Matthias Wessendorf <matzew at apache.org>
>> wrote:
>>
>>>
>>>
>>> On Mon, May 11, 2015 at 11:11 PM, Bruno Oliveira <bruno at abstractj.org>
>>> wrote:
>>>
>>>> Sorry if I'm late for this discussion.
>>>>
>>>> On 2015-05-07, Matthias Wessendorf wrote:
>>>> > How about the following, not optimal, proposal:
>>>> >
>>>> > * get back to one data-source
>>>>
>>>> I'm not against about it, if it's for the benefit of the project.
>>>>
>>>> > * stick w/ Keycloak-1.1.0-final (in case updating to KC-1.2.0 makes
>>>> above
>>>> > item harder)
>>>>
>>>> I don't get why master must be reverted to 1.1.0 final. I think stable
>>>> release of KC must go in 1.0.x series of UPS, but on master, we must
>>>> stick with the latest greatest release of KC. Because is the only way to
>>>> work closely with KC team.
>>>>
>>>
>>> does their DB migration from their 1.0.5.Final to 1.2.0.CR1 work?
>>> If yes -> alright, let's go w/ KC 1.2..CR - if not, well it's not the
>>> end of the world to go back :-)
>>>
>>>
>>> Or, we just do NOT support any KC db migration, just ours - that's fine
>>> w/ me...
>>>
>>>
>>>>
>>>> >
>>>> > I understand that a separation of the two is needed on the longer run
>>>> - it
>>>> > would be good if that's something on our agenda post 1.1.0 e.g. for
>>>> 1.2.0
>>>> >
>>>> > I think the above is a 'work around', which I could live with and
>>>> buys us
>>>> > time to truly think about a perfect separation.
>>>>
>>>> My 2 cents here and my humble opinion is the fact that we don't need
>>>> perfection,
>>>> only the correct. Today, split Keycloak and UPS would the most
>>>> correct thing to do. I'm not saying what we're doing here is dead
>>>> wrong, but
>>>> sooner or later the problem will hit us anyway.
>>>>
>>>> So maybe we should attack the problem now?
>>>>
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> > On Thu, May 7, 2015 at 3:26 AM, Matthias Wessendorf <
>>>> matzew at apache.org>
>>>> > wrote:
>>>> >
>>>> > >
>>>> > >
>>>> > > On Wed, May 6, 2015 at 8:27 PM, Douglas Campos <qmx at qmx.me> wrote:
>>>> > >
>>>> > >> Howdy y'all!
>>>> > >>
>>>> > >> I'm revisiting migration strategies for UPS master, and we have a
>>>> tough
>>>> > >> situation to deal with.
>>>> > >>
>>>> > >> Since we have moved keycloak to its own DataSource, there are KC
>>>> > >> leftovers at UPS database which need to be cleaned up.
>>>> > >>
>>>> > >> 1) Any suggestions on how to provide a migration path?
>>>> > >>   Since the tables are intertwined with UPS tables, it's not a
>>>> matter of
>>>> > >> doing a db dump/restore...
>>>> > >>
>>>> > >
>>>> > > how are they intertwined? Is UPS stuff stored in KC tables, or vice
>>>> versa?
>>>> > >
>>>> > >
>>>> > >> 2) How to ensure we can safely get rid of the leftover tables on
>>>> UPS
>>>> > >> DataSource?
>>>> > >>   I can easily provide migrations which just nuke the tables from
>>>> the
>>>> > >> face of the earth,
>>>> > >>
>>>> > >
>>>> > > that's good, but
>>>> > >
>>>> > >
>>>> > >> but how to do this without data loss?
>>>> > >>
>>>> > >
>>>> > > I don't know :-) I wonder if we just can not move the data to a new
>>>> > > datasource.
>>>> > >
>>>> > >
>>>> > >
>>>> > >
>>>> > >
>>>> > >>
>>>> > >> Thoughts?
>>>> > >>
>>>> > >> _______________________________________________
>>>> > >> aerogear-dev mailing list
>>>> > >> aerogear-dev at lists.jboss.org
>>>> > >> https://lists.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
>>>>
>>>>
>>>> --
>>>>
>>>> abstractj
>>>> PGP: 0x84DC9914
>>>> _______________________________________________
>>>> aerogear-dev mailing list
>>>> aerogear-dev at lists.jboss.org
>>>> https://lists.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
>>
>
>
>
> --
> 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/20150513/455fa3ab/attachment.html 

From qmx at qmx.me  Wed May 13 09:30:12 2015
From: qmx at qmx.me (Douglas Campos)
Date: Wed, 13 May 2015 10:30:12 -0300
Subject: [aerogear-dev] Dealing with UPS Keycloak data
	post-datasource-split
In-Reply-To: <CAAg5f2Rx-0NKOeo1HC36K8MD-ZuG4ZpRnRVk5eypstfQpiKy_g@mail.gmail.com>
References: <CAN-DfD5v6svHbP63QvhVHCzfKxY2Bmgy0Pq3jVYRND_jvKeN_w@mail.gmail.com>
	<CAAg5f2Trqwrg46PwY4+ZtUR9ymRvSoX3f0rYr5uxO7t2oRHpoQ@mail.gmail.com>
	<CAAg5f2T7zOkVQU8oKptCOJCb1nd8Um9jLo-5FqTHSSufgzdrkA@mail.gmail.com>
	<20150511211149.GC99477@abstractj.org>
	<CAAg5f2TRT0k7hRvMPmVYnYPfQEWE8J2Uc5aiU2SFEEft1FNXWQ@mail.gmail.com>
	<CAAg5f2TNTW=LxWphFgDCEUccXDk8Yc5cvqDg65UbF9ov5yb9Vw@mail.gmail.com>
	<CAAg5f2RFVEhyAzj0Bp6HNrY2DQOekhgaQcekJ6t5DOeBQ5yo+Q@mail.gmail.com>
	<CAAg5f2Rx-0NKOeo1HC36K8MD-ZuG4ZpRnRVk5eypstfQpiKy_g@mail.gmail.com>
Message-ID: <CAN-DfD5pogckExRq9t3GRAi=uA8CvRPo8HSHUzmFZdtqyPFUdw@mail.gmail.com>

On Wed, May 13, 2015 at 10:20 AM, Matthias Wessendorf <matzew at apache.org>
wrote:

> Hi,
>
> a few questions:
> - are we all still OK w/ going w/ 1.2.0 for our own 1.1.0 release?
> - are we all still OK to keep KC data in a separate schema?
>
yup

Now, a migration specific question: coming from UPS 1.0.3 to 1.1.0. _and_
> going w/ a separate KC schema means:
>
> * this equal to a new/fresh install of the Keycloak server
> * the admin would be back to the default password
> * we can remove the KC tables from our own schema
>
Sure, we can do it - as long as you agree with the potential data loss, I'm
fine with it.


>
> Now, before just removing the KC tables, I wonder why we can not just 'raw
> copy' them to a different schema and have the KC build-in migration handle
> its data?
>
Because this would be a PITA (dealing with raw jdbc, custom java code for
migrating it, multiplied for 2 (pgsql & mysql))


>
> If that's really not possible, ok. I am fine than with not having a proper
> KC migration story, when coming from 1.0.3 to 1.1.0 (yes, it will be
> documented)...
> I also noticed  that Keycloak does not support user export/import atm.
>
> Moving forward, the next logical steps are an even stronger isolation
> (yes, we know that since a while)!
>
Amen, brother!


> Best would be that we no longer need to distribute our own custom
> auth-server.war file. A few thoughts around that are captured in [1]. But
> that's something we won't be doing for 1.1.0 time frame of UPS.
>
>
> [1] https://issues.jboss.org/browse/AGPUSH-1047
>
>
>
>
> On Tue, May 12, 2015 at 7:33 AM, Matthias Wessendorf <matzew at apache.org>
> wrote:
>
>> I think this means:
>> * go w/ KC 1.2.0
>> * keep the separate KC datasource
>>
>> For migration: I will write some text for KC db part: e.g. do some
>> export/import before getting on to UPS-1.1.0. IMO that's good enough...
>>
>> On Tue, May 12, 2015 at 7:24 AM, Matthias Wessendorf <matzew at apache.org>
>> wrote:
>>
>>> From Stian on IRC
>>>
>>> [07:20:00] *<matzew>* *stianst* DB migration from 1.0.5.Final to KC
>>> 1.2.0.CR1 is not working, like you hinted last night, right ? /cc
>>> *abstractj*
>>>
>>> [07:20:21] *<stianst>* matzew: yep, there's no chance it'll work
>>>
>>>
>>>
>>> So, what does that mean? It means no DB migration support for KC
>>> database. Perhaps that is OK,
>>>
>>> I can't wrap my head around this now.
>>>
>>>
>>> But the migration for our own schema should be possible w/ the help of
>>> the migration tool - let's focus on that for now
>>>
>>>
>>>
>>> On Tue, May 12, 2015 at 7:14 AM, Matthias Wessendorf <matzew at apache.org>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Mon, May 11, 2015 at 11:11 PM, Bruno Oliveira <bruno at abstractj.org>
>>>> wrote:
>>>>
>>>>> Sorry if I'm late for this discussion.
>>>>>
>>>>> On 2015-05-07, Matthias Wessendorf wrote:
>>>>> > How about the following, not optimal, proposal:
>>>>> >
>>>>> > * get back to one data-source
>>>>>
>>>>> I'm not against about it, if it's for the benefit of the project.
>>>>>
>>>>> > * stick w/ Keycloak-1.1.0-final (in case updating to KC-1.2.0 makes
>>>>> above
>>>>> > item harder)
>>>>>
>>>>> I don't get why master must be reverted to 1.1.0 final. I think stable
>>>>> release of KC must go in 1.0.x series of UPS, but on master, we must
>>>>> stick with the latest greatest release of KC. Because is the only way
>>>>> to
>>>>> work closely with KC team.
>>>>>
>>>>
>>>> does their DB migration from their 1.0.5.Final to 1.2.0.CR1 work?
>>>> If yes -> alright, let's go w/ KC 1.2..CR - if not, well it's not the
>>>> end of the world to go back :-)
>>>>
>>>>
>>>> Or, we just do NOT support any KC db migration, just ours - that's fine
>>>> w/ me...
>>>>
>>>>
>>>>>
>>>>> >
>>>>> > I understand that a separation of the two is needed on the longer
>>>>> run - it
>>>>> > would be good if that's something on our agenda post 1.1.0 e.g. for
>>>>> 1.2.0
>>>>> >
>>>>> > I think the above is a 'work around', which I could live with and
>>>>> buys us
>>>>> > time to truly think about a perfect separation.
>>>>>
>>>>> My 2 cents here and my humble opinion is the fact that we don't need
>>>>> perfection,
>>>>> only the correct. Today, split Keycloak and UPS would the most
>>>>> correct thing to do. I'm not saying what we're doing here is dead
>>>>> wrong, but
>>>>> sooner or later the problem will hit us anyway.
>>>>>
>>>>> So maybe we should attack the problem now?
>>>>>
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> > On Thu, May 7, 2015 at 3:26 AM, Matthias Wessendorf <
>>>>> matzew at apache.org>
>>>>> > wrote:
>>>>> >
>>>>> > >
>>>>> > >
>>>>> > > On Wed, May 6, 2015 at 8:27 PM, Douglas Campos <qmx at qmx.me> wrote:
>>>>> > >
>>>>> > >> Howdy y'all!
>>>>> > >>
>>>>> > >> I'm revisiting migration strategies for UPS master, and we have a
>>>>> tough
>>>>> > >> situation to deal with.
>>>>> > >>
>>>>> > >> Since we have moved keycloak to its own DataSource, there are KC
>>>>> > >> leftovers at UPS database which need to be cleaned up.
>>>>> > >>
>>>>> > >> 1) Any suggestions on how to provide a migration path?
>>>>> > >>   Since the tables are intertwined with UPS tables, it's not a
>>>>> matter of
>>>>> > >> doing a db dump/restore...
>>>>> > >>
>>>>> > >
>>>>> > > how are they intertwined? Is UPS stuff stored in KC tables, or
>>>>> vice versa?
>>>>> > >
>>>>> > >
>>>>> > >> 2) How to ensure we can safely get rid of the leftover tables on
>>>>> UPS
>>>>> > >> DataSource?
>>>>> > >>   I can easily provide migrations which just nuke the tables from
>>>>> the
>>>>> > >> face of the earth,
>>>>> > >>
>>>>> > >
>>>>> > > that's good, but
>>>>> > >
>>>>> > >
>>>>> > >> but how to do this without data loss?
>>>>> > >>
>>>>> > >
>>>>> > > I don't know :-) I wonder if we just can not move the data to a new
>>>>> > > datasource.
>>>>> > >
>>>>> > >
>>>>> > >
>>>>> > >
>>>>> > >
>>>>> > >>
>>>>> > >> Thoughts?
>>>>> > >>
>>>>> > >> _______________________________________________
>>>>> > >> aerogear-dev mailing list
>>>>> > >> aerogear-dev at lists.jboss.org
>>>>> > >> https://lists.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
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> abstractj
>>>>> PGP: 0x84DC9914
>>>>> _______________________________________________
>>>>> aerogear-dev mailing list
>>>>> aerogear-dev at lists.jboss.org
>>>>> https://lists.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
>>>
>>
>>
>>
>> --
>> 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/20150513/1fe6e093/attachment-0001.html 

From matzew at apache.org  Wed May 13 09:48:31 2015
From: matzew at apache.org (Matthias Wessendorf)
Date: Wed, 13 May 2015 15:48:31 +0200
Subject: [aerogear-dev] Dealing with UPS Keycloak data
	post-datasource-split
In-Reply-To: <CAN-DfD5pogckExRq9t3GRAi=uA8CvRPo8HSHUzmFZdtqyPFUdw@mail.gmail.com>
References: <CAN-DfD5v6svHbP63QvhVHCzfKxY2Bmgy0Pq3jVYRND_jvKeN_w@mail.gmail.com>
	<CAAg5f2Trqwrg46PwY4+ZtUR9ymRvSoX3f0rYr5uxO7t2oRHpoQ@mail.gmail.com>
	<CAAg5f2T7zOkVQU8oKptCOJCb1nd8Um9jLo-5FqTHSSufgzdrkA@mail.gmail.com>
	<20150511211149.GC99477@abstractj.org>
	<CAAg5f2TRT0k7hRvMPmVYnYPfQEWE8J2Uc5aiU2SFEEft1FNXWQ@mail.gmail.com>
	<CAAg5f2TNTW=LxWphFgDCEUccXDk8Yc5cvqDg65UbF9ov5yb9Vw@mail.gmail.com>
	<CAAg5f2RFVEhyAzj0Bp6HNrY2DQOekhgaQcekJ6t5DOeBQ5yo+Q@mail.gmail.com>
	<CAAg5f2Rx-0NKOeo1HC36K8MD-ZuG4ZpRnRVk5eypstfQpiKy_g@mail.gmail.com>
	<CAN-DfD5pogckExRq9t3GRAi=uA8CvRPo8HSHUzmFZdtqyPFUdw@mail.gmail.com>
Message-ID: <CAAg5f2SaARWz6yCYWCo7-aiFVgq3LkCFgoOt8rVhgWtLCnjvrA@mail.gmail.com>

On Wed, May 13, 2015 at 3:30 PM, Douglas Campos <qmx at qmx.me> wrote:

>
>
> On Wed, May 13, 2015 at 10:20 AM, Matthias Wessendorf <matzew at apache.org>
> wrote:
>
>> Hi,
>>
>> a few questions:
>> - are we all still OK w/ going w/ 1.2.0 for our own 1.1.0 release?
>> - are we all still OK to keep KC data in a separate schema?
>>
> yup
>
> Now, a migration specific question: coming from UPS 1.0.3 to 1.1.0. _and_
>> going w/ a separate KC schema means:
>>
>> * this equal to a new/fresh install of the Keycloak server
>> * the admin would be back to the default password
>> * we can remove the KC tables from our own schema
>>
> Sure, we can do it - as long as you agree with the potential data loss,
> I'm fine with it.
>

yeah, not ideal, but... I am fine w/ it too.


>
>
>>
>> Now, before just removing the KC tables, I wonder why we can not just
>> 'raw copy' them to a different schema and have the KC build-in migration
>> handle its data?
>>
> Because this would be a PITA (dealing with raw jdbc, custom java code for
> migrating it, multiplied for 2 (pgsql & mysql))
>

ok, fair point


>
>
>>
>> If that's really not possible, ok. I am fine than with not having a
>> proper KC migration story, when coming from 1.0.3 to 1.1.0 (yes, it will be
>> documented)...
>> I also noticed  that Keycloak does not support user export/import atm.
>>
>> Moving forward, the next logical steps are an even stronger isolation
>> (yes, we know that since a while)!
>>
> Amen, brother!
>
>
>> Best would be that we no longer need to distribute our own custom
>> auth-server.war file. A few thoughts around that are captured in [1]. But
>> that's something we won't be doing for 1.1.0 time frame of UPS.
>>
>>
>> [1] https://issues.jboss.org/browse/AGPUSH-1047
>>
>>
>>
>>
>> On Tue, May 12, 2015 at 7:33 AM, Matthias Wessendorf <matzew at apache.org>
>> wrote:
>>
>>> I think this means:
>>> * go w/ KC 1.2.0
>>> * keep the separate KC datasource
>>>
>>> For migration: I will write some text for KC db part: e.g. do some
>>> export/import before getting on to UPS-1.1.0. IMO that's good enough...
>>>
>>> On Tue, May 12, 2015 at 7:24 AM, Matthias Wessendorf <matzew at apache.org>
>>> wrote:
>>>
>>>> From Stian on IRC
>>>>
>>>> [07:20:00] *<matzew>* *stianst* DB migration from 1.0.5.Final to KC
>>>> 1.2.0.CR1 is not working, like you hinted last night, right ? /cc
>>>> *abstractj*
>>>>
>>>> [07:20:21] *<stianst>* matzew: yep, there's no chance it'll work
>>>>
>>>>
>>>>
>>>> So, what does that mean? It means no DB migration support for KC
>>>> database. Perhaps that is OK,
>>>>
>>>> I can't wrap my head around this now.
>>>>
>>>>
>>>> But the migration for our own schema should be possible w/ the help of
>>>> the migration tool - let's focus on that for now
>>>>
>>>>
>>>>
>>>> On Tue, May 12, 2015 at 7:14 AM, Matthias Wessendorf <matzew at apache.org
>>>> > wrote:
>>>>
>>>>>
>>>>>
>>>>> On Mon, May 11, 2015 at 11:11 PM, Bruno Oliveira <bruno at abstractj.org>
>>>>> wrote:
>>>>>
>>>>>> Sorry if I'm late for this discussion.
>>>>>>
>>>>>> On 2015-05-07, Matthias Wessendorf wrote:
>>>>>> > How about the following, not optimal, proposal:
>>>>>> >
>>>>>> > * get back to one data-source
>>>>>>
>>>>>> I'm not against about it, if it's for the benefit of the project.
>>>>>>
>>>>>> > * stick w/ Keycloak-1.1.0-final (in case updating to KC-1.2.0 makes
>>>>>> above
>>>>>> > item harder)
>>>>>>
>>>>>> I don't get why master must be reverted to 1.1.0 final. I think stable
>>>>>> release of KC must go in 1.0.x series of UPS, but on master, we must
>>>>>> stick with the latest greatest release of KC. Because is the only way
>>>>>> to
>>>>>> work closely with KC team.
>>>>>>
>>>>>
>>>>> does their DB migration from their 1.0.5.Final to 1.2.0.CR1 work?
>>>>> If yes -> alright, let's go w/ KC 1.2..CR - if not, well it's not the
>>>>> end of the world to go back :-)
>>>>>
>>>>>
>>>>> Or, we just do NOT support any KC db migration, just ours - that's
>>>>> fine w/ me...
>>>>>
>>>>>
>>>>>>
>>>>>> >
>>>>>> > I understand that a separation of the two is needed on the longer
>>>>>> run - it
>>>>>> > would be good if that's something on our agenda post 1.1.0 e.g. for
>>>>>> 1.2.0
>>>>>> >
>>>>>> > I think the above is a 'work around', which I could live with and
>>>>>> buys us
>>>>>> > time to truly think about a perfect separation.
>>>>>>
>>>>>> My 2 cents here and my humble opinion is the fact that we don't need
>>>>>> perfection,
>>>>>> only the correct. Today, split Keycloak and UPS would the most
>>>>>> correct thing to do. I'm not saying what we're doing here is dead
>>>>>> wrong, but
>>>>>> sooner or later the problem will hit us anyway.
>>>>>>
>>>>>> So maybe we should attack the problem now?
>>>>>>
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> > On Thu, May 7, 2015 at 3:26 AM, Matthias Wessendorf <
>>>>>> matzew at apache.org>
>>>>>> > wrote:
>>>>>> >
>>>>>> > >
>>>>>> > >
>>>>>> > > On Wed, May 6, 2015 at 8:27 PM, Douglas Campos <qmx at qmx.me>
>>>>>> wrote:
>>>>>> > >
>>>>>> > >> Howdy y'all!
>>>>>> > >>
>>>>>> > >> I'm revisiting migration strategies for UPS master, and we have
>>>>>> a tough
>>>>>> > >> situation to deal with.
>>>>>> > >>
>>>>>> > >> Since we have moved keycloak to its own DataSource, there are KC
>>>>>> > >> leftovers at UPS database which need to be cleaned up.
>>>>>> > >>
>>>>>> > >> 1) Any suggestions on how to provide a migration path?
>>>>>> > >>   Since the tables are intertwined with UPS tables, it's not a
>>>>>> matter of
>>>>>> > >> doing a db dump/restore...
>>>>>> > >>
>>>>>> > >
>>>>>> > > how are they intertwined? Is UPS stuff stored in KC tables, or
>>>>>> vice versa?
>>>>>> > >
>>>>>> > >
>>>>>> > >> 2) How to ensure we can safely get rid of the leftover tables on
>>>>>> UPS
>>>>>> > >> DataSource?
>>>>>> > >>   I can easily provide migrations which just nuke the tables
>>>>>> from the
>>>>>> > >> face of the earth,
>>>>>> > >>
>>>>>> > >
>>>>>> > > that's good, but
>>>>>> > >
>>>>>> > >
>>>>>> > >> but how to do this without data loss?
>>>>>> > >>
>>>>>> > >
>>>>>> > > I don't know :-) I wonder if we just can not move the data to a
>>>>>> new
>>>>>> > > datasource.
>>>>>> > >
>>>>>> > >
>>>>>> > >
>>>>>> > >
>>>>>> > >
>>>>>> > >>
>>>>>> > >> Thoughts?
>>>>>> > >>
>>>>>> > >> _______________________________________________
>>>>>> > >> aerogear-dev mailing list
>>>>>> > >> aerogear-dev at lists.jboss.org
>>>>>> > >> https://lists.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
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>> abstractj
>>>>>> PGP: 0x84DC9914
>>>>>> _______________________________________________
>>>>>> aerogear-dev mailing list
>>>>>> aerogear-dev at lists.jboss.org
>>>>>> https://lists.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
>>>>
>>>
>>>
>>>
>>> --
>>> 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/20150513/d68f78b3/attachment.html 

From bruno at abstractj.org  Wed May 13 15:17:56 2015
From: bruno at abstractj.org (Bruno Oliveira)
Date: Wed, 13 May 2015 16:17:56 -0300
Subject: [aerogear-dev] Dealing with UPS Keycloak data
 post-datasource-split
In-Reply-To: <CAAg5f2TNTW=LxWphFgDCEUccXDk8Yc5cvqDg65UbF9ov5yb9Vw@mail.gmail.com>
References: <CAN-DfD5v6svHbP63QvhVHCzfKxY2Bmgy0Pq3jVYRND_jvKeN_w@mail.gmail.com>
	<CAAg5f2Trqwrg46PwY4+ZtUR9ymRvSoX3f0rYr5uxO7t2oRHpoQ@mail.gmail.com>
	<CAAg5f2T7zOkVQU8oKptCOJCb1nd8Um9jLo-5FqTHSSufgzdrkA@mail.gmail.com>
	<20150511211149.GC99477@abstractj.org>
	<CAAg5f2TRT0k7hRvMPmVYnYPfQEWE8J2Uc5aiU2SFEEft1FNXWQ@mail.gmail.com>
	<CAAg5f2TNTW=LxWphFgDCEUccXDk8Yc5cvqDg65UbF9ov5yb9Vw@mail.gmail.com>
Message-ID: <20150513191756.GA2329@abstractj.org>

On 2015-05-12, Matthias Wessendorf wrote:
> >From Stian on IRC
>
> [07:20:00] *<matzew>* *stianst* DB migration from 1.0.5.Final to KC
> 1.2.0.CR1 is not working, like you hinted last night, right ? /cc
> *abstractj*
>
> [07:20:21] *<stianst>* matzew: yep, there's no chance it'll work
>
>
>
> So, what does that mean? It means no DB migration support for KC database.
> Perhaps that is OK,
>
> I can't wrap my head around this now.
>
>
> But the migration for our own schema should be possible w/ the help of the
> migration tool - let's focus on that for now

+1 Thanks for the heads up

>
>
>
> On Tue, May 12, 2015 at 7:14 AM, Matthias Wessendorf <matzew at apache.org>
> wrote:
>
> >
> >
> > On Mon, May 11, 2015 at 11:11 PM, Bruno Oliveira <bruno at abstractj.org>
> > wrote:
> >
> >> Sorry if I'm late for this discussion.
> >>
> >> On 2015-05-07, Matthias Wessendorf wrote:
> >> > How about the following, not optimal, proposal:
> >> >
> >> > * get back to one data-source
> >>
> >> I'm not against about it, if it's for the benefit of the project.
> >>
> >> > * stick w/ Keycloak-1.1.0-final (in case updating to KC-1.2.0 makes
> >> above
> >> > item harder)
> >>
> >> I don't get why master must be reverted to 1.1.0 final. I think stable
> >> release of KC must go in 1.0.x series of UPS, but on master, we must
> >> stick with the latest greatest release of KC. Because is the only way to
> >> work closely with KC team.
> >>
> >
> > does their DB migration from their 1.0.5.Final to 1.2.0.CR1 work?
> > If yes -> alright, let's go w/ KC 1.2..CR - if not, well it's not the end
> > of the world to go back :-)
> >
> >
> > Or, we just do NOT support any KC db migration, just ours - that's fine w/
> > me...
> >
> >
> >>
> >> >
> >> > I understand that a separation of the two is needed on the longer run -
> >> it
> >> > would be good if that's something on our agenda post 1.1.0 e.g. for
> >> 1.2.0
> >> >
> >> > I think the above is a 'work around', which I could live with and buys
> >> us
> >> > time to truly think about a perfect separation.
> >>
> >> My 2 cents here and my humble opinion is the fact that we don't need
> >> perfection,
> >> only the correct. Today, split Keycloak and UPS would the most
> >> correct thing to do. I'm not saying what we're doing here is dead wrong,
> >> but
> >> sooner or later the problem will hit us anyway.
> >>
> >> So maybe we should attack the problem now?
> >>
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > On Thu, May 7, 2015 at 3:26 AM, Matthias Wessendorf <matzew at apache.org>
> >> > wrote:
> >> >
> >> > >
> >> > >
> >> > > On Wed, May 6, 2015 at 8:27 PM, Douglas Campos <qmx at qmx.me> wrote:
> >> > >
> >> > >> Howdy y'all!
> >> > >>
> >> > >> I'm revisiting migration strategies for UPS master, and we have a
> >> tough
> >> > >> situation to deal with.
> >> > >>
> >> > >> Since we have moved keycloak to its own DataSource, there are KC
> >> > >> leftovers at UPS database which need to be cleaned up.
> >> > >>
> >> > >> 1) Any suggestions on how to provide a migration path?
> >> > >>   Since the tables are intertwined with UPS tables, it's not a
> >> matter of
> >> > >> doing a db dump/restore...
> >> > >>
> >> > >
> >> > > how are they intertwined? Is UPS stuff stored in KC tables, or vice
> >> versa?
> >> > >
> >> > >
> >> > >> 2) How to ensure we can safely get rid of the leftover tables on UPS
> >> > >> DataSource?
> >> > >>   I can easily provide migrations which just nuke the tables from the
> >> > >> face of the earth,
> >> > >>
> >> > >
> >> > > that's good, but
> >> > >
> >> > >
> >> > >> but how to do this without data loss?
> >> > >>
> >> > >
> >> > > I don't know :-) I wonder if we just can not move the data to a new
> >> > > datasource.
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >>
> >> > >> Thoughts?
> >> > >>
> >> > >> _______________________________________________
> >> > >> aerogear-dev mailing list
> >> > >> aerogear-dev at lists.jboss.org
> >> > >> https://lists.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
> >>
> >>
> >> --
> >>
> >> abstractj
> >> PGP: 0x84DC9914
> >> _______________________________________________
> >> aerogear-dev mailing list
> >> aerogear-dev at lists.jboss.org
> >> https://lists.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


--

abstractj
PGP: 0x84DC9914

From bruno at abstractj.org  Wed May 13 15:22:24 2015
From: bruno at abstractj.org (Bruno Oliveira)
Date: Wed, 13 May 2015 16:22:24 -0300
Subject: [aerogear-dev] Metrics Endpoint (was: Re: Advanced Analtyics,
 new PR and call to the client tech leads)
In-Reply-To: <CAAg5f2QXzPGMZRtzH3XMhbYjaPqrKinuqci3-rMFGmqSHT1n-A@mail.gmail.com>
References: <CADF=h2vfetc39f7xJyygHE5uj531tUc3xtzZu9=NePLD7DBtNg@mail.gmail.com>
	<CAAg5f2QqLCmJjQAr9nJN-aG_4z-yp1p=G292aYEfUFTq=_CnRw@mail.gmail.com>
	<CADF=h2s+VH-UtHkiEA68MKhD=K0HjNzV+6iS1R88Q4nU9-=qew@mail.gmail.com>
	<CAO2B-fZ9d7P8gervDCGXnX703ZJ1a=UciwH1mMrg5rt75KzXxQ@mail.gmail.com>
	<CADF=h2scyWsrpARbkCesQ=HVJWJXHJkka3v9kr-DRcvFdprTxg@mail.gmail.com>
	<CAAg5f2ToKhNvJomxTN2PNqarN+JA_FRr4V_3GB+DutGmE8CZqw@mail.gmail.com>
	<CAL8vO=cvkk-fZAmvuSkf+jKaY3j5MLmqSWSPbdpbqcop9BPOhA@mail.gmail.com>
	<CAD_dpu2TXgzgcSomqVNSM-RAboir0_E+MdmwBXguLb9jSXroDA@mail.gmail.com>
	<20150511205626.GB99477@abstractj.org>
	<CAAg5f2QXzPGMZRtzH3XMhbYjaPqrKinuqci3-rMFGmqSHT1n-A@mail.gmail.com>
Message-ID: <20150513192224.GB2329@abstractj.org>

On 2015-05-12, Matthias Wessendorf wrote:
> On Mon, May 11, 2015 at 10:56 PM, Bruno Oliveira <bruno at abstractj.org>
> wrote:
>
> > On 2015-05-11, Sebastien Blanc wrote:
> > > Let's start with the "semi-automatic" approach ;)
> >
> > I think by "semi-automatic" you mean "it's up to the developer", right?
> > If yes, +1.
> >
> > Another question is: Is another HTTP request required only
> > to feed metrics? I'm thinking about people with very limited data plans.
> > If yes, that's definitely must be optional.
> >
> > Also, do we have documented in some place what we are collecting?
> > >From our guide I have:
> >
> > "For analytic purposes on our Dashboard we store the content of the
> > alert key sent to the UnifiedPush Server. The content of the alert key
> > belongs to the metadata, which is deleted after 30 days, using a nightly
> > job within the UnifiedPush Server."
> >
>
> the collecting of pay, which you quoted is documented, yes (it is true for
> 1.0.3 already)
>
> That we collect the open is NOT yet documented. It is part of 1.1.0.Fianl
> doc, of the new UI.
> I will update the "warning" section on the begining as well, not just
> mention the new stats on the UI parts.
>
> makes sense ?

Sure thing.

>
>
>
> >
> > If we reach an agreement on it, test the endpoint against DDoS might be
> > required.
> >
> > > @passos : maybe you can use the same method's name to keep it unified ?
> > (we
> > > can always change the names later)
> > >
> > >
> > > On Mon, May 11, 2015 at 3:48 PM, Corinne Krych <corinnekrych at gmail.com>
> > > wrote:
> > >
> > > > Yeap all is in "semi".
> > > > for iOs we'll have 2 public static methods:
> > > >
> > > > AGPushAnalytics.sendMetricWhenAppLaunched(serverURL: NSURL,
> > > > launchOptions: [NSObject:AnyObject]?)
> > > > AGPushAnalytics.sendMetricsWhenAppAwoken(serverURL: NSURL,
> > > > applicationState: UIApplicationState, userInfo: [NSObject:AnyObject])
> > > >
> > > > If we want all automation we have to provide more wrapping around
> > native
> > > > life cycle, which can be quite intrusive.
> > > >
> > > > ++
> > > > Corinne
> > > >
> > > > On 11 May 2015 at 15:44, Matthias Wessendorf <matzew at apache.org>
> > wrote:
> > > >
> > > >> iOS is also semi automatic ;-)
> > > >>
> > > >> On Mon, May 11, 2015 at 3:41 PM, Daniel Passos <dpassos at redhat.com>
> > > >> wrote:
> > > >>
> > > >>> Of course. My point was just to be clear we can't do it "automatic"
> > :)
> > > >>>
> > > >>> On Mon, May 11, 2015 at 10:39 AM, Erik Jan de Wit <edewit at redhat.com
> > >
> > > >>> wrote:
> > > >>>
> > > >>>> but the android sdk could have a method for uploading the metrics,
> > so
> > > >>>> that a developer can opt for having that displayed on the dashboard.
> > > >>>>
> > > >>>> This method can then also be used for cordova ;)
> > > >>>>
> > > >>>> On Mon, May 11, 2015 at 3:30 PM, Daniel Passos <dpassos at redhat.com>
> > > >>>> wrote:
> > > >>>> > On Fri, May 8, 2015 at 2:10 AM, Matthias Wessendorf <
> > > >>>> matzew at apache.org>
> > > >>>> > wrote:
> > > >>>> >>
> > > >>>> >>
> > > >>>> >>
> > > >>>> >> On Thu, May 7, 2015 at 11:58 PM, Daniel Passos <
> > dpassos at redhat.com>
> > > >>>> wrote:
> > > >>>> >>>
> > > >>>> >>> Just to be clear, we are talking about metrics for messages
> > > >>>> delivered
> > > >>>> >>> (received on device) or about really read/open?
> > > >>>> >>>
> > > >>>> >>> Because in Android land is not possible know when message was
> > > >>>> >>> read/opened. We delegate how the message will be
> > delivered/showed
> > > >>>> to the
> > > >>>> >>> MessageHandler[1] and we don't have access to it.
> > > >>>> >>
> > > >>>> >>
> > > >>>> >> when the user clicks on the message, the app opens. That's what
> > we
> > > >>>> track
> > > >>>> >> w/ this PR, not the actual: I read the message - more "App was
> > > >>>> opened due to
> > > >>>> >> push", see:
> > > >>>> >> https://issues.jboss.org/browse/AGPUSH-971
> > > >>>> >
> > > >>>> >
> > > >>>> > I can't do that. I can't do an action when app was opened. To do
> > that
> > > >>>> we
> > > >>>> > would need to create our own application[1] class, and all
> > projects
> > > >>>> would
> > > >>>> > need to extend it. As I have told in my previous email, for now I
> > > >>>> only can
> > > >>>> > do something when the message is delivered to the device.
> > > >>>> >
> > > >>>> > [1]
> > > >>>> http://developer.android.com/reference/android/app/Application.html
> > > >>>> >
> > > >>>> >>
> > > >>>> >>>
> > > >>>> >>>
> > > >>>> >>> Today we only have access when the message is delivered.
> > Basically
> > > >>>> we
> > > >>>> >>> receive the message in a AeroGearGCMMessageReceiver[2] do some
> > > >>>> checks and
> > > >>>> >>> push the message for all Handles registered[3][4]
> > > >>>> >>>
> > > >>>> >>> [1]
> > > >>>> >>>
> > > >>>>
> > https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/MessageHandler.java
> > > >>>> >>> [2]
> > > >>>> >>>
> > > >>>>
> > https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/gcm/AeroGearGCMMessageReceiver.java
> > > >>>> >>> [3]
> > > >>>> >>>
> > > >>>>
> > https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/RegistrarManager.java#L118
> > > >>>> >>> [4]
> > > >>>> >>>
> > > >>>>
> > https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/RegistrarManager.java#L130
> > > >>>> >>>
> > > >>>> >>> -- Passos
> > > >>>> >>>
> > > >>>> >>>
> > > >>>> >>> On Wed, May 6, 2015 at 6:38 AM, Matthias Wessendorf <
> > > >>>> matzew at apache.org>
> > > >>>> >>> wrote:
> > > >>>> >>>>
> > > >>>> >>>> Hi,
> > > >>>> >>>>
> > > >>>> >>>> as discussed on the previous thread, there will be a new
> > endpoint
> > > >>>> to
> > > >>>> >>>> 'track' the "App opened/launched due to received push
> > > >>>> notification".
> > > >>>> >>>>
> > > >>>> >>>> Internally, on the UPS, the Push Message has an ID, which get's
> > > >>>> append
> > > >>>> >>>> to the payload of the notification, like here:
> > > >>>> >>>>
> > > >>>> >>>>
> > > >>>>
> > https://github.com/matzew/aerogear-unifiedpush-server/blob/analytics/push/sender/src/main/java/org/jboss/aerogear/unifiedpush/message/sender/APNsPushNotificationSender.java#L107-L108
> > > >>>> >>>>
> > > >>>> >>>> On the client SDKs this will be read and a HTTP call made to
> > the
> > > >>>> soon
> > > >>>> >>>> introduced MetricsEndpoint. Currently this info is send to the
> > > >>>> >>>> RegistrationEndpoint, including the deviceToken/registrationId.
> > > >>>> However, I
> > > >>>> >>>> think that the deviceToken/registrationId is currently not
> > needed
> > > >>>> for
> > > >>>> >>>> metrics, since we are just interested in anonymous "app
> > > >>>> launched/opened due
> > > >>>> >>>> to push", and not a specific "DEVICE X did open, while DEVICE Y
> > > >>>> did not yet
> > > >>>> >>>> open".
> > > >>>> >>>>
> > > >>>> >>>> So all we really need is the ID of the push notification, to be
> > > >>>> >>>> processed by our Metrics Service
> > > >>>> >>>>
> > > >>>> >>>>
> > > >>>>
> > https://github.com/matzew/aerogear-unifiedpush-server/blob/analytics/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/registry/installations/InstallationRegistrationEndpoint.java#L128-L133
> > > >>>> >>>>
> > > >>>> >>>> Therefore my proposal is have an endpoint:
> > > >>>> >>>>
> > > >>>> >>>> PUT /metrics/pushmessage/{pushMessageID}
> > > >>>> >>>>
> > > >>>> >>>> I think PUT is good/best, because there is nothing really
> > created
> > > >>>> on the
> > > >>>> >>>> server, it's more updating the 'counter' on the existing
> > > >>>> >>>> PushMessageInformation object.
> > > >>>> >>>>
> > > >>>> >>>> Thoughts?
> > > >>>> >>>> -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
> > > >>>> >
> > > >>>> >
> > > >>>> >
> > > >>>> >
> > > >>>> > --
> > > >>>> > -- Passos
> > > >>>> >
> > > >>>> > _______________________________________________
> > > >>>> > aerogear-dev mailing list
> > > >>>> > aerogear-dev at lists.jboss.org
> > > >>>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>> --
> > > >>>> Cheers,
> > > >>>>        Erik Jan
> > > >>>> _______________________________________________
> > > >>>> aerogear-dev mailing list
> > > >>>> aerogear-dev at lists.jboss.org
> > > >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > >>>>
> > > >>>
> > > >>>
> > > >>>
> > > >>> --
> > > >>> -- Passos
> > > >>>
> > > >>> _______________________________________________
> > > >>> aerogear-dev mailing list
> > > >>> aerogear-dev at lists.jboss.org
> > > >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > >>>
> > > >>
> > > >>
> > > >>
> > > >> --
> > > >> Matthias Wessendorf
> > > >>
> > > >> blog: http://matthiaswessendorf.wordpress.com/
> > > >> sessions: http://www.slideshare.net/mwessendorf
> > > >> twitter: http://twitter.com/mwessendorf
> > > >>
> > > >> _______________________________________________
> > > >> aerogear-dev mailing list
> > > >> aerogear-dev at lists.jboss.org
> > > >> https://lists.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
> >
> >
> > --
> >
> > abstractj
> > PGP: 0x84DC9914
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf

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


--

abstractj
PGP: 0x84DC9914

From bruno at abstractj.org  Wed May 13 15:24:06 2015
From: bruno at abstractj.org (Bruno Oliveira)
Date: Wed, 13 May 2015 16:24:06 -0300
Subject: [aerogear-dev] Metrics Endpoint (was: Re: Advanced Analtyics,
 new PR and call to the client tech leads)
In-Reply-To: <CAD_dpu1qj4UaCSJ+dkv8Fjh9Vzj+f5JDLs3ztxAPbBaMVyi2vw@mail.gmail.com>
References: <CADF=h2vfetc39f7xJyygHE5uj531tUc3xtzZu9=NePLD7DBtNg@mail.gmail.com>
	<CAAg5f2QqLCmJjQAr9nJN-aG_4z-yp1p=G292aYEfUFTq=_CnRw@mail.gmail.com>
	<CADF=h2s+VH-UtHkiEA68MKhD=K0HjNzV+6iS1R88Q4nU9-=qew@mail.gmail.com>
	<CAO2B-fZ9d7P8gervDCGXnX703ZJ1a=UciwH1mMrg5rt75KzXxQ@mail.gmail.com>
	<CADF=h2scyWsrpARbkCesQ=HVJWJXHJkka3v9kr-DRcvFdprTxg@mail.gmail.com>
	<CAAg5f2ToKhNvJomxTN2PNqarN+JA_FRr4V_3GB+DutGmE8CZqw@mail.gmail.com>
	<CAL8vO=cvkk-fZAmvuSkf+jKaY3j5MLmqSWSPbdpbqcop9BPOhA@mail.gmail.com>
	<CAD_dpu2TXgzgcSomqVNSM-RAboir0_E+MdmwBXguLb9jSXroDA@mail.gmail.com>
	<20150511205626.GB99477@abstractj.org>
	<CAD_dpu1qj4UaCSJ+dkv8Fjh9Vzj+f5JDLs3ztxAPbBaMVyi2vw@mail.gmail.com>
Message-ID: <20150513192406.GC2329@abstractj.org>

Thanks for the clarification, that helps.

On 2015-05-11, Sebastien Blanc wrote:
> On Mon, May 11, 2015 at 10:56 PM, Bruno Oliveira <bruno at abstractj.org>
> wrote:
>
> > On 2015-05-11, Sebastien Blanc wrote:
> > > Let's start with the "semi-automatic" approach ;)
> >
> > I think by "semi-automatic" you mean "it's up to the developer", right?
> >
> right :)
>
> > If yes, +1.
> >
> > Another question is: Is another HTTP request required only
> > to feed metrics? I'm thinking about people with very limited data plans.
> > If yes, that's definitely must be optional.
> >
> Yes since we have to collect when a specific action occurs (open an app or
> bring to foreground) the only way is do a http request
>
> >
> > Also, do we have documented in some place what we are collecting?
> >
> We are not collecting anything with this advanced metrics, we are just
> "counting" anonymously.
>
> > >From our guide I have:
> >
> > "For analytic purposes on our Dashboard we store the content of the
> > alert key sent to the UnifiedPush Server. The content of the alert key
> > belongs to the metadata, which is deleted after 30 days, using a nightly
> > job within the UnifiedPush Server."
> >
> > If we reach an agreement on it, test the endpoint against DDoS might be
> > required.
> >
> Agreed.
> we should even test DDoS against all our "open" endpoints (registration,
> import, sender)
>
> >
> > > @passos : maybe you can use the same method's name to keep it unified ?
> > (we
> > > can always change the names later)
> > >
> > >
> > > On Mon, May 11, 2015 at 3:48 PM, Corinne Krych <corinnekrych at gmail.com>
> > > wrote:
> > >
> > > > Yeap all is in "semi".
> > > > for iOs we'll have 2 public static methods:
> > > >
> > > > AGPushAnalytics.sendMetricWhenAppLaunched(serverURL: NSURL,
> > > > launchOptions: [NSObject:AnyObject]?)
> > > > AGPushAnalytics.sendMetricsWhenAppAwoken(serverURL: NSURL,
> > > > applicationState: UIApplicationState, userInfo: [NSObject:AnyObject])
> > > >
> > > > If we want all automation we have to provide more wrapping around
> > native
> > > > life cycle, which can be quite intrusive.
> > > >
> > > > ++
> > > > Corinne
> > > >
> > > > On 11 May 2015 at 15:44, Matthias Wessendorf <matzew at apache.org>
> > wrote:
> > > >
> > > >> iOS is also semi automatic ;-)
> > > >>
> > > >> On Mon, May 11, 2015 at 3:41 PM, Daniel Passos <dpassos at redhat.com>
> > > >> wrote:
> > > >>
> > > >>> Of course. My point was just to be clear we can't do it "automatic"
> > :)
> > > >>>
> > > >>> On Mon, May 11, 2015 at 10:39 AM, Erik Jan de Wit <edewit at redhat.com
> > >
> > > >>> wrote:
> > > >>>
> > > >>>> but the android sdk could have a method for uploading the metrics,
> > so
> > > >>>> that a developer can opt for having that displayed on the dashboard.
> > > >>>>
> > > >>>> This method can then also be used for cordova ;)
> > > >>>>
> > > >>>> On Mon, May 11, 2015 at 3:30 PM, Daniel Passos <dpassos at redhat.com>
> > > >>>> wrote:
> > > >>>> > On Fri, May 8, 2015 at 2:10 AM, Matthias Wessendorf <
> > > >>>> matzew at apache.org>
> > > >>>> > wrote:
> > > >>>> >>
> > > >>>> >>
> > > >>>> >>
> > > >>>> >> On Thu, May 7, 2015 at 11:58 PM, Daniel Passos <
> > dpassos at redhat.com>
> > > >>>> wrote:
> > > >>>> >>>
> > > >>>> >>> Just to be clear, we are talking about metrics for messages
> > > >>>> delivered
> > > >>>> >>> (received on device) or about really read/open?
> > > >>>> >>>
> > > >>>> >>> Because in Android land is not possible know when message was
> > > >>>> >>> read/opened. We delegate how the message will be
> > delivered/showed
> > > >>>> to the
> > > >>>> >>> MessageHandler[1] and we don't have access to it.
> > > >>>> >>
> > > >>>> >>
> > > >>>> >> when the user clicks on the message, the app opens. That's what
> > we
> > > >>>> track
> > > >>>> >> w/ this PR, not the actual: I read the message - more "App was
> > > >>>> opened due to
> > > >>>> >> push", see:
> > > >>>> >> https://issues.jboss.org/browse/AGPUSH-971
> > > >>>> >
> > > >>>> >
> > > >>>> > I can't do that. I can't do an action when app was opened. To do
> > that
> > > >>>> we
> > > >>>> > would need to create our own application[1] class, and all
> > projects
> > > >>>> would
> > > >>>> > need to extend it. As I have told in my previous email, for now I
> > > >>>> only can
> > > >>>> > do something when the message is delivered to the device.
> > > >>>> >
> > > >>>> > [1]
> > > >>>> http://developer.android.com/reference/android/app/Application.html
> > > >>>> >
> > > >>>> >>
> > > >>>> >>>
> > > >>>> >>>
> > > >>>> >>> Today we only have access when the message is delivered.
> > Basically
> > > >>>> we
> > > >>>> >>> receive the message in a AeroGearGCMMessageReceiver[2] do some
> > > >>>> checks and
> > > >>>> >>> push the message for all Handles registered[3][4]
> > > >>>> >>>
> > > >>>> >>> [1]
> > > >>>> >>>
> > > >>>>
> > https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/MessageHandler.java
> > > >>>> >>> [2]
> > > >>>> >>>
> > > >>>>
> > https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/gcm/AeroGearGCMMessageReceiver.java
> > > >>>> >>> [3]
> > > >>>> >>>
> > > >>>>
> > https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/RegistrarManager.java#L118
> > > >>>> >>> [4]
> > > >>>> >>>
> > > >>>>
> > https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/RegistrarManager.java#L130
> > > >>>> >>>
> > > >>>> >>> -- Passos
> > > >>>> >>>
> > > >>>> >>>
> > > >>>> >>> On Wed, May 6, 2015 at 6:38 AM, Matthias Wessendorf <
> > > >>>> matzew at apache.org>
> > > >>>> >>> wrote:
> > > >>>> >>>>
> > > >>>> >>>> Hi,
> > > >>>> >>>>
> > > >>>> >>>> as discussed on the previous thread, there will be a new
> > endpoint
> > > >>>> to
> > > >>>> >>>> 'track' the "App opened/launched due to received push
> > > >>>> notification".
> > > >>>> >>>>
> > > >>>> >>>> Internally, on the UPS, the Push Message has an ID, which get's
> > > >>>> append
> > > >>>> >>>> to the payload of the notification, like here:
> > > >>>> >>>>
> > > >>>> >>>>
> > > >>>>
> > https://github.com/matzew/aerogear-unifiedpush-server/blob/analytics/push/sender/src/main/java/org/jboss/aerogear/unifiedpush/message/sender/APNsPushNotificationSender.java#L107-L108
> > > >>>> >>>>
> > > >>>> >>>> On the client SDKs this will be read and a HTTP call made to
> > the
> > > >>>> soon
> > > >>>> >>>> introduced MetricsEndpoint. Currently this info is send to the
> > > >>>> >>>> RegistrationEndpoint, including the deviceToken/registrationId.
> > > >>>> However, I
> > > >>>> >>>> think that the deviceToken/registrationId is currently not
> > needed
> > > >>>> for
> > > >>>> >>>> metrics, since we are just interested in anonymous "app
> > > >>>> launched/opened due
> > > >>>> >>>> to push", and not a specific "DEVICE X did open, while DEVICE Y
> > > >>>> did not yet
> > > >>>> >>>> open".
> > > >>>> >>>>
> > > >>>> >>>> So all we really need is the ID of the push notification, to be
> > > >>>> >>>> processed by our Metrics Service
> > > >>>> >>>>
> > > >>>> >>>>
> > > >>>>
> > https://github.com/matzew/aerogear-unifiedpush-server/blob/analytics/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/registry/installations/InstallationRegistrationEndpoint.java#L128-L133
> > > >>>> >>>>
> > > >>>> >>>> Therefore my proposal is have an endpoint:
> > > >>>> >>>>
> > > >>>> >>>> PUT /metrics/pushmessage/{pushMessageID}
> > > >>>> >>>>
> > > >>>> >>>> I think PUT is good/best, because there is nothing really
> > created
> > > >>>> on the
> > > >>>> >>>> server, it's more updating the 'counter' on the existing
> > > >>>> >>>> PushMessageInformation object.
> > > >>>> >>>>
> > > >>>> >>>> Thoughts?
> > > >>>> >>>> -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
> > > >>>> >
> > > >>>> >
> > > >>>> >
> > > >>>> >
> > > >>>> > --
> > > >>>> > -- Passos
> > > >>>> >
> > > >>>> > _______________________________________________
> > > >>>> > aerogear-dev mailing list
> > > >>>> > aerogear-dev at lists.jboss.org
> > > >>>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>> --
> > > >>>> Cheers,
> > > >>>>        Erik Jan
> > > >>>> _______________________________________________
> > > >>>> aerogear-dev mailing list
> > > >>>> aerogear-dev at lists.jboss.org
> > > >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > >>>>
> > > >>>
> > > >>>
> > > >>>
> > > >>> --
> > > >>> -- Passos
> > > >>>
> > > >>> _______________________________________________
> > > >>> aerogear-dev mailing list
> > > >>> aerogear-dev at lists.jboss.org
> > > >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > >>>
> > > >>
> > > >>
> > > >>
> > > >> --
> > > >> Matthias Wessendorf
> > > >>
> > > >> blog: http://matthiaswessendorf.wordpress.com/
> > > >> sessions: http://www.slideshare.net/mwessendorf
> > > >> twitter: http://twitter.com/mwessendorf
> > > >>
> > > >> _______________________________________________
> > > >> aerogear-dev mailing list
> > > >> aerogear-dev at lists.jboss.org
> > > >> https://lists.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
> >
> >
> > --
> >
> > abstractj
> > PGP: 0x84DC9914
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >

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


--

abstractj
PGP: 0x84DC9914

From matzew at apache.org  Wed May 13 16:53:02 2015
From: matzew at apache.org (Matthias Wessendorf)
Date: Wed, 13 May 2015 22:53:02 +0200
Subject: [aerogear-dev] Fwd: New Push Server Deployed: Autopush 1.0
In-Reply-To: <5553B2DD.5070407@mozilla.com>
References: <5553B2DD.5070407@mozilla.com>
Message-ID: <CAAg5f2TRSUjwXKFRWsDiCjRH7g_SZtz7Ogg_hyh8_3AOjB2NXw@mail.gmail.com>

interesting to see a rewrite from go to twisted python

---------- Forwarded message ----------
From: *JR Conlin* <jconlin at mozilla.com>
Date: Wednesday, May 13, 2015
Subject: New Push Server Deployed: Autopush 1.0
To: dev-push at lists.mozilla.org


Yesterday, a new version of the Push Server has been promoted to production.

This version is a total rewrite of the go version into Python Twisted
framework.
The code is available at:

https://github.com/mozilla-services/autopush

There were many reasons for the code rewrite, however the principal was
better memory handling for TLS connections. The new server is able to be
run on a smaller, more afforable AWS instance as well as be able to handle
a larger number of connections.

Operation has passed QA and we expect no impact to existing services. We
have identified several client based issues and are working to address
them. As always, we're available in the irc.mozilla.org #push channel or
via this email list.


_______________________________________________
dev-push mailing list
dev-push at lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-push



-- 
Sent from Gmail Mobile
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20150513/56f9dfad/attachment-0001.html 

From qmx at qmx.me  Wed May 13 19:11:10 2015
From: qmx at qmx.me (Douglas Campos)
Date: Wed, 13 May 2015 20:11:10 -0300
Subject: [aerogear-dev] UPS Migrations for Master, Sequences and Friends
Message-ID: <CAN-DfD6=kDb8V8WXk_=XHtXvFEv7vCO9h0XHcraH=s7mJzjhNQ@mail.gmail.com>

Howdy!

While working on rebasing the migration PR I've noticed that Lukas moved my
'category_seq' generator to the shiny-new 'enhanced-sequence' generator.

Does anyone remembers the reasoning for the change? I'm asking because we
do want a sequence-style generator BUT with individual sequence-like tables
when using mysql. The reason for this is SEVERE contention with InnoDB
tables under load - something that is prone to happen when you go with the
`hibernate_sequence` magic table.

I might be missing something.....HALP? :)

[]'z
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20150513/f011c6ef/attachment.html 

From matzew at apache.org  Thu May 14 08:02:57 2015
From: matzew at apache.org (Matthias Wessendorf)
Date: Thu, 14 May 2015 14:02:57 +0200
Subject: [aerogear-dev] jboss parent pom update?
Message-ID: <CAAg5f2TLhghJHivpbq=3+kMr_NW+yRduKXTQy=SRvzTUC7yc2g@mail.gmail.com>

Hi,

our aerogear-parent uses an older jbosss-parent #11. This version uses some
older libraries/plugins. For instance the checkstyle version in there is
not understanding java8.

We have done some work arounds, like:
https://github.com/aerogear/aerogear-webpush-server/blob/master/pom.xml#L275

Why not going to a newer jboss parent instead, e.g. 17 ?
Sure - this needs some tests :-) but I was wondering if there is a general
concern

-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/20150514/d6d2b796/attachment.html 

From bruno at abstractj.org  Thu May 14 10:51:01 2015
From: bruno at abstractj.org (Bruno Oliveira)
Date: Thu, 14 May 2015 11:51:01 -0300
Subject: [aerogear-dev] jboss parent pom update?
In-Reply-To: <CAAg5f2TLhghJHivpbq=3+kMr_NW+yRduKXTQy=SRvzTUC7yc2g@mail.gmail.com>
References: <CAAg5f2TLhghJHivpbq=3+kMr_NW+yRduKXTQy=SRvzTUC7yc2g@mail.gmail.com>
Message-ID: <20150514145100.GA19910@abstractj.org>

At the moment 0 concerns, so +1

Yes, for doing tests before the change.

On 2015-05-14, Matthias Wessendorf wrote:
> Hi,
>
> our aerogear-parent uses an older jbosss-parent #11. This version uses some
> older libraries/plugins. For instance the checkstyle version in there is
> not understanding java8.
>
> We have done some work arounds, like:
> https://github.com/aerogear/aerogear-webpush-server/blob/master/pom.xml#L275
>
> Why not going to a newer jboss parent instead, e.g. 17 ?
> Sure - this needs some tests :-) but I was wondering if there is a general
> concern
>
> -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


--

abstractj
PGP: 0x84DC9914

From dpassos at redhat.com  Thu May 14 11:07:49 2015
From: dpassos at redhat.com (Daniel Passos)
Date: Thu, 14 May 2015 12:07:49 -0300
Subject: [aerogear-dev] jboss parent pom update?
In-Reply-To: <CAAg5f2TLhghJHivpbq=3+kMr_NW+yRduKXTQy=SRvzTUC7yc2g@mail.gmail.com>
References: <CAAg5f2TLhghJHivpbq=3+kMr_NW+yRduKXTQy=SRvzTUC7yc2g@mail.gmail.com>
Message-ID: <CADF=h2snnyEKVfDYmDKXZSzwpsXZ-o8Q9s-eea9KqnnW--4hkQ@mail.gmail.com>

Why not? Let's do some test with it.

+1

On Thu, May 14, 2015 at 9:02 AM, Matthias Wessendorf <matzew at apache.org>
wrote:

> Hi,
>
> our aerogear-parent uses an older jbosss-parent #11. This version uses
> some older libraries/plugins. For instance the checkstyle version in there
> is not understanding java8.
>
> We have done some work arounds, like:
>
> https://github.com/aerogear/aerogear-webpush-server/blob/master/pom.xml#L275
>
> Why not going to a newer jboss parent instead, e.g. 17 ?
> Sure - this needs some tests :-) but I was wondering if there is a general
> concern
>
> -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
>



-- 
-- Passos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20150514/ac668eb5/attachment.html 

From matzew at apache.org  Fri May 15 03:07:07 2015
From: matzew at apache.org (Matthias Wessendorf)
Date: Fri, 15 May 2015 09:07:07 +0200
Subject: [aerogear-dev] UPS Migrations for Master, Sequences and Friends
In-Reply-To: <CAN-DfD6=kDb8V8WXk_=XHtXvFEv7vCO9h0XHcraH=s7mJzjhNQ@mail.gmail.com>
References: <CAN-DfD6=kDb8V8WXk_=XHtXvFEv7vCO9h0XHcraH=s7mJzjhNQ@mail.gmail.com>
Message-ID: <CAAg5f2SwChGHsRbP8wC+N54kNs-5_-J9NLR9toztQ+jmkFbvDQ@mail.gmail.com>

I think it was a recommendation from Gunnar, on the Hibernate-dev channel

On Thu, May 14, 2015 at 1:11 AM, Douglas Campos <qmx at qmx.me> wrote:

> Howdy!
>
> While working on rebasing the migration PR I've noticed that Lukas moved
> my 'category_seq' generator to the shiny-new 'enhanced-sequence' generator.
>
> Does anyone remembers the reasoning for the change? I'm asking because we
> do want a sequence-style generator BUT with individual sequence-like tables
> when using mysql. The reason for this is SEVERE contention with InnoDB
> tables under load - something that is prone to happen when you go with the
> `hibernate_sequence` magic table.
>
> I might be missing something.....HALP? :)
>
> []'z
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.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/20150515/292e97a6/attachment.html 

From lukas.fryc at gmail.com  Mon May 18 00:15:36 2015
From: lukas.fryc at gmail.com (=?UTF-8?B?THVrw6HFoSBGcnnEjQ==?=)
Date: Mon, 18 May 2015 06:15:36 +0200
Subject: [aerogear-dev] UPS Migrations for Master, Sequences and Friends
In-Reply-To: <CAN-DfD6=kDb8V8WXk_=XHtXvFEv7vCO9h0XHcraH=s7mJzjhNQ@mail.gmail.com>
References: <CAN-DfD6=kDb8V8WXk_=XHtXvFEv7vCO9h0XHcraH=s7mJzjhNQ@mail.gmail.com>
Message-ID: <CAEroY35Prg=9SOtJK0JFJ5H1mfMtPEuyCBW51ktLwN=-PvHGbQ@mail.gmail.com>

Heya qmx!

we was in the middle of switching from pure orm.xml to hbm.xml (in order to
allow column indexing in JPA 2.0),

when we found out the 'sequence' generator does not really work with MySQL
(the MySQL adapter complains about not supporting that configuration).


https://github.com/aerogear/aerogear-unifiedpush-server/commit/2a8fc6b70be82307da06a01050070a4eff201085


So Gunnar recommended 'enhanced-sequence' which should basically be a
sequence that use fallback strategy and it should be compliant with how
Hibernate operates for JPA 2.0 sequence configuration.

I would be perfectly happy with any solution that would allow us to use the
same strategy as before, but the problem is we didn't find one.


Do someone has any suggestions?

~ Lukas

On Thu, May 14, 2015 at 1:11 AM, Douglas Campos <qmx at qmx.me> wrote:

> Howdy!
>
> While working on rebasing the migration PR I've noticed that Lukas moved
> my 'category_seq' generator to the shiny-new 'enhanced-sequence' generator.
>
> Does anyone remembers the reasoning for the change? I'm asking because we
> do want a sequence-style generator BUT with individual sequence-like tables
> when using mysql. The reason for this is SEVERE contention with InnoDB
> tables under load - something that is prone to happen when you go with the
> `hibernate_sequence` magic table.
>
> I might be missing something.....HALP? :)
>
> []'z
>
> _______________________________________________
> 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/20150518/0167e2e0/attachment.html 

From edewit at redhat.com  Mon May 18 08:47:11 2015
From: edewit at redhat.com (Erik Jan de Wit)
Date: Mon, 18 May 2015 14:47:11 +0200
Subject: [aerogear-dev] [Aerogear-users] Aerogear Unified Push
 registration through a server backend
In-Reply-To: <5559D726.4030209@udl.cat>
References: <5559D726.4030209@udl.cat>
Message-ID: <CAO2B-fbL7j_gsj7oXhZpsqv74hKd9024M4o8W8gH6pMufZ5-UQ@mail.gmail.com>

The problem is that you don't want/need to call unregister in a normal
flow. Unregister is used for instance when a new version of you app
drops support for push notifications.

I don't get why you are proxy-ing the requests to UPS, because you
cannot have 2 applications receiving the same push notifications. On
iOS the bundle id makes sure of that, and on android there is the
unique project id. So even if a second app would register with UPS it
will not get the push notifications.

On Mon, May 18, 2015 at 2:12 PM, Alex Ballest?
<alexandre.balleste at udl.cat> wrote:
> Hi, I'm developing a mobile app for android and ios for our University. It
> will use AeroGear Unified Push Server to send notifications to students when
> a new announcement is sent in our LMS.
>
> We are developing the app with ionic framework and we are using the register
> and unregister process through a custom backend service instead of direct
> from device.
>
> We use the cordova plugin and we call registers and unregister JS methods,
> but we don't point to the push server endpoint, but backend server instead.
> Once the Backend server gets the requests it creates a new request to Push
> server providing variantSecret and variantID; the response received is sent
> back to the app.
>
> We would like to use this flow for security reasons. We want to avoid that
> the users do their own apps and use those values to register and supply
> alias to get users notifications. So backend handles the security (tokens,
> deviceids, usernames, ... ) and if everything is ok then proxies then
> backend generates a new request fullfilling alias and real authentication
> parameters and the received parameters from app. We achieved the registation
> and unregistration, but when unregistration process is done if we do a new
> re-registration then we got a success response, but then notification didn't
> arrive.
>
> Has anybody did something similar to this approximation? Do you have any
> advise or trick that would be useful for us?
>
> Thanks in advance
>
> Alex
>
>
>
> --
>
> Alexandre Ballest? Crevill?n alexandre.balleste at udl.cat
> ====================
> Universitat de Lleida
>
> ?rea de sistemes d'Informaci? i Comunicacions
>
> Analista/Programador
>
>
> University of Lleida
>
> Information and Communication Systems Service
>
>
> Tlf: +34 973 702148
>
> Fax: +34 973 702130
>
> =====================
>
> Av?s legal/Aviso legal/Avertiment legal/Legal notice
>
>
> _______________________________________________
> Aerogear-users mailing list
> Aerogear-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-users
>



-- 
Cheers,
       Erik Jan


From cvasilak at gmail.com  Mon May 18 13:14:44 2015
From: cvasilak at gmail.com (Christos Vasilakis)
Date: Mon, 18 May 2015 20:14:44 +0300
Subject: [aerogear-dev] What's new in AeroGear (18th May)
Message-ID: <CAKVvow-AWwY2Mywtw5cyJ-3yuyXWBHwPj5rOQ1LOY09LDrroyg@mail.gmail.com>

Hi all,

in order to minimize the amount of email on what's new in our various
platforms, we have decided to combine into one collective email (thanks to
abstractj for the suggestion!).

So here is our first instalment with a hope it will become a useful tool to
learn about our latest developments


*What's new in Android*

   - UPS Metrics support has been added into the push library
   <https://github.com/aerogear/aerogear-android-push/pull/36> as well as
   on the accompanied HelloWorld demo
   <https://github.com/danielpassos/unified-push-helloworld/tree/analytics>
   .

(Since analytics also cover all our platforms, if you are interested in the
topic, we suggest to visit our our analytics mail thread
<http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Metrics-Endpoint-was-Re-Advanced-Analtyics-new-PR-and-call-to-the-client-tech-leads-td11581.html>
to
get a high level view of the architecture)


   - Since we initiated work
   <https://github.com/simpligility/android-maven-plugin/issues/623> to
   support JUnit 4 in the official maven android-plugin and this work has been
   merged as part of the 4.2.1 release, we have started adding support in our
   android libraries too, with the first library to get love be the
   android-pipe <https://github.com/aerogear/aerogear-android-pipe/pull/35>.
   Work is under-way to support our other Android libraries too.

*What's new in iOS*

   - As with Android, work to support analytics has been started in
our push-sdk
   library <https://github.com/aerogear/aerogear-ios-push/pull/56> as well
   as on the accompanied HelloWorld demo app
   <https://github.com/jboss-mobile/unified-push-helloworld/pull/6>.
   Although work was initiated first for our Swift variants (we love Swift!),
   this week we'll carry on our effort for an ObjC version of the same API.
   - iOS 2.4 release is on its way! Main focus is to strengthen iOS7
   support and Objc/Swift interoperability. Check out project's JIRA tracker
   <https://issues.jboss.org/issues/?filter=12323789> for more details and
   help shape the release.


*What's new in Apache Cordova*

A new version of the Push Plugin 1.0.3 has been released. Details of the
release can be found in the official announcement
<http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-PushPlugin-release-1-0-3-td11592.html>
.


*What's new in JS*
Nothing new to report with regards to our JS libs but it was sure a heavy
week in the JS community with many core project having new releases: These
caught our attention:

* Convergence <https://github.com/nodejs/node> of Node.js and IO.js.
* Release of Ember 1.12
<http://emberjs.com/blog/2015/05/13/ember-1-12-released.html>
* Not really a new thing, but for those interested in using ES6 today you
many find this project <https://babeljs.io/> interesting.
* For those interested in Angular, there is a new tutorial
<https://auth0.com/blog/2015/05/14/creating-your-first-real-world-angular-2-app-from-authentication-to-calling-an-api-and-everything-in-between/>
on getting started with Angular 2.


We would love to get feedback and further testings from the community
regarding our current on-going analytic work, so if you have some spare
time that's a perfect time to jump-in and give us feedback.

That's all for now, see you all next week!

*AeroGear team*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20150518/7e0a2b93/attachment.html 

From matzew at apache.org  Wed May 20 10:45:21 2015
From: matzew at apache.org (Matthias Wessendorf)
Date: Wed, 20 May 2015 16:45:21 +0200
Subject: [aerogear-dev] UPS 1.1.0-beta.1 heads up
Message-ID: <CAAg5f2Tj2Z2xJMhA+Gp=jN5q3D2g3dzgSF-EVNPrDOp5qwQbEw@mail.gmail.com>

Hello,

we have a few pending PRs for 1.1.0-beta.1:
https://issues.jboss.org/browse/AGPUSH/fixforversion/12326579

These will be merged later today, or tomorrow (reviews are going on).

I have moved the migration task out to beta.2, since that is really a
larger concern for 1.1.0-final (and than coming from 1.0.3).

For Analytics, the following push libraries/sdks are merged:
* Android
* iOS
* Windows

That means, we can now start (for beta.2) on Cordova and also updating the
HelloWorld demos. The demos should be ready shortly after our beta.1
release, since the SDKs/libraries need releases (e.g. to CocoaPods, Maven
Central or Nugget).

If all goes well, with the PRs above, I'd like to TAG end of tomorrow. QE
is already able to run their tests based on latest.

After we tagged, there will be a bit of a code freeze for us, for testing
and stuff. Once beta.1 is finally released (~mid next week), the master
branch will be open again for beta.2 related PRs.

Any thoughts or questions?

-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/20150520/b0b80bd2/attachment.html 

From mwessendorf at gmail.com  Wed May 20 10:56:33 2015
From: mwessendorf at gmail.com (Matthias Wessendorf)
Date: Wed, 20 May 2015 16:56:33 +0200
Subject: [aerogear-dev] UPS 1.1.0-beta.1 heads up
Message-ID: <CAAg5f2S0PyV3djnV96CZ0RXkEDTBinqzA1d4sOvfhFo7kw3TAQ@mail.gmail.com>

Hello,

we have a few pending PRs for 1.1.0-beta.1:
https://issues.jboss.org/browse/AGPUSH/fixforversion/12326579

These will be merged later today, or tomorrow (reviews are going on).

I have moved the migration task out to beta.2, since that is really a
larger concern for 1.1.0-final (and than coming from 1.0.3).

For Analytics, the following push libraries/sdks are merged:
* Android
* iOS
* Windows

That means, we can now start (for beta.2) on Cordova and also updating the
HelloWorld demos. The demos should be ready shortly after our beta.1
release, since the SDKs/libraries need releases (e.g. to CocoaPods, Maven
Central or Nugget).

If all goes well, with the PRs above, I'd like to TAG end of tomorrow. QE
is already able to run their tests based on latest.

After we tagged, there will be a bit of a code freeze for us, for testing
and stuff. Once beta.1 is finally released (~mid next week), the master
branch will be open again for beta.2 related PRs.

Any thoughts or questions?

-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/20150520/3ef8c7f4/attachment.html 

From scm.blanc at gmail.com  Wed May 20 11:16:39 2015
From: scm.blanc at gmail.com (Sebastien Blanc)
Date: Wed, 20 May 2015 17:16:39 +0200
Subject: [aerogear-dev] test
Message-ID: <CAD_dpu0Em+LBt2_-_EcrxV0N35QubLicadSmR6R75EnHvtYR8A@mail.gmail.com>

test
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20150520/0cea06de/attachment.html 

From delalis at gmail.com  Wed May 20 15:57:24 2015
From: delalis at gmail.com (delalis)
Date: Wed, 20 May 2015 12:57:24 -0700 (MST)
Subject: [aerogear-dev] Android GCM PUSH ERROR - Error sending payload to
 GCM server: java.util.ConcurrentModificationException
Message-ID: <1432151844648-11655.post@n5.nabble.com>

I have Aerogear set up properly for iOS notifications and they are working,
however Android is not.  Registration works no problem, but sending pushes
does not.

 I have 4 devices registered and I am getting the following error when
sending a test notification to the devices.

 Error sending payload to GCM server:
java.util.ConcurrentModificationException


https://gist.github.com/anonymous/89d575bc8892f68bc0f5
<https://gist.github.com/anonymous/89d575bc8892f68bc0f5>  

Any help would be greatly appreciated!



--
View this message in context: http://aerogear-dev.1069024.n5.nabble.com/Android-GCM-PUSH-ERROR-Error-sending-payload-to-GCM-server-java-util-ConcurrentModificationException-tp11655.html
Sent from the aerogear-dev mailing list archive at Nabble.com.

From matzew at apache.org  Thu May 21 01:54:50 2015
From: matzew at apache.org (Matthias Wessendorf)
Date: Thu, 21 May 2015 07:54:50 +0200
Subject: [aerogear-dev] Android GCM PUSH ERROR - Error sending payload
 to GCM server: java.util.ConcurrentModificationException
In-Reply-To: <1432151844648-11655.post@n5.nabble.com>
References: <1432151844648-11655.post@n5.nabble.com>
Message-ID: <CAAg5f2QsB6Nm1bE7=6r-LXMx4O2OWGuuEcJXbY2PQg2rmG5F+w@mail.gmail.com>

Hi delalis,

thanks for reaching out to us, I've created
https://issues.jboss.org/browse/AGPUSH-1419 and we will take a look!

-Matthias



On Wed, May 20, 2015 at 9:57 PM, delalis <delalis at gmail.com> wrote:

> I have Aerogear set up properly for iOS notifications and they are working,
> however Android is not.  Registration works no problem, but sending pushes
> does not.
>
>  I have 4 devices registered and I am getting the following error when
> sending a test notification to the devices.
>
>  Error sending payload to GCM server:
> java.util.ConcurrentModificationException
>
>
> https://gist.github.com/anonymous/89d575bc8892f68bc0f5
> <https://gist.github.com/anonymous/89d575bc8892f68bc0f5>
>
> Any help would be greatly appreciated!
>
>
>
> --
> View this message in context:
> http://aerogear-dev.1069024.n5.nabble.com/Android-GCM-PUSH-ERROR-Error-sending-payload-to-GCM-server-java-util-ConcurrentModificationException-tp11655.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/20150521/57ef5f6e/attachment-0001.html 

From scm.blanc at gmail.com  Thu May 21 03:11:03 2015
From: scm.blanc at gmail.com (Sebastien Blanc)
Date: Thu, 21 May 2015 09:11:03 +0200
Subject: [aerogear-dev] UPS 1.1.0-beta.1 heads up
In-Reply-To: <CAAg5f2S0PyV3djnV96CZ0RXkEDTBinqzA1d4sOvfhFo7kw3TAQ@mail.gmail.com>
References: <CAAg5f2S0PyV3djnV96CZ0RXkEDTBinqzA1d4sOvfhFo7kw3TAQ@mail.gmail.com>
Message-ID: <CAD_dpu2Nma6S5hScwyjOQS5s1+bcxTicUE11fYYZ+cWdjaNdBA@mail.gmail.com>

That all sounds good ! +1

On Wed, May 20, 2015 at 4:56 PM, Matthias Wessendorf <mwessendorf at gmail.com>
wrote:

> Hello,
>
> we have a few pending PRs for 1.1.0-beta.1:
> https://issues.jboss.org/browse/AGPUSH/fixforversion/12326579
>
> These will be merged later today, or tomorrow (reviews are going on).
>
> I have moved the migration task out to beta.2, since that is really a
> larger concern for 1.1.0-final (and than coming from 1.0.3).
>
> For Analytics, the following push libraries/sdks are merged:
> * Android
> * iOS
> * Windows
>
> That means, we can now start (for beta.2) on Cordova and also updating the
> HelloWorld demos. The demos should be ready shortly after our beta.1
> release, since the SDKs/libraries need releases (e.g. to CocoaPods, Maven
> Central or Nugget).
>
> If all goes well, with the PRs above, I'd like to TAG end of tomorrow. QE
> is already able to run their tests based on latest.
>
> After we tagged, there will be a bit of a code freeze for us, for testing
> and stuff. Once beta.1 is finally released (~mid next week), the master
> branch will be open again for beta.2 related PRs.
>
> Any thoughts or questions?
>
> -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/20150521/7c1e2b60/attachment.html 

From mwessendorf at gmail.com  Thu May 21 05:16:35 2015
From: mwessendorf at gmail.com (Matthias Wessendorf)
Date: Thu, 21 May 2015 11:16:35 +0200
Subject: [aerogear-dev] UPS: Code Freeze (Re:  UPS 1.1.0-beta.1 heads up)
Message-ID: <CAAg5f2QWdMwykc-MBpYBTNUOwe=khbRKdo=D1oy2tkEYfvDfiw@mail.gmail.com>

Hi,

we have in the fixes for those tickets that we wanted on BETA.1:
https://issues.jboss.org/browse/AGPUSH/fixforversion/12326579

Let's freeze the MASTER branch for a few days. Later today (read: 2nite) I
will run the release plugin to create the TAG and get the bits up on
staging for testing.

Once the freeze is over, we will be merging the PRs for the next beta.2
release ;-)

Thanks for all the fixes on this release, especially Lukas has been kicking
ass around UI and JMS.


-Matthias


On Thu, May 21, 2015 at 9:11 AM, Sebastien Blanc <scm.blanc at gmail.com>
wrote:

> That all sounds good ! +1
>
> On Wed, May 20, 2015 at 4:56 PM, Matthias Wessendorf <
> mwessendorf at gmail.com> wrote:
>
>> Hello,
>>
>> we have a few pending PRs for 1.1.0-beta.1:
>> https://issues.jboss.org/browse/AGPUSH/fixforversion/12326579
>>
>> These will be merged later today, or tomorrow (reviews are going on).
>>
>> I have moved the migration task out to beta.2, since that is really a
>> larger concern for 1.1.0-final (and than coming from 1.0.3).
>>
>> For Analytics, the following push libraries/sdks are merged:
>> * Android
>> * iOS
>> * Windows
>>
>> That means, we can now start (for beta.2) on Cordova and also updating
>> the HelloWorld demos. The demos should be ready shortly after our beta.1
>> release, since the SDKs/libraries need releases (e.g. to CocoaPods, Maven
>> Central or Nugget).
>>
>> If all goes well, with the PRs above, I'd like to TAG end of tomorrow. QE
>> is already able to run their tests based on latest.
>>
>> After we tagged, there will be a bit of a code freeze for us, for testing
>> and stuff. Once beta.1 is finally released (~mid next week), the master
>> branch will be open again for beta.2 related PRs.
>>
>> Any thoughts or questions?
>>
>> -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/20150521/7b36b38b/attachment.html 

From mwessendorf at gmail.com  Thu May 21 07:23:10 2015
From: mwessendorf at gmail.com (Matthias Wessendorf)
Date: Thu, 21 May 2015 13:23:10 +0200
Subject: [aerogear-dev] UPS: Code Freeze (Re: UPS 1.1.0-beta.1 heads up)
In-Reply-To: <CAAg5f2QWdMwykc-MBpYBTNUOwe=khbRKdo=D1oy2tkEYfvDfiw@mail.gmail.com>
References: <CAAg5f2QWdMwykc-MBpYBTNUOwe=khbRKdo=D1oy2tkEYfvDfiw@mail.gmail.com>
Message-ID: <CAAg5f2RNynVv0Hh0wj=7r=_cxMjCQa=Ozu8u0u1sVq356_m6zQ@mail.gmail.com>

Hello,

we have a -SNAPSHOT dependency of "arquillian-container-chameleon":
https://github.com/aerogear/aerogear-unifiedpush-server/blob/b5a6d47b6a4e17b2ecab6a88cbad8186eb423b1f/push/sender/pom.xml#L161-L166

:-(




On Thu, May 21, 2015 at 11:16 AM, Matthias Wessendorf <mwessendorf at gmail.com
> wrote:

> Hi,
>
> we have in the fixes for those tickets that we wanted on BETA.1:
> https://issues.jboss.org/browse/AGPUSH/fixforversion/12326579
>
> Let's freeze the MASTER branch for a few days. Later today (read: 2nite) I
> will run the release plugin to create the TAG and get the bits up on
> staging for testing.
>
> Once the freeze is over, we will be merging the PRs for the next beta.2
> release ;-)
>
> Thanks for all the fixes on this release, especially Lukas has been
> kicking ass around UI and JMS.
>
>
> -Matthias
>
>
> On Thu, May 21, 2015 at 9:11 AM, Sebastien Blanc <scm.blanc at gmail.com>
> wrote:
>
>> That all sounds good ! +1
>>
>> On Wed, May 20, 2015 at 4:56 PM, Matthias Wessendorf <
>> mwessendorf at gmail.com> wrote:
>>
>>> Hello,
>>>
>>> we have a few pending PRs for 1.1.0-beta.1:
>>> https://issues.jboss.org/browse/AGPUSH/fixforversion/12326579
>>>
>>> These will be merged later today, or tomorrow (reviews are going on).
>>>
>>> I have moved the migration task out to beta.2, since that is really a
>>> larger concern for 1.1.0-final (and than coming from 1.0.3).
>>>
>>> For Analytics, the following push libraries/sdks are merged:
>>> * Android
>>> * iOS
>>> * Windows
>>>
>>> That means, we can now start (for beta.2) on Cordova and also updating
>>> the HelloWorld demos. The demos should be ready shortly after our beta.1
>>> release, since the SDKs/libraries need releases (e.g. to CocoaPods, Maven
>>> Central or Nugget).
>>>
>>> If all goes well, with the PRs above, I'd like to TAG end of tomorrow.
>>> QE is already able to run their tests based on latest.
>>>
>>> After we tagged, there will be a bit of a code freeze for us, for
>>> testing and stuff. Once beta.1 is finally released (~mid next week), the
>>> master branch will be open again for beta.2 related PRs.
>>>
>>> Any thoughts or questions?
>>>
>>> -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
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.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/20150521/e79f156c/attachment-0001.html 

From matzew at apache.org  Thu May 21 08:19:20 2015
From: matzew at apache.org (Matthias Wessendorf)
Date: Thu, 21 May 2015 14:19:20 +0200
Subject: [aerogear-dev] UPS: Code Freeze (Re: UPS 1.1.0-beta.1 heads up)
In-Reply-To: <CAAg5f2RNynVv0Hh0wj=7r=_cxMjCQa=Ozu8u0u1sVq356_m6zQ@mail.gmail.com>
References: <CAAg5f2QWdMwykc-MBpYBTNUOwe=khbRKdo=D1oy2tkEYfvDfiw@mail.gmail.com>
	<CAAg5f2RNynVv0Hh0wj=7r=_cxMjCQa=Ozu8u0u1sVq356_m6zQ@mail.gmail.com>
Message-ID: <CAAg5f2R_CXcTS6YTatf3V2L9nqCiJo=8dpuDsRpCwLtXkekhZQ@mail.gmail.com>

thanks lukas for the quick turn around

On Thu, May 21, 2015 at 1:23 PM, Matthias Wessendorf <mwessendorf at gmail.com>
wrote:

> Hello,
>
> we have a -SNAPSHOT dependency of "arquillian-container-chameleon":
>
> https://github.com/aerogear/aerogear-unifiedpush-server/blob/b5a6d47b6a4e17b2ecab6a88cbad8186eb423b1f/push/sender/pom.xml#L161-L166
>
> :-(
>
>
>
>
> On Thu, May 21, 2015 at 11:16 AM, Matthias Wessendorf <
> mwessendorf at gmail.com> wrote:
>
>> Hi,
>>
>> we have in the fixes for those tickets that we wanted on BETA.1:
>> https://issues.jboss.org/browse/AGPUSH/fixforversion/12326579
>>
>> Let's freeze the MASTER branch for a few days. Later today (read: 2nite)
>> I will run the release plugin to create the TAG and get the bits up on
>> staging for testing.
>>
>> Once the freeze is over, we will be merging the PRs for the next beta.2
>> release ;-)
>>
>> Thanks for all the fixes on this release, especially Lukas has been
>> kicking ass around UI and JMS.
>>
>>
>> -Matthias
>>
>>
>> On Thu, May 21, 2015 at 9:11 AM, Sebastien Blanc <scm.blanc at gmail.com>
>> wrote:
>>
>>> That all sounds good ! +1
>>>
>>> On Wed, May 20, 2015 at 4:56 PM, Matthias Wessendorf <
>>> mwessendorf at gmail.com> wrote:
>>>
>>>> Hello,
>>>>
>>>> we have a few pending PRs for 1.1.0-beta.1:
>>>> https://issues.jboss.org/browse/AGPUSH/fixforversion/12326579
>>>>
>>>> These will be merged later today, or tomorrow (reviews are going on).
>>>>
>>>> I have moved the migration task out to beta.2, since that is really a
>>>> larger concern for 1.1.0-final (and than coming from 1.0.3).
>>>>
>>>> For Analytics, the following push libraries/sdks are merged:
>>>> * Android
>>>> * iOS
>>>> * Windows
>>>>
>>>> That means, we can now start (for beta.2) on Cordova and also updating
>>>> the HelloWorld demos. The demos should be ready shortly after our beta.1
>>>> release, since the SDKs/libraries need releases (e.g. to CocoaPods, Maven
>>>> Central or Nugget).
>>>>
>>>> If all goes well, with the PRs above, I'd like to TAG end of tomorrow.
>>>> QE is already able to run their tests based on latest.
>>>>
>>>> After we tagged, there will be a bit of a code freeze for us, for
>>>> testing and stuff. Once beta.1 is finally released (~mid next week), the
>>>> master branch will be open again for beta.2 related PRs.
>>>>
>>>> Any thoughts or questions?
>>>>
>>>> -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
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.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/20150521/4f462195/attachment.html 

From delalis at gmail.com  Thu May 21 13:12:06 2015
From: delalis at gmail.com (delalis)
Date: Thu, 21 May 2015 10:12:06 -0700 (MST)
Subject: [aerogear-dev] Android GCM PUSH ERROR - Error sending payload
 to GCM server: java.util.ConcurrentModificationException
In-Reply-To: <CAAg5f2QsB6Nm1bE7=6r-LXMx4O2OWGuuEcJXbY2PQg2rmG5F+w@mail.gmail.com>
References: <1432151844648-11655.post@n5.nabble.com>
	<CAAg5f2QsB6Nm1bE7=6r-LXMx4O2OWGuuEcJXbY2PQg2rmG5F+w@mail.gmail.com>
Message-ID: <1432228326487-11664.post@n5.nabble.com>

Thanks Matthias!  Could you please reply to this thread when and if you get a
fix for this into the next build?  That way I will know when I can download
it.  

In the mean time I am going to reinstall the aerogear server from scratch to
make sure I didnt miss something.  Also, FYI, I am using a mySQL backend.

Cheers



--
View this message in context: http://aerogear-dev.1069024.n5.nabble.com/Android-GCM-PUSH-ERROR-Error-sending-payload-to-GCM-server-java-util-ConcurrentModificationException-tp11655p11664.html
Sent from the aerogear-dev mailing list archive at Nabble.com.

From mwessendorf at gmail.com  Thu May 21 15:21:55 2015
From: mwessendorf at gmail.com (Matthias Wessendorf)
Date: Thu, 21 May 2015 21:21:55 +0200
Subject: [aerogear-dev] UnifiedPush Server 1.1.0-beta.1
Message-ID: <CAAg5f2Rpiq0L0CmvARgc9m_a==rjjLKyMDaADTP00MeL_18oUg@mail.gmail.com>

Hi,

after month of work, here is the first beta release for the UPS 1.1.0. It
contains more features and inprovements around UI, JMS for enhanced
scalability and a lot of other stuff:
https://issues.jboss.org/browse/AGPUSH/fixforversion/12326579


Please test the staged release:
https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-5605/

Like w/ the previous alpha.2, please make sure you use a full profile
WildFly or EAP server for tests, since we now have JMS hooks ;-)
(See README for details)

On Wednesday I'd like to press the button to release it to the wild.

PS: Since this is the first beta release we won't yet be updating our
Openshift cartridge - that will stay on 1.0.3 (stable) for a little longer
time. For the next release (beta.2) in a few weeks we may get to this
Openshift update.

Thanks,
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/20150521/c363d16c/attachment.html 

From mwessendorf at gmail.com  Thu May 21 16:15:50 2015
From: mwessendorf at gmail.com (Matthias Wessendorf)
Date: Thu, 21 May 2015 22:15:50 +0200
Subject: [aerogear-dev] UnifiedPush Server 1.1.0-beta.1
In-Reply-To: <CAAg5f2Rpiq0L0CmvARgc9m_a==rjjLKyMDaADTP00MeL_18oUg@mail.gmail.com>
References: <CAAg5f2Rpiq0L0CmvARgc9m_a==rjjLKyMDaADTP00MeL_18oUg@mail.gmail.com>
Message-ID: <CAAg5f2SvujHDvc8OU_eK-fDJ=r3GoNjuwiJkk1=TpxjSzepgdg@mail.gmail.com>

we need to re-stage, due to this bug:
https://github.com/aerogear/aerogear-unifiedpush-server/pull/568

On Thu, May 21, 2015 at 9:21 PM, Matthias Wessendorf <mwessendorf at gmail.com>
wrote:

> Hi,
>
> after month of work, here is the first beta release for the UPS 1.1.0. It
> contains more features and inprovements around UI, JMS for enhanced
> scalability and a lot of other stuff:
> https://issues.jboss.org/browse/AGPUSH/fixforversion/12326579
>
>
> Please test the staged release:
>
> https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-5605/
>
> Like w/ the previous alpha.2, please make sure you use a full profile
> WildFly or EAP server for tests, since we now have JMS hooks ;-)
> (See README for details)
>
> On Wednesday I'd like to press the button to release it to the wild.
>
> PS: Since this is the first beta release we won't yet be updating our
> Openshift cartridge - that will stay on 1.0.3 (stable) for a little longer
> time. For the next release (beta.2) in a few weeks we may get to this
> Openshift update.
>
> Thanks,
> Matthias
>
>
>
>
> --
> 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/20150521/64282949/attachment.html 

From matzew at apache.org  Thu May 21 16:18:55 2015
From: matzew at apache.org (Matthias Wessendorf)
Date: Thu, 21 May 2015 22:18:55 +0200
Subject: [aerogear-dev] UnifiedPush Server 1.1.0-beta.1
In-Reply-To: <CAAg5f2SvujHDvc8OU_eK-fDJ=r3GoNjuwiJkk1=TpxjSzepgdg@mail.gmail.com>
References: <CAAg5f2Rpiq0L0CmvARgc9m_a==rjjLKyMDaADTP00MeL_18oUg@mail.gmail.com>
	<CAAg5f2SvujHDvc8OU_eK-fDJ=r3GoNjuwiJkk1=TpxjSzepgdg@mail.gmail.com>
Message-ID: <CAAg5f2RcJGPXS24k06Ayt4Ouswhgy1qU-faA6z2NTrRNC=JEtA@mail.gmail.com>

please give it a spin, so that I can merege it, in order to actually do the
re-staging

On Thu, May 21, 2015 at 10:15 PM, Matthias Wessendorf <mwessendorf at gmail.com
> wrote:

> we need to re-stage, due to this bug:
> https://github.com/aerogear/aerogear-unifiedpush-server/pull/568
>
> On Thu, May 21, 2015 at 9:21 PM, Matthias Wessendorf <
> mwessendorf at gmail.com> wrote:
>
>> Hi,
>>
>> after month of work, here is the first beta release for the UPS 1.1.0. It
>> contains more features and inprovements around UI, JMS for enhanced
>> scalability and a lot of other stuff:
>> https://issues.jboss.org/browse/AGPUSH/fixforversion/12326579
>>
>>
>> Please test the staged release:
>>
>> https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-5605/
>>
>> Like w/ the previous alpha.2, please make sure you use a full profile
>> WildFly or EAP server for tests, since we now have JMS hooks ;-)
>> (See README for details)
>>
>> On Wednesday I'd like to press the button to release it to the wild.
>>
>> PS: Since this is the first beta release we won't yet be updating our
>> Openshift cartridge - that will stay on 1.0.3 (stable) for a little longer
>> time. For the next release (beta.2) in a few weeks we may get to this
>> Openshift update.
>>
>> Thanks,
>> Matthias
>>
>>
>>
>>
>> --
>> 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/20150521/a9e1d001/attachment-0001.html 

From matzew at apache.org  Thu May 21 16:33:16 2015
From: matzew at apache.org (Matthias Wessendorf)
Date: Thu, 21 May 2015 22:33:16 +0200
Subject: [aerogear-dev] UnifiedPush Server 1.1.0-beta.1
In-Reply-To: <CAAg5f2RcJGPXS24k06Ayt4Ouswhgy1qU-faA6z2NTrRNC=JEtA@mail.gmail.com>
References: <CAAg5f2Rpiq0L0CmvARgc9m_a==rjjLKyMDaADTP00MeL_18oUg@mail.gmail.com>
	<CAAg5f2SvujHDvc8OU_eK-fDJ=r3GoNjuwiJkk1=TpxjSzepgdg@mail.gmail.com>
	<CAAg5f2RcJGPXS24k06Ayt4Ouswhgy1qU-faA6z2NTrRNC=JEtA@mail.gmail.com>
Message-ID: <CAAg5f2Tf1b5EA3N7+Zg4Mamrvc9p4vGuWjmV_=aJEuGw5E7qTA@mail.gmail.com>

NEVERMIND, see
https://github.com/aerogear/aerogear-unifiedpush-server/pull/568 for details

staging stays, and we continue w/ 1.1.0 of Keycloak

On Thu, May 21, 2015 at 10:18 PM, Matthias Wessendorf <matzew at apache.org>
wrote:

> please give it a spin, so that I can merege it, in order to actually do
> the re-staging
>
> On Thu, May 21, 2015 at 10:15 PM, Matthias Wessendorf <
> mwessendorf at gmail.com> wrote:
>
>> we need to re-stage, due to this bug:
>> https://github.com/aerogear/aerogear-unifiedpush-server/pull/568
>>
>> On Thu, May 21, 2015 at 9:21 PM, Matthias Wessendorf <
>> mwessendorf at gmail.com> wrote:
>>
>>> Hi,
>>>
>>> after month of work, here is the first beta release for the UPS 1.1.0.
>>> It contains more features and inprovements around UI, JMS for enhanced
>>> scalability and a lot of other stuff:
>>> https://issues.jboss.org/browse/AGPUSH/fixforversion/12326579
>>>
>>>
>>> Please test the staged release:
>>>
>>> https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-5605/
>>>
>>> Like w/ the previous alpha.2, please make sure you use a full profile
>>> WildFly or EAP server for tests, since we now have JMS hooks ;-)
>>> (See README for details)
>>>
>>> On Wednesday I'd like to press the button to release it to the wild.
>>>
>>> PS: Since this is the first beta release we won't yet be updating our
>>> Openshift cartridge - that will stay on 1.0.3 (stable) for a little longer
>>> time. For the next release (beta.2) in a few weeks we may get to this
>>> Openshift update.
>>>
>>> Thanks,
>>> Matthias
>>>
>>>
>>>
>>>
>>> --
>>> 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
>



-- 
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/20150521/c6a3c987/attachment.html 

From mwessendorf at gmail.com  Thu May 21 16:45:46 2015
From: mwessendorf at gmail.com (Matthias Wessendorf)
Date: Thu, 21 May 2015 22:45:46 +0200
Subject: [aerogear-dev] Java Sender 1.1.0-beta.1 (was: Re: UnifiedPush
	Server 1.1.0-beta.1)
Message-ID: <CAAg5f2TkmtzwGWvZU92UTw=XSpbE09axffpg7LGA-7+mWH2QRQ@mail.gmail.com>

related, here is the staging for the sender:


https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-5606/


yes, I know the UPS UI does not match that, but that's OK. See also:
https://github.com/aerogear/aerogear-unifiedpush-server/pull/569

On Thu, May 21, 2015 at 9:21 PM, Matthias Wessendorf <mwessendorf at gmail.com>
wrote:

> Hi,
>
> after month of work, here is the first beta release for the UPS 1.1.0. It
> contains more features and inprovements around UI, JMS for enhanced
> scalability and a lot of other stuff:
> https://issues.jboss.org/browse/AGPUSH/fixforversion/12326579
>
>
> Please test the staged release:
>
> https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-5605/
>
> Like w/ the previous alpha.2, please make sure you use a full profile
> WildFly or EAP server for tests, since we now have JMS hooks ;-)
> (See README for details)
>
> On Wednesday I'd like to press the button to release it to the wild.
>
> PS: Since this is the first beta release we won't yet be updating our
> Openshift cartridge - that will stay on 1.0.3 (stable) for a little longer
> time. For the next release (beta.2) in a few weeks we may get to this
> Openshift update.
>
> Thanks,
> Matthias
>
>
>
>
> --
> 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/20150521/6a3d6ff8/attachment.html 

From tkriz at redhat.com  Thu May 21 17:39:08 2015
From: tkriz at redhat.com (Tadeas Kriz)
Date: Thu, 21 May 2015 23:39:08 +0200
Subject: [aerogear-dev] UnifiedPush Server 1.1.0-beta.1
In-Reply-To: <CAAg5f2Tf1b5EA3N7+Zg4Mamrvc9p4vGuWjmV_=aJEuGw5E7qTA@mail.gmail.com>
References: <CAAg5f2Rpiq0L0CmvARgc9m_a==rjjLKyMDaADTP00MeL_18oUg@mail.gmail.com>
	<CAAg5f2SvujHDvc8OU_eK-fDJ=r3GoNjuwiJkk1=TpxjSzepgdg@mail.gmail.com>
	<CAAg5f2RcJGPXS24k06Ayt4Ouswhgy1qU-faA6z2NTrRNC=JEtA@mail.gmail.com>
	<CAAg5f2Tf1b5EA3N7+Zg4Mamrvc9p4vGuWjmV_=aJEuGw5E7qTA@mail.gmail.com>
Message-ID: <CAJ0HFMAQaEue=mW6+eKvR1V9B4oTH86MO3yb41sbvi-T4pyfwg@mail.gmail.com>

Hey,

I've just run integration tests and the UnifiedPush Server works great. One
huge downside is the change that breaks the API of Java Sender and that the
API is currently in somehow inconsistent state (it is synchronous, but it
uses callback to deliver the `success` state and throws exception to
deliver the `failed` state).

Now I'm going to proceed with the real-device testing.

On Thu, May 21, 2015 at 10:33 PM, Matthias Wessendorf <matzew at apache.org>
wrote:

> NEVERMIND, see
> https://github.com/aerogear/aerogear-unifiedpush-server/pull/568 for
> details
>
> staging stays, and we continue w/ 1.1.0 of Keycloak
>
> On Thu, May 21, 2015 at 10:18 PM, Matthias Wessendorf <matzew at apache.org>
> wrote:
>
>> please give it a spin, so that I can merege it, in order to actually do
>> the re-staging
>>
>> On Thu, May 21, 2015 at 10:15 PM, Matthias Wessendorf <
>> mwessendorf at gmail.com> wrote:
>>
>>> we need to re-stage, due to this bug:
>>> https://github.com/aerogear/aerogear-unifiedpush-server/pull/568
>>>
>>> On Thu, May 21, 2015 at 9:21 PM, Matthias Wessendorf <
>>> mwessendorf at gmail.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> after month of work, here is the first beta release for the UPS 1.1.0.
>>>> It contains more features and inprovements around UI, JMS for enhanced
>>>> scalability and a lot of other stuff:
>>>> https://issues.jboss.org/browse/AGPUSH/fixforversion/12326579
>>>>
>>>>
>>>> Please test the staged release:
>>>>
>>>> https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-5605/
>>>>
>>>> Like w/ the previous alpha.2, please make sure you use a full profile
>>>> WildFly or EAP server for tests, since we now have JMS hooks ;-)
>>>> (See README for details)
>>>>
>>>> On Wednesday I'd like to press the button to release it to the wild.
>>>>
>>>> PS: Since this is the first beta release we won't yet be updating our
>>>> Openshift cartridge - that will stay on 1.0.3 (stable) for a little longer
>>>> time. For the next release (beta.2) in a few weeks we may get to this
>>>> Openshift update.
>>>>
>>>> Thanks,
>>>> Matthias
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> 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
>>
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>



-- 
--
Tadeas Kriz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20150521/9865550a/attachment.html 

From tkriz at redhat.com  Thu May 21 21:24:52 2015
From: tkriz at redhat.com (Tadeas Kriz)
Date: Fri, 22 May 2015 03:24:52 +0200
Subject: [aerogear-dev] UnifiedPush Server 1.1.0-beta.1
In-Reply-To: <CAJ0HFMAQaEue=mW6+eKvR1V9B4oTH86MO3yb41sbvi-T4pyfwg@mail.gmail.com>
References: <CAAg5f2Rpiq0L0CmvARgc9m_a==rjjLKyMDaADTP00MeL_18oUg@mail.gmail.com>
	<CAAg5f2SvujHDvc8OU_eK-fDJ=r3GoNjuwiJkk1=TpxjSzepgdg@mail.gmail.com>
	<CAAg5f2RcJGPXS24k06Ayt4Ouswhgy1qU-faA6z2NTrRNC=JEtA@mail.gmail.com>
	<CAAg5f2Tf1b5EA3N7+Zg4Mamrvc9p4vGuWjmV_=aJEuGw5E7qTA@mail.gmail.com>
	<CAJ0HFMAQaEue=mW6+eKvR1V9B4oTH86MO3yb41sbvi-T4pyfwg@mail.gmail.com>
Message-ID: <CAJ0HFMDLVz8oY9TH7YVCK+a85vLG=xFC=quRADbjv4Mpf4HQhA@mail.gmail.com>

UnifiedPush Server 1.1.0-beta.1 testing report

Hello there again,

so I have tested the UPS using the UI console, iOS 8.0 and Android 5.1. I
have used the HelloPush example as to me it seems the best for testing the
server and messaging.

I have not tested the Windows, SimplePush and Amazon. The Simple Push was
tested in the automated integration tests, but that does not apply for
Windows and Amazon as we do not have the test cases for those. I also could
not test them manually because I do not have Windows nor Amazon developer
accounts.

I have tortured the Admin UI quite thoroughly and it did really well. There
were some bugs and some UX quirks that I suggest we fix into the next beta
release.
Kudos for:

   - Absolutely f***ing awesome wizard in the UnifiedPush Server Admin UI.
   I have loved every step of it and what totally amazed me was that when I
   deployed the app on the device and the app registered itself to the UPS,
   the wizard automagically progreessed to the next step! That is so damn
   awesome and the UX is just wonderful.
      - It was so great that I (as a user) would not mind if it was shown
      also when creating another variants in an application that already has
      some, because it makes it more friendly and gives the feedback when the
      first registration is successful.
   - It is also great that the user does not need to click on a link to
   keep logged in and only focusing the window is enough. Thanks for that.
   - iOS HelloPush example is Swift 1.2 ready!
   - Very nice error reporting in iOS HelloPush example (I set the URL
   wrong and the app told me about registration issue)

Found bugs

   -

   When sending push message using the UI, the following can happen:
   1. Check one or more variants in the variants list
      2. Uncheck all of the variants (this will leave you in the same
      visual state as it was before step 1.)
      3. Send the message
      4. Wonder why it was not sent to any of the devices

   It seems that when I open the dialog, it shows *No variants*, but it
   really means *All variants*. However when I check some variants and then
   uncheck them all, it will still say *No variants*, but now it really
   means it as *No variants*. My suggestion is to start with having all the
   variants checked and instead of listing them all separated by commas, we
   should show*All variants*.
   -

   For some strange reason there is a lot of space in the bottom and I can
   scroll away all the content.
   - There are *?* help icons/buttons in the lower-right corners [5] in the
   analytics panel, but they do not do or show anything.
   - In the variant list it still shows *0 delivered*[7] even when I
   already sent and delivered messages.
   - In *Sender API* tab there is always *Set up Java UPS* on top of the
   other sender platform (see [2, 3, 4])
   - Clicking the *Read more* about master secret and push app id security
   [8] leads to */ag-push/#* (and somehow corrupts the history and I could
   not hit back button).
   - Search in PushApplication list does not work (and I am not sure if it
   is necessary as there should not be that many apps).

UI/UX Quirks

   - Variant creation dialog wraps text when there is a lot of space [1].
   - The area between number of devices and *edit* button shows the
*hand* cursor,
   but it is not clickable. I would suggest to make it clickable and the
   action would be expanding/collapsing the variant detail.
   - The *+*/*-* button for expanding/collapsing the statistics does not
   show *hand* cursor when mouse is above it.
   - In the top right corner of the window, there is the *warnings*
information,
   however it is strange when there are no warnings so I would suggest one of
   these:
      1. Do not show it in the bar altogether when there are no warnings
      2. Disable the *clickability* of it when there are no warnings
      3. When the popup is shown, it should not be just an empty box[6],
      but should show something like *No warnings*
   - When hitting the *Edit* variant button, it shows a dialog where I can
   change only the name of the variant. However when I click the*Change
   network options* button, I am presented with the possibility to change
   both the name of the variant and the network specific configuration. I
   would therefore suggest to not show the name field in the *Change
   network options* dialog as it is not considered a good practise to have
   two ways of doing the same thing in UI.
   - It is a bit strange that when I hover over the *copy* (sources) in
   variant detail, the *edit* and delete buttons disappear until I move the
   mouse away from the *copy*.
   - Links to *Android*, *Chrome*, *iOS*, *Cordova* etc. in variant detail
   should open the documentation in a new tab like the rest of documentation
   links. Now it opens in the same app which is not good because the user
   wants to stay in the Admin UI.
   - When I click on the *in the documentation* link on the *no
variants* screen,
   I get redirected correcly, but it takes a while for the images to load and
   it pushes the content away and I lose track where was the help I came for.
   I would suggest to set the dimensions into the <img> tags therefore it will
   not push the screen away, but simply load into the empty space.
   - Each time the user wants to do a destructive action (i.e. *deleting
   application*, *deleting variant*,*reseting master secret*) he should be
   presented with a dialog in which he would have to type the name of the
   *variant*or *application* in order to continue. This was already in
   before and I am not sure why was it removed.

Questions

   - I am not sure what *x receivers / y opened* means as well as the
   meaning of *first time opened* and*last time opened*.
   - Is there a way to access the list of registered installations as it
   was before? Should it?
   - In analytics there are *Push opens* statistics. Does that mean there
   is some new API in UnifiedPush Server? If so should we test it? If so how?

One more thing

It would be great if we implemented documentation versioning similar to
readthedocs.org <http://www.readthedocs.org/>. That way there could be more
versions of the documentation hosted on the aerogear.org
<http://www.aerogear.org/> site and each version of UnifiedPush Server
Admin UI could point to the specific version. It would lead to better user
experience because they would see the documentation exactly for their
version.

All taken into consideration the team did a great job on the 1.1.0 and even
though it is still just beta.1, it is working very well. Thanks guys!

PS: Sorry for the order of images, it is 3 am and I was too tired to
reorganize them. Also I did not yet create any JIRA tickets for the bugs. I
just wanted to share the report with you guys so we can discuss which of
the items will be moved into the JIRA as tickets and which are not
important or would me marked as "won't fix".

Thanks,
Tadeas Kriz

1 -
https://lh5.googleusercontent.com/-OHKxiXEIT88/VV6DvB0uRKI/AAAAAAAAX5I/a-m6umCfZUo/w593-h758-no/Screen%2BShot%2B2015-05-22%2Bat%2B12.14.05%2Bam.png
2 -
https://lh5.googleusercontent.com/-KzruF4kzwj4/VV6Dyuu1kxI/AAAAAAAAX5o/RFuCFGzxtXo/w1192-h512-no/Screen%2BShot%2B2015-05-22%2Bat%2B1.27.53%2Bam.png
3 -
https://lh6.googleusercontent.com/-ZAlJzi51BX0/VV6Dx1J3SxI/AAAAAAAAX5k/UQiql9TMye4/w1187-h571-no/Screen%2BShot%2B2015-05-22%2Bat%2B1.27.58%2Bam.png
4 -
https://lh6.googleusercontent.com/-LHyvZPW5AzI/VV6DxSuf-yI/AAAAAAAAX5c/bi9eJaQ6RLc/w1199-h491-no/Screen%2BShot%2B2015-05-22%2Bat%2B1.28.04%2Bam.png
5 -
https://lh6.googleusercontent.com/-A-dpKMM4IcU/VV6D1WjHp5I/AAAAAAAAX54/XeQC-2KUqVg/w373-h146-no/Screen%2BShot%2B2015-05-22%2Bat%2B1.12.15%2Bam.png
6 -
https://lh3.googleusercontent.com/-dU4Weqwf5as/VV6D2OFf-II/AAAAAAAAX6A/T5CDLREzT-w/w277-h83-no/Screen%2BShot%2B2015-05-22%2Bat%2B1.09.51%2Bam.png
7 -
https://lh5.googleusercontent.com/-q_0F21tJZgo/VV6Dz4jZJPI/AAAAAAAAX5w/ngGABCT_AUM/w320-h316-no/Screen%2BShot%2B2015-05-22%2Bat%2B1.19.53%2Bam.png
8 -
https://lh5.googleusercontent.com/-57qlJTvJEBI/VV6Dwg3i0SI/AAAAAAAAX5Q/KPQxgw1DS0w/w644-h63-no/Screen%2BShot%2B2015-05-22%2Bat%2B1.28.56%2Bam.png


On Thu, May 21, 2015 at 11:39 PM, Tadeas Kriz <tkriz at redhat.com> wrote:

> Hey,
>
> I've just run integration tests and the UnifiedPush Server works great.
> One huge downside is the change that breaks the API of Java Sender and that
> the API is currently in somehow inconsistent state (it is synchronous, but
> it uses callback to deliver the `success` state and throws exception to
> deliver the `failed` state).
>
> Now I'm going to proceed with the real-device testing.
>
> On Thu, May 21, 2015 at 10:33 PM, Matthias Wessendorf <matzew at apache.org>
> wrote:
>
>> NEVERMIND, see
>> https://github.com/aerogear/aerogear-unifiedpush-server/pull/568 for
>> details
>>
>> staging stays, and we continue w/ 1.1.0 of Keycloak
>>
>> On Thu, May 21, 2015 at 10:18 PM, Matthias Wessendorf <matzew at apache.org>
>> wrote:
>>
>>> please give it a spin, so that I can merege it, in order to actually do
>>> the re-staging
>>>
>>> On Thu, May 21, 2015 at 10:15 PM, Matthias Wessendorf <
>>> mwessendorf at gmail.com> wrote:
>>>
>>>> we need to re-stage, due to this bug:
>>>> https://github.com/aerogear/aerogear-unifiedpush-server/pull/568
>>>>
>>>> On Thu, May 21, 2015 at 9:21 PM, Matthias Wessendorf <
>>>> mwessendorf at gmail.com> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> after month of work, here is the first beta release for the UPS 1.1.0.
>>>>> It contains more features and inprovements around UI, JMS for enhanced
>>>>> scalability and a lot of other stuff:
>>>>> https://issues.jboss.org/browse/AGPUSH/fixforversion/12326579
>>>>>
>>>>>
>>>>> Please test the staged release:
>>>>>
>>>>> https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-5605/
>>>>>
>>>>> Like w/ the previous alpha.2, please make sure you use a full profile
>>>>> WildFly or EAP server for tests, since we now have JMS hooks ;-)
>>>>> (See README for details)
>>>>>
>>>>> On Wednesday I'd like to press the button to release it to the wild.
>>>>>
>>>>> PS: Since this is the first beta release we won't yet be updating our
>>>>> Openshift cartridge - that will stay on 1.0.3 (stable) for a little longer
>>>>> time. For the next release (beta.2) in a few weeks we may get to this
>>>>> Openshift update.
>>>>>
>>>>> Thanks,
>>>>> Matthias
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> 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
>>>
>>
>>
>>
>> --
>> Matthias Wessendorf
>>
>> blog: http://matthiaswessendorf.wordpress.com/
>> sessions: http://www.slideshare.net/mwessendorf
>> twitter: http://twitter.com/mwessendorf
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
>
> --
> --
> Tadeas Kriz
>



-- 
--
Tadeas Kriz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20150522/bd192b0a/attachment-0001.html 

From lukas.fryc at gmail.com  Fri May 22 07:30:00 2015
From: lukas.fryc at gmail.com (=?UTF-8?B?THVrw6HFoSBGcnnEjQ==?=)
Date: Fri, 22 May 2015 13:30:00 +0200
Subject: [aerogear-dev] UnifiedPush Server 1.1.0-beta.1
In-Reply-To: <CAJ0HFMDLVz8oY9TH7YVCK+a85vLG=xFC=quRADbjv4Mpf4HQhA@mail.gmail.com>
References: <CAAg5f2Rpiq0L0CmvARgc9m_a==rjjLKyMDaADTP00MeL_18oUg@mail.gmail.com>
	<CAAg5f2SvujHDvc8OU_eK-fDJ=r3GoNjuwiJkk1=TpxjSzepgdg@mail.gmail.com>
	<CAAg5f2RcJGPXS24k06Ayt4Ouswhgy1qU-faA6z2NTrRNC=JEtA@mail.gmail.com>
	<CAAg5f2Tf1b5EA3N7+Zg4Mamrvc9p4vGuWjmV_=aJEuGw5E7qTA@mail.gmail.com>
	<CAJ0HFMAQaEue=mW6+eKvR1V9B4oTH86MO3yb41sbvi-T4pyfwg@mail.gmail.com>
	<CAJ0HFMDLVz8oY9TH7YVCK+a85vLG=xFC=quRADbjv4Mpf4HQhA@mail.gmail.com>
Message-ID: <CAEroY35uSYOPWdZ0Xnps-VYtvVfJaWvSW8fXDedn79Qry8Dkxg@mail.gmail.com>

Thanks Tadeas,

that's wonderful feedback!

On Fri, May 22, 2015 at 3:24 AM, Tadeas Kriz <tkriz at redhat.com> wrote:

> UnifiedPush Server 1.1.0-beta.1 testing report
>
> Hello there again,
>
> so I have tested the UPS using the UI console, iOS 8.0 and Android 5.1. I
> have used the HelloPush example as to me it seems the best for testing the
> server and messaging.
>
> I have not tested the Windows, SimplePush and Amazon. The Simple Push was
> tested in the automated integration tests, but that does not apply for
> Windows and Amazon as we do not have the test cases for those. I also could
> not test them manually because I do not have Windows nor Amazon developer
> accounts.
>
> I have tortured the Admin UI quite thoroughly and it did really well.
> There were some bugs and some UX quirks that I suggest we fix into the next
> beta release.
> Kudos for:
>
>    - Absolutely f***ing awesome wizard in the UnifiedPush Server Admin
>    UI. I have loved every step of it and what totally amazed me was that when
>    I deployed the app on the device and the app registered itself to the UPS,
>    the wizard automagically progreessed to the next step! That is so damn
>    awesome and the UX is just wonderful.
>       - It was so great that I (as a user) would not mind if it was shown
>       also when creating another variants in an application that already has
>       some, because it makes it more friendly and gives the feedback when the
>       first registration is successful.
>    - It is also great that the user does not need to click on a link to
>    keep logged in and only focusing the window is enough. Thanks for that.
>    - iOS HelloPush example is Swift 1.2 ready!
>    - Very nice error reporting in iOS HelloPush example (I set the URL
>    wrong and the app told me about registration issue)
>
> Found bugs
>
>    -
>
>    When sending push message using the UI, the following can happen:
>    1. Check one or more variants in the variants list
>       2. Uncheck all of the variants (this will leave you in the same
>       visual state as it was before step 1.)
>       3. Send the message
>       4. Wonder why it was not sent to any of the devices
>
>    It seems that when I open the dialog, it shows *No variants*, but it
>    really means *All variants*. However when I check some variants and
>    then uncheck them all, it will still say *No variants*, but now it
>    really means it as *No variants*. My suggestion is to start with
>    having all the variants checked and instead of listing them all separated
>    by commas, we should show*All variants*.
>    -
>
>    For some strange reason there is a lot of space in the bottom and I
>    can scroll away all the content.
>    - There are *?* help icons/buttons in the lower-right corners [5] in
>    the analytics panel, but they do not do or show anything.
>    - In the variant list it still shows *0 delivered*[7] even when I
>    already sent and delivered messages.
>    - In *Sender API* tab there is always *Set up Java UPS* on top of the
>    other sender platform (see [2, 3, 4])
>    - Clicking the *Read more* about master secret and push app id
>    security [8] leads to */ag-push/#* (and somehow corrupts the history
>    and I could not hit back button).
>    - Search in PushApplication list does not work (and I am not sure if
>    it is necessary as there should not be that many apps).
>
> UI/UX Quirks
>
>    - Variant creation dialog wraps text when there is a lot of space [1].
>    - The area between number of devices and *edit* button shows the *hand* cursor,
>    but it is not clickable. I would suggest to make it clickable and the
>    action would be expanding/collapsing the variant detail.
>    - The *+*/*-* button for expanding/collapsing the statistics does not
>    show *hand* cursor when mouse is above it.
>    - In the top right corner of the window, there is the *warnings* information,
>    however it is strange when there are no warnings so I would suggest one of
>    these:
>       1. Do not show it in the bar altogether when there are no warnings
>       2. Disable the *clickability* of it when there are no warnings
>       3. When the popup is shown, it should not be just an empty box[6],
>       but should show something like *No warnings*
>    - When hitting the *Edit* variant button, it shows a dialog where I
>    can change only the name of the variant. However when I click the*Change
>    network options* button, I am presented with the possibility to change
>    both the name of the variant and the network specific configuration. I
>    would therefore suggest to not show the name field in the *Change
>    network options* dialog as it is not considered a good practise to
>    have two ways of doing the same thing in UI.
>    - It is a bit strange that when I hover over the *copy* (sources) in
>    variant detail, the *edit* and delete buttons disappear until I move
>    the mouse away from the *copy*.
>    - Links to *Android*, *Chrome*, *iOS*, *Cordova* etc. in variant
>    detail should open the documentation in a new tab like the rest of
>    documentation links. Now it opens in the same app which is not good because
>    the user wants to stay in the Admin UI.
>    - When I click on the *in the documentation* link on the *no variants* screen,
>    I get redirected correcly, but it takes a while for the images to load and
>    it pushes the content away and I lose track where was the help I came for.
>    I would suggest to set the dimensions into the <img> tags therefore it will
>    not push the screen away, but simply load into the empty space.
>
> This is aerogear.org bug, could you report that?

>
>    - Each time the user wants to do a destructive action (i.e. *deleting
>    application*, *deleting variant*,*reseting master secret*) he should
>    be presented with a dialog in which he would have to type the name of the
>    *variant*or *application* in order to continue. This was already in
>    before and I am not sure why was it removed.
>
>  We have discussed this with Andres and he believes it is unnecessary from
UX PoV: clicking big red button should be enough. :-)

But since this is re-occuring report to the new UI, we should probably
rethink that and introduce confirmation back.

> Questions
>
>    - I am not sure what *x receivers / y opened* means as well as the
>    meaning of *first time opened* and*last time opened*.
>    - Is there a way to access the list of registered installations as it
>    was before? Should it?
>    - In analytics there are *Push opens* statistics. Does that mean there
>    is some new API in UnifiedPush Server? If so should we test it? If so how?
>
> Yes, all these are related to the new Analytics - push notification sent
to devices / devices opened metric.

> One more thing
>
> It would be great if we implemented documentation versioning similar to
> readthedocs.org <http://www.readthedocs.org/>. That way there could be
> more versions of the documentation hosted on the aerogear.org
> <http://www.aerogear.org/> site and each version of UnifiedPush Server
> Admin UI could point to the specific version. It would lead to better user
> experience because they would see the documentation exactly for their
> version.
>

Something what we could consider is hosting generated documentation in
version-prefixed directories, such as here:
http://docs.jboss.org/richfaces/

This is probably worth separated thread.


> All taken into consideration the team did a great job on the 1.1.0 and
> even though it is still just beta.1, it is working very well. Thanks guys!
>
> PS: Sorry for the order of images, it is 3 am and I was too tired to
> reorganize them. Also I did not yet create any JIRA tickets for the bugs. I
> just wanted to share the report with you guys so we can discuss which of
> the items will be moved into the JIRA as tickets and which are not
> important or would me marked as "won't fix".
>


@Tadeas: could I ask you to report the bugs in one or two JIRAs (+ JIRAs
specific to aerogear.org, such as page scrolling issue)? Let's report them
in a bulk and assigned to me, I will split them as necessary into subtasks.

> Thanks,
> Tadeas Kriz
>
> 1 -
> https://lh5.googleusercontent.com/-OHKxiXEIT88/VV6DvB0uRKI/AAAAAAAAX5I/a-m6umCfZUo/w593-h758-no/Screen%2BShot%2B2015-05-22%2Bat%2B12.14.05%2Bam.png
> 2 -
> https://lh5.googleusercontent.com/-KzruF4kzwj4/VV6Dyuu1kxI/AAAAAAAAX5o/RFuCFGzxtXo/w1192-h512-no/Screen%2BShot%2B2015-05-22%2Bat%2B1.27.53%2Bam.png
> 3 -
> https://lh6.googleusercontent.com/-ZAlJzi51BX0/VV6Dx1J3SxI/AAAAAAAAX5k/UQiql9TMye4/w1187-h571-no/Screen%2BShot%2B2015-05-22%2Bat%2B1.27.58%2Bam.png
> 4 -
> https://lh6.googleusercontent.com/-LHyvZPW5AzI/VV6DxSuf-yI/AAAAAAAAX5c/bi9eJaQ6RLc/w1199-h491-no/Screen%2BShot%2B2015-05-22%2Bat%2B1.28.04%2Bam.png
> 5 -
> https://lh6.googleusercontent.com/-A-dpKMM4IcU/VV6D1WjHp5I/AAAAAAAAX54/XeQC-2KUqVg/w373-h146-no/Screen%2BShot%2B2015-05-22%2Bat%2B1.12.15%2Bam.png
> 6 -
> https://lh3.googleusercontent.com/-dU4Weqwf5as/VV6D2OFf-II/AAAAAAAAX6A/T5CDLREzT-w/w277-h83-no/Screen%2BShot%2B2015-05-22%2Bat%2B1.09.51%2Bam.png
> 7 -
> https://lh5.googleusercontent.com/-q_0F21tJZgo/VV6Dz4jZJPI/AAAAAAAAX5w/ngGABCT_AUM/w320-h316-no/Screen%2BShot%2B2015-05-22%2Bat%2B1.19.53%2Bam.png
> 8 -
> https://lh5.googleusercontent.com/-57qlJTvJEBI/VV6Dwg3i0SI/AAAAAAAAX5Q/KPQxgw1DS0w/w644-h63-no/Screen%2BShot%2B2015-05-22%2Bat%2B1.28.56%2Bam.png
>
>
> On Thu, May 21, 2015 at 11:39 PM, Tadeas Kriz <tkriz at redhat.com> wrote:
>
>> Hey,
>>
>> I've just run integration tests and the UnifiedPush Server works great.
>> One huge downside is the change that breaks the API of Java Sender and that
>> the API is currently in somehow inconsistent state (it is synchronous, but
>> it uses callback to deliver the `success` state and throws exception to
>> deliver the `failed` state).
>>
>> Now I'm going to proceed with the real-device testing.
>>
>> On Thu, May 21, 2015 at 10:33 PM, Matthias Wessendorf <matzew at apache.org>
>> wrote:
>>
>>> NEVERMIND, see
>>> https://github.com/aerogear/aerogear-unifiedpush-server/pull/568 for
>>> details
>>>
>>> staging stays, and we continue w/ 1.1.0 of Keycloak
>>>
>>> On Thu, May 21, 2015 at 10:18 PM, Matthias Wessendorf <matzew at apache.org
>>> > wrote:
>>>
>>>> please give it a spin, so that I can merege it, in order to actually do
>>>> the re-staging
>>>>
>>>> On Thu, May 21, 2015 at 10:15 PM, Matthias Wessendorf <
>>>> mwessendorf at gmail.com> wrote:
>>>>
>>>>> we need to re-stage, due to this bug:
>>>>> https://github.com/aerogear/aerogear-unifiedpush-server/pull/568
>>>>>
>>>>> On Thu, May 21, 2015 at 9:21 PM, Matthias Wessendorf <
>>>>> mwessendorf at gmail.com> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> after month of work, here is the first beta release for the UPS
>>>>>> 1.1.0. It contains more features and inprovements around UI, JMS for
>>>>>> enhanced scalability and a lot of other stuff:
>>>>>> https://issues.jboss.org/browse/AGPUSH/fixforversion/12326579
>>>>>>
>>>>>>
>>>>>> Please test the staged release:
>>>>>>
>>>>>> https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-5605/
>>>>>>
>>>>>> Like w/ the previous alpha.2, please make sure you use a full profile
>>>>>> WildFly or EAP server for tests, since we now have JMS hooks ;-)
>>>>>> (See README for details)
>>>>>>
>>>>>> On Wednesday I'd like to press the button to release it to the wild.
>>>>>>
>>>>>> PS: Since this is the first beta release we won't yet be updating our
>>>>>> Openshift cartridge - that will stay on 1.0.3 (stable) for a little longer
>>>>>> time. For the next release (beta.2) in a few weeks we may get to this
>>>>>> Openshift update.
>>>>>>
>>>>>> Thanks,
>>>>>> Matthias
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> 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
>>>>
>>>
>>>
>>>
>>> --
>>> Matthias Wessendorf
>>>
>>> blog: http://matthiaswessendorf.wordpress.com/
>>> sessions: http://www.slideshare.net/mwessendorf
>>> twitter: http://twitter.com/mwessendorf
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>
>>
>>
>> --
>> --
>> Tadeas Kriz
>>
>
>
>
> --
> --
> Tadeas Kriz
>
> _______________________________________________
> 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/20150522/ac8ab91a/attachment-0001.html 

From bruno at abstractj.org  Mon May 25 10:38:14 2015
From: bruno at abstractj.org (Bruno Oliveira)
Date: Mon, 25 May 2015 11:38:14 -0300
Subject: [aerogear-dev] What's new in AeroGear (25th May)
Message-ID: <CAM5SUC4wwjx0RfVAzTx+O1E8GuEp3=EC+0HM7QBX-MJNKemk0g@mail.gmail.com>

Happy holidays for those around the world!

*Android*

Push analytics[1] was merged, we will release a new version this week

[1] https://github.com/aerogear/aerogear-android-push/pull/36

*For iOS lovers*

As promised, last week focuses on providing push anlaytics in ObjC for
aerogear-ios-push.

For *Swift* see
https://github.com/aerogear/aerogear-ios-push/tree/1.1.0-beta.1-swift

For *ObjC* https://github.com/aerogear/aerogear-ios-push/tree/1.1.0-beta.1

*Push*

UnifiedPush Server 1.1.0-beta-1 was staged:

https://github.com/aerogear/aerogear-unifiedpush-server/releases


-- 

-- 
"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/20150525/e08f3bc8/attachment.html 

From delalis at gmail.com  Mon May 25 15:26:46 2015
From: delalis at gmail.com (delalis)
Date: Mon, 25 May 2015 12:26:46 -0700 (MST)
Subject: [aerogear-dev] aerogear UPS - deploy failed - wildfly - java 1.8_45
Message-ID: <1432582006466-11674.post@n5.nabble.com>

hey all, can anyone help me with this error:
https://gist.github.com/delalis/7364801a0c26fdc31454

 trying to set up aerogear on Wildfly, deploying the war files causes this
"Unsupported major.minor version 51.0"

java runtime is 1.8_45 (latest)

 but perhaps the version supported/expected by the war is older?


  been following the 4 steps:
https://aerogear.org/docs/unifiedpush/ups_userguide/index/#server-installation


windows 7 environment






--
View this message in context: http://aerogear-dev.1069024.n5.nabble.com/aerogear-UPS-deploy-failed-wildfly-java-1-8-45-tp11674.html
Sent from the aerogear-dev mailing list archive at Nabble.com.

From delalis at gmail.com  Mon May 25 17:46:35 2015
From: delalis at gmail.com (delalis)
Date: Mon, 25 May 2015 14:46:35 -0700 (MST)
Subject: [aerogear-dev] aerogear UPS - deploy failed - wildfly - java
	1.8_45
In-Reply-To: <1432582006466-11674.post@n5.nabble.com>
References: <1432582006466-11674.post@n5.nabble.com>
Message-ID: <1432590395831-11675.post@n5.nabble.com>

Looks like it just wasnt compatible with java 1.8, used java 1.7 and the war
files deployed.



--
View this message in context: http://aerogear-dev.1069024.n5.nabble.com/aerogear-UPS-deploy-failed-wildfly-java-1-8-45-tp11674p11675.html
Sent from the aerogear-dev mailing list archive at Nabble.com.

From matzew at apache.org  Tue May 26 03:02:27 2015
From: matzew at apache.org (Matthias Wessendorf)
Date: Tue, 26 May 2015 09:02:27 +0200
Subject: [aerogear-dev] aerogear UPS - deploy failed - wildfly - java
	1.8_45
In-Reply-To: <1432590395831-11675.post@n5.nabble.com>
References: <1432582006466-11674.post@n5.nabble.com>
	<1432590395831-11675.post@n5.nabble.com>
Message-ID: <CAAg5f2Twt+tHmfbytR2nPehmXNh-NMmDBtyqNZHZhjs30TSPKg@mail.gmail.com>

yes, atm we build w/ JDK7.
that's likely to change shortly ;-)

On Mon, May 25, 2015 at 11:46 PM, delalis <delalis at gmail.com> wrote:

> Looks like it just wasnt compatible with java 1.8, used java 1.7 and the
> war
> files deployed.
>
>
>
> --
> View this message in context:
> http://aerogear-dev.1069024.n5.nabble.com/aerogear-UPS-deploy-failed-wildfly-java-1-8-45-tp11674p11675.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/20150526/b891c782/attachment.html 

From matzew at apache.org  Tue May 26 04:40:15 2015
From: matzew at apache.org (Matthias Wessendorf)
Date: Tue, 26 May 2015 10:40:15 +0200
Subject: [aerogear-dev] UnifiedPush Server 1.1.0-beta.1
In-Reply-To: <CAEroY35uSYOPWdZ0Xnps-VYtvVfJaWvSW8fXDedn79Qry8Dkxg@mail.gmail.com>
References: <CAAg5f2Rpiq0L0CmvARgc9m_a==rjjLKyMDaADTP00MeL_18oUg@mail.gmail.com>
	<CAAg5f2SvujHDvc8OU_eK-fDJ=r3GoNjuwiJkk1=TpxjSzepgdg@mail.gmail.com>
	<CAAg5f2RcJGPXS24k06Ayt4Ouswhgy1qU-faA6z2NTrRNC=JEtA@mail.gmail.com>
	<CAAg5f2Tf1b5EA3N7+Zg4Mamrvc9p4vGuWjmV_=aJEuGw5E7qTA@mail.gmail.com>
	<CAJ0HFMAQaEue=mW6+eKvR1V9B4oTH86MO3yb41sbvi-T4pyfwg@mail.gmail.com>
	<CAJ0HFMDLVz8oY9TH7YVCK+a85vLG=xFC=quRADbjv4Mpf4HQhA@mail.gmail.com>
	<CAEroY35uSYOPWdZ0Xnps-VYtvVfJaWvSW8fXDedn79Qry8Dkxg@mail.gmail.com>
Message-ID: <CAAg5f2Q=zbNjzZ8Ufk3f6aH3OCBaA36vJE5h2+7J+_WFj7ZCuw@mail.gmail.com>

Hi,

thanks for the testing. Looks like we are good to go w/ the beta.1 release.
Like Lukas already asked, are you able to create a few JIRAs to capture the
issues on the UI ?

Thanks

On Fri, May 22, 2015 at 1:30 PM, Luk?? Fry? <lukas.fryc at gmail.com> wrote:

> Thanks Tadeas,
>
> that's wonderful feedback!
>
> On Fri, May 22, 2015 at 3:24 AM, Tadeas Kriz <tkriz at redhat.com> wrote:
>
>> UnifiedPush Server 1.1.0-beta.1 testing report
>>
>> Hello there again,
>>
>> so I have tested the UPS using the UI console, iOS 8.0 and Android 5.1. I
>> have used the HelloPush example as to me it seems the best for testing the
>> server and messaging.
>>
>> I have not tested the Windows, SimplePush and Amazon. The Simple Push was
>> tested in the automated integration tests, but that does not apply for
>> Windows and Amazon as we do not have the test cases for those. I also could
>> not test them manually because I do not have Windows nor Amazon developer
>> accounts.
>>
>> I have tortured the Admin UI quite thoroughly and it did really well.
>> There were some bugs and some UX quirks that I suggest we fix into the next
>> beta release.
>> Kudos for:
>>
>>    - Absolutely f***ing awesome wizard in the UnifiedPush Server Admin
>>    UI. I have loved every step of it and what totally amazed me was that when
>>    I deployed the app on the device and the app registered itself to the UPS,
>>    the wizard automagically progreessed to the next step! That is so damn
>>    awesome and the UX is just wonderful.
>>       - It was so great that I (as a user) would not mind if it was
>>       shown also when creating another variants in an application that already
>>       has some, because it makes it more friendly and gives the feedback when the
>>       first registration is successful.
>>    - It is also great that the user does not need to click on a link to
>>    keep logged in and only focusing the window is enough. Thanks for that.
>>    - iOS HelloPush example is Swift 1.2 ready!
>>    - Very nice error reporting in iOS HelloPush example (I set the URL
>>    wrong and the app told me about registration issue)
>>
>> Found bugs
>>
>>    -
>>
>>    When sending push message using the UI, the following can happen:
>>    1. Check one or more variants in the variants list
>>       2. Uncheck all of the variants (this will leave you in the same
>>       visual state as it was before step 1.)
>>       3. Send the message
>>       4. Wonder why it was not sent to any of the devices
>>
>>    It seems that when I open the dialog, it shows *No variants*, but it
>>    really means *All variants*. However when I check some variants and
>>    then uncheck them all, it will still say *No variants*, but now it
>>    really means it as *No variants*. My suggestion is to start with
>>    having all the variants checked and instead of listing them all separated
>>    by commas, we should show*All variants*.
>>    -
>>
>>    For some strange reason there is a lot of space in the bottom and I
>>    can scroll away all the content.
>>    - There are *?* help icons/buttons in the lower-right corners [5] in
>>    the analytics panel, but they do not do or show anything.
>>    - In the variant list it still shows *0 delivered*[7] even when I
>>    already sent and delivered messages.
>>    - In *Sender API* tab there is always *Set up Java UPS* on top of the
>>    other sender platform (see [2, 3, 4])
>>    - Clicking the *Read more* about master secret and push app id
>>    security [8] leads to */ag-push/#* (and somehow corrupts the history
>>    and I could not hit back button).
>>    - Search in PushApplication list does not work (and I am not sure if
>>    it is necessary as there should not be that many apps).
>>
>> UI/UX Quirks
>>
>>    - Variant creation dialog wraps text when there is a lot of space [1].
>>    - The area between number of devices and *edit* button shows the
>>    *hand* cursor, but it is not clickable. I would suggest to make it
>>    clickable and the action would be expanding/collapsing the variant detail.
>>    - The *+*/*-* button for expanding/collapsing the statistics does not
>>    show *hand* cursor when mouse is above it.
>>    - In the top right corner of the window, there is the *warnings* information,
>>    however it is strange when there are no warnings so I would suggest one of
>>    these:
>>       1. Do not show it in the bar altogether when there are no warnings
>>       2. Disable the *clickability* of it when there are no warnings
>>       3. When the popup is shown, it should not be just an empty box[6],
>>       but should show something like *No warnings*
>>    - When hitting the *Edit* variant button, it shows a dialog where I
>>    can change only the name of the variant. However when I click the*Change
>>    network options* button, I am presented with the possibility to
>>    change both the name of the variant and the network specific configuration.
>>    I would therefore suggest to not show the name field in the *Change
>>    network options* dialog as it is not considered a good practise to
>>    have two ways of doing the same thing in UI.
>>    - It is a bit strange that when I hover over the *copy* (sources) in
>>    variant detail, the *edit* and delete buttons disappear until I move
>>    the mouse away from the *copy*.
>>    - Links to *Android*, *Chrome*, *iOS*, *Cordova* etc. in variant
>>    detail should open the documentation in a new tab like the rest of
>>    documentation links. Now it opens in the same app which is not good because
>>    the user wants to stay in the Admin UI.
>>    - When I click on the *in the documentation* link on the *no variants* screen,
>>    I get redirected correcly, but it takes a while for the images to load and
>>    it pushes the content away and I lose track where was the help I came for.
>>    I would suggest to set the dimensions into the <img> tags therefore it will
>>    not push the screen away, but simply load into the empty space.
>>
>> This is aerogear.org bug, could you report that?
>
>>
>>    - Each time the user wants to do a destructive action (i.e. *deleting
>>    application*, *deleting variant*,*reseting master secret*) he should
>>    be presented with a dialog in which he would have to type the name of the
>>    *variant*or *application* in order to continue. This was already in
>>    before and I am not sure why was it removed.
>>
>>  We have discussed this with Andres and he believes it is unnecessary
> from UX PoV: clicking big red button should be enough. :-)
>
> But since this is re-occuring report to the new UI, we should probably
> rethink that and introduce confirmation back.
>
>> Questions
>>
>>    - I am not sure what *x receivers / y opened* means as well as the
>>    meaning of *first time opened* and*last time opened*.
>>    - Is there a way to access the list of registered installations as it
>>    was before? Should it?
>>    - In analytics there are *Push opens* statistics. Does that mean
>>    there is some new API in UnifiedPush Server? If so should we test it? If so
>>    how?
>>
>> Yes, all these are related to the new Analytics - push notification sent
> to devices / devices opened metric.
>
>> One more thing
>>
>> It would be great if we implemented documentation versioning similar to
>> readthedocs.org <http://www.readthedocs.org/>. That way there could be
>> more versions of the documentation hosted on the aerogear.org
>> <http://www.aerogear.org/> site and each version of UnifiedPush Server
>> Admin UI could point to the specific version. It would lead to better user
>> experience because they would see the documentation exactly for their
>> version.
>>
>
> Something what we could consider is hosting generated documentation in
> version-prefixed directories, such as here:
> http://docs.jboss.org/richfaces/
>
> This is probably worth separated thread.
>
>
>> All taken into consideration the team did a great job on the 1.1.0 and
>> even though it is still just beta.1, it is working very well. Thanks guys!
>>
>> PS: Sorry for the order of images, it is 3 am and I was too tired to
>> reorganize them. Also I did not yet create any JIRA tickets for the bugs. I
>> just wanted to share the report with you guys so we can discuss which of
>> the items will be moved into the JIRA as tickets and which are not
>> important or would me marked as "won't fix".
>>
>
>
> @Tadeas: could I ask you to report the bugs in one or two JIRAs (+ JIRAs
> specific to aerogear.org, such as page scrolling issue)? Let's report
> them in a bulk and assigned to me, I will split them as necessary into
> subtasks.
>
>> Thanks,
>> Tadeas Kriz
>>
>> 1 -
>> https://lh5.googleusercontent.com/-OHKxiXEIT88/VV6DvB0uRKI/AAAAAAAAX5I/a-m6umCfZUo/w593-h758-no/Screen%2BShot%2B2015-05-22%2Bat%2B12.14.05%2Bam.png
>> 2 -
>> https://lh5.googleusercontent.com/-KzruF4kzwj4/VV6Dyuu1kxI/AAAAAAAAX5o/RFuCFGzxtXo/w1192-h512-no/Screen%2BShot%2B2015-05-22%2Bat%2B1.27.53%2Bam.png
>> 3 -
>> https://lh6.googleusercontent.com/-ZAlJzi51BX0/VV6Dx1J3SxI/AAAAAAAAX5k/UQiql9TMye4/w1187-h571-no/Screen%2BShot%2B2015-05-22%2Bat%2B1.27.58%2Bam.png
>> 4 -
>> https://lh6.googleusercontent.com/-LHyvZPW5AzI/VV6DxSuf-yI/AAAAAAAAX5c/bi9eJaQ6RLc/w1199-h491-no/Screen%2BShot%2B2015-05-22%2Bat%2B1.28.04%2Bam.png
>> 5 -
>> https://lh6.googleusercontent.com/-A-dpKMM4IcU/VV6D1WjHp5I/AAAAAAAAX54/XeQC-2KUqVg/w373-h146-no/Screen%2BShot%2B2015-05-22%2Bat%2B1.12.15%2Bam.png
>> 6 -
>> https://lh3.googleusercontent.com/-dU4Weqwf5as/VV6D2OFf-II/AAAAAAAAX6A/T5CDLREzT-w/w277-h83-no/Screen%2BShot%2B2015-05-22%2Bat%2B1.09.51%2Bam.png
>> 7 -
>> https://lh5.googleusercontent.com/-q_0F21tJZgo/VV6Dz4jZJPI/AAAAAAAAX5w/ngGABCT_AUM/w320-h316-no/Screen%2BShot%2B2015-05-22%2Bat%2B1.19.53%2Bam.png
>> 8 -
>> https://lh5.googleusercontent.com/-57qlJTvJEBI/VV6Dwg3i0SI/AAAAAAAAX5Q/KPQxgw1DS0w/w644-h63-no/Screen%2BShot%2B2015-05-22%2Bat%2B1.28.56%2Bam.png
>>
>>
>> On Thu, May 21, 2015 at 11:39 PM, Tadeas Kriz <tkriz at redhat.com> wrote:
>>
>>> Hey,
>>>
>>> I've just run integration tests and the UnifiedPush Server works great.
>>> One huge downside is the change that breaks the API of Java Sender and that
>>> the API is currently in somehow inconsistent state (it is synchronous, but
>>> it uses callback to deliver the `success` state and throws exception to
>>> deliver the `failed` state).
>>>
>>> Now I'm going to proceed with the real-device testing.
>>>
>>> On Thu, May 21, 2015 at 10:33 PM, Matthias Wessendorf <matzew at apache.org
>>> > wrote:
>>>
>>>> NEVERMIND, see
>>>> https://github.com/aerogear/aerogear-unifiedpush-server/pull/568 for
>>>> details
>>>>
>>>> staging stays, and we continue w/ 1.1.0 of Keycloak
>>>>
>>>> On Thu, May 21, 2015 at 10:18 PM, Matthias Wessendorf <
>>>> matzew at apache.org> wrote:
>>>>
>>>>> please give it a spin, so that I can merege it, in order to actually
>>>>> do the re-staging
>>>>>
>>>>> On Thu, May 21, 2015 at 10:15 PM, Matthias Wessendorf <
>>>>> mwessendorf at gmail.com> wrote:
>>>>>
>>>>>> we need to re-stage, due to this bug:
>>>>>> https://github.com/aerogear/aerogear-unifiedpush-server/pull/568
>>>>>>
>>>>>> On Thu, May 21, 2015 at 9:21 PM, Matthias Wessendorf <
>>>>>> mwessendorf at gmail.com> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> after month of work, here is the first beta release for the UPS
>>>>>>> 1.1.0. It contains more features and inprovements around UI, JMS for
>>>>>>> enhanced scalability and a lot of other stuff:
>>>>>>> https://issues.jboss.org/browse/AGPUSH/fixforversion/12326579
>>>>>>>
>>>>>>>
>>>>>>> Please test the staged release:
>>>>>>>
>>>>>>> https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-5605/
>>>>>>>
>>>>>>> Like w/ the previous alpha.2, please make sure you use a full
>>>>>>> profile WildFly or EAP server for tests, since we now have JMS hooks ;-)
>>>>>>> (See README for details)
>>>>>>>
>>>>>>> On Wednesday I'd like to press the button to release it to the wild.
>>>>>>>
>>>>>>> PS: Since this is the first beta release we won't yet be updating
>>>>>>> our Openshift cartridge - that will stay on 1.0.3 (stable) for a little
>>>>>>> longer time. For the next release (beta.2) in a few weeks we may get to
>>>>>>> this Openshift update.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Matthias
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> 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
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Matthias Wessendorf
>>>>
>>>> blog: http://matthiaswessendorf.wordpress.com/
>>>> sessions: http://www.slideshare.net/mwessendorf
>>>> twitter: http://twitter.com/mwessendorf
>>>>
>>>> _______________________________________________
>>>> aerogear-dev mailing list
>>>> aerogear-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>
>>>
>>>
>>>
>>> --
>>> --
>>> Tadeas Kriz
>>>
>>
>>
>>
>> --
>> --
>> Tadeas Kriz
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.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/20150526/e5674bd5/attachment-0001.html 

From lukas at fryc.eu  Tue May 26 07:58:38 2015
From: lukas at fryc.eu (=?UTF-8?B?THVrw6HFoSBGcnnEjQ==?=)
Date: Tue, 26 May 2015 13:58:38 +0200
Subject: [aerogear-dev] Versioning Documentation
Message-ID: <CAEroY35p9_G5U_bV-vZSYOc4Fzdfv4JiSYpx_PMt1WAPbKBRiA@mail.gmail.com>

Hey guys,

Tadeas started a discussion about versioning documentation in the thread
[1],


and I must agree - it is a good idea to version documentation (and possibly
also guides),

especially since our UPS Console now points from the UI to the
documentation -
that is a great feature but I'm worried about maintanance of that solution,
a documentation tend to change in time, with links no longer being valid.


Lot of projects publish generated documentation separately, hosting it e.g.
on docs.jboss.org (see [2] for a sample).

I'd suggest to version both, API documentation and guides on a separated
server.
Perhaps we could version whole site?



WDYT?


Cheers,

~ Lukas

[1]
http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-UnifiedPush-Server-1-1-0-beta-1-tp11665p11672.html
[2] http://docs.jboss.org/richfaces/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20150526/3cad8d14/attachment.html 

From supittma at redhat.com  Tue May 26 08:25:37 2015
From: supittma at redhat.com (Summers Pittman)
Date: Tue, 26 May 2015 08:25:37 -0400
Subject: [aerogear-dev] Versioning Documentation
In-Reply-To: <CAEroY35p9_G5U_bV-vZSYOc4Fzdfv4JiSYpx_PMt1WAPbKBRiA@mail.gmail.com>
References: <CAEroY35p9_G5U_bV-vZSYOc4Fzdfv4JiSYpx_PMt1WAPbKBRiA@mail.gmail.com>
Message-ID: <CAEQz2CtExXgXKR8TNdkCXJ=+fQqh9sif6H5BaEUpPbhUF5+vyQ@mail.gmail.com>

Is there a jekyll plugin that lets us link on the page to the files github
commit history?  Would be very easy to do and hopefully we can show tags
and things too.

On Tue, May 26, 2015 at 7:58 AM, Luk?? Fry? <lukas at fryc.eu> wrote:

> Hey guys,
>
> Tadeas started a discussion about versioning documentation in the thread
> [1],
>
>
> and I must agree - it is a good idea to version documentation (and
> possibly also guides),
>
> especially since our UPS Console now points from the UI to the
> documentation -
> that is a great feature but I'm worried about maintanance of that
> solution, a documentation tend to change in time, with links no longer
> being valid.
>
>
> Lot of projects publish generated documentation separately, hosting it
> e.g. on docs.jboss.org (see [2] for a sample).
>
> I'd suggest to version both, API documentation and guides on a separated
> server.
> Perhaps we could version whole site?
>
>
>
> WDYT?
>
>
> Cheers,
>
> ~ Lukas
>
> [1]
> http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-UnifiedPush-Server-1-1-0-beta-1-tp11665p11672.html
> [2] http://docs.jboss.org/richfaces/
>
> _______________________________________________
> 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/20150526/40ef2970/attachment.html 

From lukas.fryc at gmail.com  Tue May 26 08:37:33 2015
From: lukas.fryc at gmail.com (=?UTF-8?B?THVrw6HFoSBGcnnEjQ==?=)
Date: Tue, 26 May 2015 14:37:33 +0200
Subject: [aerogear-dev] UnifiedPush Server 1.1.0-beta.1
In-Reply-To: <CAAg5f2Q=zbNjzZ8Ufk3f6aH3OCBaA36vJE5h2+7J+_WFj7ZCuw@mail.gmail.com>
References: <CAAg5f2Rpiq0L0CmvARgc9m_a==rjjLKyMDaADTP00MeL_18oUg@mail.gmail.com>
	<CAAg5f2SvujHDvc8OU_eK-fDJ=r3GoNjuwiJkk1=TpxjSzepgdg@mail.gmail.com>
	<CAAg5f2RcJGPXS24k06Ayt4Ouswhgy1qU-faA6z2NTrRNC=JEtA@mail.gmail.com>
	<CAAg5f2Tf1b5EA3N7+Zg4Mamrvc9p4vGuWjmV_=aJEuGw5E7qTA@mail.gmail.com>
	<CAJ0HFMAQaEue=mW6+eKvR1V9B4oTH86MO3yb41sbvi-T4pyfwg@mail.gmail.com>
	<CAJ0HFMDLVz8oY9TH7YVCK+a85vLG=xFC=quRADbjv4Mpf4HQhA@mail.gmail.com>
	<CAEroY35uSYOPWdZ0Xnps-VYtvVfJaWvSW8fXDedn79Qry8Dkxg@mail.gmail.com>
	<CAAg5f2Q=zbNjzZ8Ufk3f6aH3OCBaA36vJE5h2+7J+_WFj7ZCuw@mail.gmail.com>
Message-ID: <CAEroY378zrTUG9icrFvZT+9V+pnOE7iuL4t9SEanTCnFDuYriA@mail.gmail.com>

Hey Tadeas,

as agreed on the IRC, I have opened these jiras:

https://issues.jboss.org/browse/AGPUSH-1423 UPS Console: bulk of Admin
UI/UX issues
https://issues.jboss.org/browse/AGPUSH-1421 UPS Console: re-introduce
double-check confirmation for app/variant remove/secret-reset
https://issues.jboss.org/browse/AGPUSH-1422 Describe test spec for testing
new Push Opened Analytics feature


Cheers,

~ Lukas

On Tue, May 26, 2015 at 10:40 AM, Matthias Wessendorf <matzew at apache.org>
wrote:

> Hi,
>
> thanks for the testing. Looks like we are good to go w/ the beta.1 release.
> Like Lukas already asked, are you able to create a few JIRAs to capture
> the issues on the UI ?
>
> Thanks
>
> On Fri, May 22, 2015 at 1:30 PM, Luk?? Fry? <lukas.fryc at gmail.com> wrote:
>
>> Thanks Tadeas,
>>
>> that's wonderful feedback!
>>
>> On Fri, May 22, 2015 at 3:24 AM, Tadeas Kriz <tkriz at redhat.com> wrote:
>>
>>> UnifiedPush Server 1.1.0-beta.1 testing report
>>>
>>> Hello there again,
>>>
>>> so I have tested the UPS using the UI console, iOS 8.0 and Android 5.1.
>>> I have used the HelloPush example as to me it seems the best for testing
>>> the server and messaging.
>>>
>>> I have not tested the Windows, SimplePush and Amazon. The Simple Push
>>> was tested in the automated integration tests, but that does not apply for
>>> Windows and Amazon as we do not have the test cases for those. I also could
>>> not test them manually because I do not have Windows nor Amazon developer
>>> accounts.
>>>
>>> I have tortured the Admin UI quite thoroughly and it did really well.
>>> There were some bugs and some UX quirks that I suggest we fix into the next
>>> beta release.
>>> Kudos for:
>>>
>>>    - Absolutely f***ing awesome wizard in the UnifiedPush Server Admin
>>>    UI. I have loved every step of it and what totally amazed me was that when
>>>    I deployed the app on the device and the app registered itself to the UPS,
>>>    the wizard automagically progreessed to the next step! That is so damn
>>>    awesome and the UX is just wonderful.
>>>       - It was so great that I (as a user) would not mind if it was
>>>       shown also when creating another variants in an application that already
>>>       has some, because it makes it more friendly and gives the feedback when the
>>>       first registration is successful.
>>>    - It is also great that the user does not need to click on a link to
>>>    keep logged in and only focusing the window is enough. Thanks for that.
>>>    - iOS HelloPush example is Swift 1.2 ready!
>>>    - Very nice error reporting in iOS HelloPush example (I set the URL
>>>    wrong and the app told me about registration issue)
>>>
>>> Found bugs
>>>
>>>    -
>>>
>>>    When sending push message using the UI, the following can happen:
>>>    1. Check one or more variants in the variants list
>>>       2. Uncheck all of the variants (this will leave you in the same
>>>       visual state as it was before step 1.)
>>>       3. Send the message
>>>       4. Wonder why it was not sent to any of the devices
>>>
>>>    It seems that when I open the dialog, it shows *No variants*, but it
>>>    really means *All variants*. However when I check some variants and
>>>    then uncheck them all, it will still say *No variants*, but now it
>>>    really means it as *No variants*. My suggestion is to start with
>>>    having all the variants checked and instead of listing them all separated
>>>    by commas, we should show*All variants*.
>>>    -
>>>
>>>    For some strange reason there is a lot of space in the bottom and I
>>>    can scroll away all the content.
>>>    - There are *?* help icons/buttons in the lower-right corners [5] in
>>>    the analytics panel, but they do not do or show anything.
>>>    - In the variant list it still shows *0 delivered*[7] even when I
>>>    already sent and delivered messages.
>>>    - In *Sender API* tab there is always *Set up Java UPS* on top of
>>>    the other sender platform (see [2, 3, 4])
>>>    - Clicking the *Read more* about master secret and push app id
>>>    security [8] leads to */ag-push/#* (and somehow corrupts the history
>>>    and I could not hit back button).
>>>    - Search in PushApplication list does not work (and I am not sure if
>>>    it is necessary as there should not be that many apps).
>>>
>>> UI/UX Quirks
>>>
>>>    - Variant creation dialog wraps text when there is a lot of space
>>>    [1].
>>>    - The area between number of devices and *edit* button shows the
>>>    *hand* cursor, but it is not clickable. I would suggest to make it
>>>    clickable and the action would be expanding/collapsing the variant detail.
>>>    - The *+*/*-* button for expanding/collapsing the statistics does
>>>    not show *hand* cursor when mouse is above it.
>>>    - In the top right corner of the window, there is the *warnings* information,
>>>    however it is strange when there are no warnings so I would suggest one of
>>>    these:
>>>       1. Do not show it in the bar altogether when there are no warnings
>>>       2. Disable the *clickability* of it when there are no warnings
>>>       3. When the popup is shown, it should not be just an empty
>>>       box[6], but should show something like *No warnings*
>>>    - When hitting the *Edit* variant button, it shows a dialog where I
>>>    can change only the name of the variant. However when I click the*Change
>>>    network options* button, I am presented with the possibility to
>>>    change both the name of the variant and the network specific configuration.
>>>    I would therefore suggest to not show the name field in the *Change
>>>    network options* dialog as it is not considered a good practise to
>>>    have two ways of doing the same thing in UI.
>>>    - It is a bit strange that when I hover over the *copy* (sources) in
>>>    variant detail, the *edit* and delete buttons disappear until I move
>>>    the mouse away from the *copy*.
>>>    - Links to *Android*, *Chrome*, *iOS*, *Cordova* etc. in variant
>>>    detail should open the documentation in a new tab like the rest of
>>>    documentation links. Now it opens in the same app which is not good because
>>>    the user wants to stay in the Admin UI.
>>>    - When I click on the *in the documentation* link on the *no
>>>    variants* screen, I get redirected correcly, but it takes a while
>>>    for the images to load and it pushes the content away and I lose track
>>>    where was the help I came for. I would suggest to set the dimensions into
>>>    the <img> tags therefore it will not push the screen away, but simply load
>>>    into the empty space.
>>>
>>> This is aerogear.org bug, could you report that?
>>
>>>
>>>    - Each time the user wants to do a destructive action (i.e. *deleting
>>>    application*, *deleting variant*,*reseting master secret*) he should
>>>    be presented with a dialog in which he would have to type the name of the
>>>    *variant*or *application* in order to continue. This was already in
>>>    before and I am not sure why was it removed.
>>>
>>>  We have discussed this with Andres and he believes it is unnecessary
>> from UX PoV: clicking big red button should be enough. :-)
>>
>> But since this is re-occuring report to the new UI, we should probably
>> rethink that and introduce confirmation back.
>>
>>> Questions
>>>
>>>    - I am not sure what *x receivers / y opened* means as well as the
>>>    meaning of *first time opened* and*last time opened*.
>>>    - Is there a way to access the list of registered installations as
>>>    it was before? Should it?
>>>    - In analytics there are *Push opens* statistics. Does that mean
>>>    there is some new API in UnifiedPush Server? If so should we test it? If so
>>>    how?
>>>
>>> Yes, all these are related to the new Analytics - push notification sent
>> to devices / devices opened metric.
>>
>>> One more thing
>>>
>>> It would be great if we implemented documentation versioning similar to
>>> readthedocs.org <http://www.readthedocs.org/>. That way there could be
>>> more versions of the documentation hosted on the aerogear.org
>>> <http://www.aerogear.org/> site and each version of UnifiedPush Server
>>> Admin UI could point to the specific version. It would lead to better user
>>> experience because they would see the documentation exactly for their
>>> version.
>>>
>>
>> Something what we could consider is hosting generated documentation in
>> version-prefixed directories, such as here:
>> http://docs.jboss.org/richfaces/
>>
>> This is probably worth separated thread.
>>
>>
>>> All taken into consideration the team did a great job on the 1.1.0 and
>>> even though it is still just beta.1, it is working very well. Thanks guys!
>>>
>>> PS: Sorry for the order of images, it is 3 am and I was too tired to
>>> reorganize them. Also I did not yet create any JIRA tickets for the bugs. I
>>> just wanted to share the report with you guys so we can discuss which of
>>> the items will be moved into the JIRA as tickets and which are not
>>> important or would me marked as "won't fix".
>>>
>>
>>
>> @Tadeas: could I ask you to report the bugs in one or two JIRAs (+ JIRAs
>> specific to aerogear.org, such as page scrolling issue)? Let's report
>> them in a bulk and assigned to me, I will split them as necessary into
>> subtasks.
>>
>>> Thanks,
>>> Tadeas Kriz
>>>
>>> 1 -
>>> https://lh5.googleusercontent.com/-OHKxiXEIT88/VV6DvB0uRKI/AAAAAAAAX5I/a-m6umCfZUo/w593-h758-no/Screen%2BShot%2B2015-05-22%2Bat%2B12.14.05%2Bam.png
>>> 2 -
>>> https://lh5.googleusercontent.com/-KzruF4kzwj4/VV6Dyuu1kxI/AAAAAAAAX5o/RFuCFGzxtXo/w1192-h512-no/Screen%2BShot%2B2015-05-22%2Bat%2B1.27.53%2Bam.png
>>> 3 -
>>> https://lh6.googleusercontent.com/-ZAlJzi51BX0/VV6Dx1J3SxI/AAAAAAAAX5k/UQiql9TMye4/w1187-h571-no/Screen%2BShot%2B2015-05-22%2Bat%2B1.27.58%2Bam.png
>>> 4 -
>>> https://lh6.googleusercontent.com/-LHyvZPW5AzI/VV6DxSuf-yI/AAAAAAAAX5c/bi9eJaQ6RLc/w1199-h491-no/Screen%2BShot%2B2015-05-22%2Bat%2B1.28.04%2Bam.png
>>> 5 -
>>> https://lh6.googleusercontent.com/-A-dpKMM4IcU/VV6D1WjHp5I/AAAAAAAAX54/XeQC-2KUqVg/w373-h146-no/Screen%2BShot%2B2015-05-22%2Bat%2B1.12.15%2Bam.png
>>> 6 -
>>> https://lh3.googleusercontent.com/-dU4Weqwf5as/VV6D2OFf-II/AAAAAAAAX6A/T5CDLREzT-w/w277-h83-no/Screen%2BShot%2B2015-05-22%2Bat%2B1.09.51%2Bam.png
>>> 7 -
>>> https://lh5.googleusercontent.com/-q_0F21tJZgo/VV6Dz4jZJPI/AAAAAAAAX5w/ngGABCT_AUM/w320-h316-no/Screen%2BShot%2B2015-05-22%2Bat%2B1.19.53%2Bam.png
>>> 8 -
>>> https://lh5.googleusercontent.com/-57qlJTvJEBI/VV6Dwg3i0SI/AAAAAAAAX5Q/KPQxgw1DS0w/w644-h63-no/Screen%2BShot%2B2015-05-22%2Bat%2B1.28.56%2Bam.png
>>>
>>>
>>> On Thu, May 21, 2015 at 11:39 PM, Tadeas Kriz <tkriz at redhat.com> wrote:
>>>
>>>> Hey,
>>>>
>>>> I've just run integration tests and the UnifiedPush Server works great.
>>>> One huge downside is the change that breaks the API of Java Sender and that
>>>> the API is currently in somehow inconsistent state (it is synchronous, but
>>>> it uses callback to deliver the `success` state and throws exception to
>>>> deliver the `failed` state).
>>>>
>>>> Now I'm going to proceed with the real-device testing.
>>>>
>>>> On Thu, May 21, 2015 at 10:33 PM, Matthias Wessendorf <
>>>> matzew at apache.org> wrote:
>>>>
>>>>> NEVERMIND, see
>>>>> https://github.com/aerogear/aerogear-unifiedpush-server/pull/568 for
>>>>> details
>>>>>
>>>>> staging stays, and we continue w/ 1.1.0 of Keycloak
>>>>>
>>>>> On Thu, May 21, 2015 at 10:18 PM, Matthias Wessendorf <
>>>>> matzew at apache.org> wrote:
>>>>>
>>>>>> please give it a spin, so that I can merege it, in order to actually
>>>>>> do the re-staging
>>>>>>
>>>>>> On Thu, May 21, 2015 at 10:15 PM, Matthias Wessendorf <
>>>>>> mwessendorf at gmail.com> wrote:
>>>>>>
>>>>>>> we need to re-stage, due to this bug:
>>>>>>> https://github.com/aerogear/aerogear-unifiedpush-server/pull/568
>>>>>>>
>>>>>>> On Thu, May 21, 2015 at 9:21 PM, Matthias Wessendorf <
>>>>>>> mwessendorf at gmail.com> wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> after month of work, here is the first beta release for the UPS
>>>>>>>> 1.1.0. It contains more features and inprovements around UI, JMS for
>>>>>>>> enhanced scalability and a lot of other stuff:
>>>>>>>> https://issues.jboss.org/browse/AGPUSH/fixforversion/12326579
>>>>>>>>
>>>>>>>>
>>>>>>>> Please test the staged release:
>>>>>>>>
>>>>>>>> https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-5605/
>>>>>>>>
>>>>>>>> Like w/ the previous alpha.2, please make sure you use a full
>>>>>>>> profile WildFly or EAP server for tests, since we now have JMS hooks ;-)
>>>>>>>> (See README for details)
>>>>>>>>
>>>>>>>> On Wednesday I'd like to press the button to release it to the wild.
>>>>>>>>
>>>>>>>> PS: Since this is the first beta release we won't yet be updating
>>>>>>>> our Openshift cartridge - that will stay on 1.0.3 (stable) for a little
>>>>>>>> longer time. For the next release (beta.2) in a few weeks we may get to
>>>>>>>> this Openshift update.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Matthias
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> 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
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Matthias Wessendorf
>>>>>
>>>>> blog: http://matthiaswessendorf.wordpress.com/
>>>>> sessions: http://www.slideshare.net/mwessendorf
>>>>> twitter: http://twitter.com/mwessendorf
>>>>>
>>>>> _______________________________________________
>>>>> aerogear-dev mailing list
>>>>> aerogear-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> --
>>>> Tadeas Kriz
>>>>
>>>
>>>
>>>
>>> --
>>> --
>>> Tadeas Kriz
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/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/20150526/88fcf1a9/attachment-0001.html 

From tkriz at redhat.com  Tue May 26 08:41:45 2015
From: tkriz at redhat.com (Tadeas Kriz)
Date: Tue, 26 May 2015 14:41:45 +0200
Subject: [aerogear-dev] UnifiedPush Server 1.1.0-beta.1
In-Reply-To: <CAEroY378zrTUG9icrFvZT+9V+pnOE7iuL4t9SEanTCnFDuYriA@mail.gmail.com>
References: <CAAg5f2Rpiq0L0CmvARgc9m_a==rjjLKyMDaADTP00MeL_18oUg@mail.gmail.com>
	<CAAg5f2SvujHDvc8OU_eK-fDJ=r3GoNjuwiJkk1=TpxjSzepgdg@mail.gmail.com>
	<CAAg5f2RcJGPXS24k06Ayt4Ouswhgy1qU-faA6z2NTrRNC=JEtA@mail.gmail.com>
	<CAAg5f2Tf1b5EA3N7+Zg4Mamrvc9p4vGuWjmV_=aJEuGw5E7qTA@mail.gmail.com>
	<CAJ0HFMAQaEue=mW6+eKvR1V9B4oTH86MO3yb41sbvi-T4pyfwg@mail.gmail.com>
	<CAJ0HFMDLVz8oY9TH7YVCK+a85vLG=xFC=quRADbjv4Mpf4HQhA@mail.gmail.com>
	<CAEroY35uSYOPWdZ0Xnps-VYtvVfJaWvSW8fXDedn79Qry8Dkxg@mail.gmail.com>
	<CAAg5f2Q=zbNjzZ8Ufk3f6aH3OCBaA36vJE5h2+7J+_WFj7ZCuw@mail.gmail.com>
	<CAEroY378zrTUG9icrFvZT+9V+pnOE7iuL4t9SEanTCnFDuYriA@mail.gmail.com>
Message-ID: <CAJ0HFMCQxvqZKC0z3xeKyTWczK3Yo+pMDU3r2Bt3=28PHik_hQ@mail.gmail.com>

Thanks Lukas!

On Tue, May 26, 2015 at 2:37 PM, Luk?? Fry? <lukas.fryc at gmail.com> wrote:

> Hey Tadeas,
>
> as agreed on the IRC, I have opened these jiras:
>
> https://issues.jboss.org/browse/AGPUSH-1423 UPS Console: bulk of Admin
> UI/UX issues
> https://issues.jboss.org/browse/AGPUSH-1421 UPS Console: re-introduce
> double-check confirmation for app/variant remove/secret-reset
> https://issues.jboss.org/browse/AGPUSH-1422 Describe test spec for
> testing new Push Opened Analytics feature
>
>
> Cheers,
>
> ~ Lukas
>
> On Tue, May 26, 2015 at 10:40 AM, Matthias Wessendorf <matzew at apache.org>
> wrote:
>
>> Hi,
>>
>> thanks for the testing. Looks like we are good to go w/ the beta.1
>> release.
>> Like Lukas already asked, are you able to create a few JIRAs to capture
>> the issues on the UI ?
>>
>> Thanks
>>
>> On Fri, May 22, 2015 at 1:30 PM, Luk?? Fry? <lukas.fryc at gmail.com> wrote:
>>
>>> Thanks Tadeas,
>>>
>>> that's wonderful feedback!
>>>
>>> On Fri, May 22, 2015 at 3:24 AM, Tadeas Kriz <tkriz at redhat.com> wrote:
>>>
>>>> UnifiedPush Server 1.1.0-beta.1 testing report
>>>>
>>>> Hello there again,
>>>>
>>>> so I have tested the UPS using the UI console, iOS 8.0 and Android 5.1.
>>>> I have used the HelloPush example as to me it seems the best for testing
>>>> the server and messaging.
>>>>
>>>> I have not tested the Windows, SimplePush and Amazon. The Simple Push
>>>> was tested in the automated integration tests, but that does not apply for
>>>> Windows and Amazon as we do not have the test cases for those. I also could
>>>> not test them manually because I do not have Windows nor Amazon developer
>>>> accounts.
>>>>
>>>> I have tortured the Admin UI quite thoroughly and it did really well.
>>>> There were some bugs and some UX quirks that I suggest we fix into the next
>>>> beta release.
>>>> Kudos for:
>>>>
>>>>    - Absolutely f***ing awesome wizard in the UnifiedPush Server Admin
>>>>    UI. I have loved every step of it and what totally amazed me was that when
>>>>    I deployed the app on the device and the app registered itself to the UPS,
>>>>    the wizard automagically progreessed to the next step! That is so damn
>>>>    awesome and the UX is just wonderful.
>>>>       - It was so great that I (as a user) would not mind if it was
>>>>       shown also when creating another variants in an application that already
>>>>       has some, because it makes it more friendly and gives the feedback when the
>>>>       first registration is successful.
>>>>    - It is also great that the user does not need to click on a link
>>>>    to keep logged in and only focusing the window is enough. Thanks for that.
>>>>    - iOS HelloPush example is Swift 1.2 ready!
>>>>    - Very nice error reporting in iOS HelloPush example (I set the URL
>>>>    wrong and the app told me about registration issue)
>>>>
>>>> Found bugs
>>>>
>>>>    -
>>>>
>>>>    When sending push message using the UI, the following can happen:
>>>>    1. Check one or more variants in the variants list
>>>>       2. Uncheck all of the variants (this will leave you in the same
>>>>       visual state as it was before step 1.)
>>>>       3. Send the message
>>>>       4. Wonder why it was not sent to any of the devices
>>>>
>>>>    It seems that when I open the dialog, it shows *No variants*, but
>>>>    it really means *All variants*. However when I check some variants
>>>>    and then uncheck them all, it will still say *No variants*, but now
>>>>    it really means it as *No variants*. My suggestion is to start with
>>>>    having all the variants checked and instead of listing them all separated
>>>>    by commas, we should show*All variants*.
>>>>    -
>>>>
>>>>    For some strange reason there is a lot of space in the bottom and I
>>>>    can scroll away all the content.
>>>>    - There are *?* help icons/buttons in the lower-right corners [5]
>>>>    in the analytics panel, but they do not do or show anything.
>>>>    - In the variant list it still shows *0 delivered*[7] even when I
>>>>    already sent and delivered messages.
>>>>    - In *Sender API* tab there is always *Set up Java UPS* on top of
>>>>    the other sender platform (see [2, 3, 4])
>>>>    - Clicking the *Read more* about master secret and push app id
>>>>    security [8] leads to */ag-push/#* (and somehow corrupts the
>>>>    history and I could not hit back button).
>>>>    - Search in PushApplication list does not work (and I am not sure
>>>>    if it is necessary as there should not be that many apps).
>>>>
>>>> UI/UX Quirks
>>>>
>>>>    - Variant creation dialog wraps text when there is a lot of space
>>>>    [1].
>>>>    - The area between number of devices and *edit* button shows the
>>>>    *hand* cursor, but it is not clickable. I would suggest to make it
>>>>    clickable and the action would be expanding/collapsing the variant detail.
>>>>    - The *+*/*-* button for expanding/collapsing the statistics does
>>>>    not show *hand* cursor when mouse is above it.
>>>>    - In the top right corner of the window, there is the *warnings* information,
>>>>    however it is strange when there are no warnings so I would suggest one of
>>>>    these:
>>>>       1. Do not show it in the bar altogether when there are no
>>>>       warnings
>>>>       2. Disable the *clickability* of it when there are no warnings
>>>>       3. When the popup is shown, it should not be just an empty
>>>>       box[6], but should show something like *No warnings*
>>>>    - When hitting the *Edit* variant button, it shows a dialog where I
>>>>    can change only the name of the variant. However when I click the*Change
>>>>    network options* button, I am presented with the possibility to
>>>>    change both the name of the variant and the network specific configuration.
>>>>    I would therefore suggest to not show the name field in the *Change
>>>>    network options* dialog as it is not considered a good practise to
>>>>    have two ways of doing the same thing in UI.
>>>>    - It is a bit strange that when I hover over the *copy* (sources)
>>>>    in variant detail, the *edit* and delete buttons disappear until I
>>>>    move the mouse away from the *copy*.
>>>>    - Links to *Android*, *Chrome*, *iOS*, *Cordova* etc. in variant
>>>>    detail should open the documentation in a new tab like the rest of
>>>>    documentation links. Now it opens in the same app which is not good because
>>>>    the user wants to stay in the Admin UI.
>>>>    - When I click on the *in the documentation* link on the *no
>>>>    variants* screen, I get redirected correcly, but it takes a while
>>>>    for the images to load and it pushes the content away and I lose track
>>>>    where was the help I came for. I would suggest to set the dimensions into
>>>>    the <img> tags therefore it will not push the screen away, but simply load
>>>>    into the empty space.
>>>>
>>>> This is aerogear.org bug, could you report that?
>>>
>>>>
>>>>    - Each time the user wants to do a destructive action (i.e. *deleting
>>>>    application*, *deleting variant*,*reseting master secret*) he
>>>>    should be presented with a dialog in which he would have to type the name
>>>>    of the *variant*or *application* in order to continue. This was
>>>>    already in before and I am not sure why was it removed.
>>>>
>>>>  We have discussed this with Andres and he believes it is unnecessary
>>> from UX PoV: clicking big red button should be enough. :-)
>>>
>>> But since this is re-occuring report to the new UI, we should probably
>>> rethink that and introduce confirmation back.
>>>
>>>> Questions
>>>>
>>>>    - I am not sure what *x receivers / y opened* means as well as the
>>>>    meaning of *first time opened* and*last time opened*.
>>>>    - Is there a way to access the list of registered installations as
>>>>    it was before? Should it?
>>>>    - In analytics there are *Push opens* statistics. Does that mean
>>>>    there is some new API in UnifiedPush Server? If so should we test it? If so
>>>>    how?
>>>>
>>>> Yes, all these are related to the new Analytics - push notification
>>> sent to devices / devices opened metric.
>>>
>>>> One more thing
>>>>
>>>> It would be great if we implemented documentation versioning similar to
>>>> readthedocs.org <http://www.readthedocs.org/>. That way there could be
>>>> more versions of the documentation hosted on the aerogear.org
>>>> <http://www.aerogear.org/> site and each version of UnifiedPush Server
>>>> Admin UI could point to the specific version. It would lead to better user
>>>> experience because they would see the documentation exactly for their
>>>> version.
>>>>
>>>
>>> Something what we could consider is hosting generated documentation in
>>> version-prefixed directories, such as here:
>>> http://docs.jboss.org/richfaces/
>>>
>>> This is probably worth separated thread.
>>>
>>>
>>>> All taken into consideration the team did a great job on the 1.1.0 and
>>>> even though it is still just beta.1, it is working very well. Thanks guys!
>>>>
>>>> PS: Sorry for the order of images, it is 3 am and I was too tired to
>>>> reorganize them. Also I did not yet create any JIRA tickets for the bugs. I
>>>> just wanted to share the report with you guys so we can discuss which of
>>>> the items will be moved into the JIRA as tickets and which are not
>>>> important or would me marked as "won't fix".
>>>>
>>>
>>>
>>> @Tadeas: could I ask you to report the bugs in one or two JIRAs (+ JIRAs
>>> specific to aerogear.org, such as page scrolling issue)? Let's report
>>> them in a bulk and assigned to me, I will split them as necessary into
>>> subtasks.
>>>
>>>> Thanks,
>>>> Tadeas Kriz
>>>>
>>>> 1 -
>>>> https://lh5.googleusercontent.com/-OHKxiXEIT88/VV6DvB0uRKI/AAAAAAAAX5I/a-m6umCfZUo/w593-h758-no/Screen%2BShot%2B2015-05-22%2Bat%2B12.14.05%2Bam.png
>>>> 2 -
>>>> https://lh5.googleusercontent.com/-KzruF4kzwj4/VV6Dyuu1kxI/AAAAAAAAX5o/RFuCFGzxtXo/w1192-h512-no/Screen%2BShot%2B2015-05-22%2Bat%2B1.27.53%2Bam.png
>>>> 3 -
>>>> https://lh6.googleusercontent.com/-ZAlJzi51BX0/VV6Dx1J3SxI/AAAAAAAAX5k/UQiql9TMye4/w1187-h571-no/Screen%2BShot%2B2015-05-22%2Bat%2B1.27.58%2Bam.png
>>>> 4 -
>>>> https://lh6.googleusercontent.com/-LHyvZPW5AzI/VV6DxSuf-yI/AAAAAAAAX5c/bi9eJaQ6RLc/w1199-h491-no/Screen%2BShot%2B2015-05-22%2Bat%2B1.28.04%2Bam.png
>>>> 5 -
>>>> https://lh6.googleusercontent.com/-A-dpKMM4IcU/VV6D1WjHp5I/AAAAAAAAX54/XeQC-2KUqVg/w373-h146-no/Screen%2BShot%2B2015-05-22%2Bat%2B1.12.15%2Bam.png
>>>> 6 -
>>>> https://lh3.googleusercontent.com/-dU4Weqwf5as/VV6D2OFf-II/AAAAAAAAX6A/T5CDLREzT-w/w277-h83-no/Screen%2BShot%2B2015-05-22%2Bat%2B1.09.51%2Bam.png
>>>> 7 -
>>>> https://lh5.googleusercontent.com/-q_0F21tJZgo/VV6Dz4jZJPI/AAAAAAAAX5w/ngGABCT_AUM/w320-h316-no/Screen%2BShot%2B2015-05-22%2Bat%2B1.19.53%2Bam.png
>>>> 8 -
>>>> https://lh5.googleusercontent.com/-57qlJTvJEBI/VV6Dwg3i0SI/AAAAAAAAX5Q/KPQxgw1DS0w/w644-h63-no/Screen%2BShot%2B2015-05-22%2Bat%2B1.28.56%2Bam.png
>>>>
>>>>
>>>> On Thu, May 21, 2015 at 11:39 PM, Tadeas Kriz <tkriz at redhat.com> wrote:
>>>>
>>>>> Hey,
>>>>>
>>>>> I've just run integration tests and the UnifiedPush Server works
>>>>> great. One huge downside is the change that breaks the API of Java Sender
>>>>> and that the API is currently in somehow inconsistent state (it is
>>>>> synchronous, but it uses callback to deliver the `success` state and throws
>>>>> exception to deliver the `failed` state).
>>>>>
>>>>> Now I'm going to proceed with the real-device testing.
>>>>>
>>>>> On Thu, May 21, 2015 at 10:33 PM, Matthias Wessendorf <
>>>>> matzew at apache.org> wrote:
>>>>>
>>>>>> NEVERMIND, see
>>>>>> https://github.com/aerogear/aerogear-unifiedpush-server/pull/568 for
>>>>>> details
>>>>>>
>>>>>> staging stays, and we continue w/ 1.1.0 of Keycloak
>>>>>>
>>>>>> On Thu, May 21, 2015 at 10:18 PM, Matthias Wessendorf <
>>>>>> matzew at apache.org> wrote:
>>>>>>
>>>>>>> please give it a spin, so that I can merege it, in order to actually
>>>>>>> do the re-staging
>>>>>>>
>>>>>>> On Thu, May 21, 2015 at 10:15 PM, Matthias Wessendorf <
>>>>>>> mwessendorf at gmail.com> wrote:
>>>>>>>
>>>>>>>> we need to re-stage, due to this bug:
>>>>>>>> https://github.com/aerogear/aerogear-unifiedpush-server/pull/568
>>>>>>>>
>>>>>>>> On Thu, May 21, 2015 at 9:21 PM, Matthias Wessendorf <
>>>>>>>> mwessendorf at gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> after month of work, here is the first beta release for the UPS
>>>>>>>>> 1.1.0. It contains more features and inprovements around UI, JMS for
>>>>>>>>> enhanced scalability and a lot of other stuff:
>>>>>>>>> https://issues.jboss.org/browse/AGPUSH/fixforversion/12326579
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Please test the staged release:
>>>>>>>>>
>>>>>>>>> https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-5605/
>>>>>>>>>
>>>>>>>>> Like w/ the previous alpha.2, please make sure you use a full
>>>>>>>>> profile WildFly or EAP server for tests, since we now have JMS hooks ;-)
>>>>>>>>> (See README for details)
>>>>>>>>>
>>>>>>>>> On Wednesday I'd like to press the button to release it to the
>>>>>>>>> wild.
>>>>>>>>>
>>>>>>>>> PS: Since this is the first beta release we won't yet be updating
>>>>>>>>> our Openshift cartridge - that will stay on 1.0.3 (stable) for a little
>>>>>>>>> longer time. For the next release (beta.2) in a few weeks we may get to
>>>>>>>>> this Openshift update.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Matthias
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> 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
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Matthias Wessendorf
>>>>>>
>>>>>> blog: http://matthiaswessendorf.wordpress.com/
>>>>>> sessions: http://www.slideshare.net/mwessendorf
>>>>>> twitter: http://twitter.com/mwessendorf
>>>>>>
>>>>>> _______________________________________________
>>>>>> aerogear-dev mailing list
>>>>>> aerogear-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> --
>>>>> Tadeas Kriz
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> --
>>>> Tadeas Kriz
>>>>
>>>> _______________________________________________
>>>> aerogear-dev mailing list
>>>> aerogear-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>
>>>
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>
>>
>>
>> --
>> Matthias Wessendorf
>>
>> blog: http://matthiaswessendorf.wordpress.com/
>> sessions: http://www.slideshare.net/mwessendorf
>> twitter: http://twitter.com/mwessendorf
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>



-- 
--
Tadeas Kriz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20150526/106ef693/attachment-0001.html 

From lholmqui at redhat.com  Tue May 26 08:53:00 2015
From: lholmqui at redhat.com (Luke Holmquist)
Date: Tue, 26 May 2015 08:53:00 -0400
Subject: [aerogear-dev] Versioning Documentation
In-Reply-To: <CAEroY35p9_G5U_bV-vZSYOc4Fzdfv4JiSYpx_PMt1WAPbKBRiA@mail.gmail.com>
References: <CAEroY35p9_G5U_bV-vZSYOc4Fzdfv4JiSYpx_PMt1WAPbKBRiA@mail.gmail.com>
Message-ID: <CALD3Fd28VYD0K+8ekcVMDhg=tzoFT4TPhnNkY7ua=pBySjYMkQ@mail.gmail.com>

this would be nice.

On Tue, May 26, 2015 at 7:58 AM, Luk?? Fry? <lukas at fryc.eu> wrote:

> Hey guys,
>
> Tadeas started a discussion about versioning documentation in the thread
> [1],
>
>
> and I must agree - it is a good idea to version documentation (and
> possibly also guides),
>
> especially since our UPS Console now points from the UI to the
> documentation -
> that is a great feature but I'm worried about maintanance of that
> solution, a documentation tend to change in time, with links no longer
> being valid.
>
>
> Lot of projects publish generated documentation separately, hosting it
> e.g. on docs.jboss.org (see [2] for a sample).
>
> I'd suggest to version both, API documentation and guides on a separated
> server.
> Perhaps we could version whole site?
>
>
>
> WDYT?
>
>
> Cheers,
>
> ~ Lukas
>
> [1]
> http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-UnifiedPush-Server-1-1-0-beta-1-tp11665p11672.html
> [2] http://docs.jboss.org/richfaces/
>
> _______________________________________________
> 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/20150526/e8c69a37/attachment.html 

From delalis at gmail.com  Tue May 26 09:37:01 2015
From: delalis at gmail.com (delalis)
Date: Tue, 26 May 2015 06:37:01 -0700 (MST)
Subject: [aerogear-dev] Aerogear UPS 1.0.3 - Wildfly server error on login
Message-ID: <1432647421048-11683.post@n5.nabble.com>

Hey guys, Ive been following this tutorial to get my server set up, The war
file deploy successfully, but I am getting an error when logging into the
UPS dashboard, I believe it might be caused by something I did incorrectly
when setting up the database schema.  I did not fully understand the whole
ups-migrator update and liquibase stuff...and might have done it
incorrectly.

https://aerogear.org/docs/unifiedpush/ups_userguide/index/#schema

Here is the error:

https://gist.github.com/delalis/264b3e9b4e18e5328492

Any ideas?  does it look like the error is tied to my database schema being
wrong? or perhaps my datasource isnt set up properly?

Any help would be appreciated.  thanks



--
View this message in context: http://aerogear-dev.1069024.n5.nabble.com/Aerogear-UPS-1-0-3-Wildfly-server-error-on-login-tp11683.html
Sent from the aerogear-dev mailing list archive at Nabble.com.

From matzew at apache.org  Tue May 26 11:04:46 2015
From: matzew at apache.org (Matthias Wessendorf)
Date: Tue, 26 May 2015 17:04:46 +0200
Subject: [aerogear-dev] UnifiedPush Server 1.1.0-beta.1
In-Reply-To: <CAJ0HFMCQxvqZKC0z3xeKyTWczK3Yo+pMDU3r2Bt3=28PHik_hQ@mail.gmail.com>
References: <CAAg5f2Rpiq0L0CmvARgc9m_a==rjjLKyMDaADTP00MeL_18oUg@mail.gmail.com>
	<CAAg5f2SvujHDvc8OU_eK-fDJ=r3GoNjuwiJkk1=TpxjSzepgdg@mail.gmail.com>
	<CAAg5f2RcJGPXS24k06Ayt4Ouswhgy1qU-faA6z2NTrRNC=JEtA@mail.gmail.com>
	<CAAg5f2Tf1b5EA3N7+Zg4Mamrvc9p4vGuWjmV_=aJEuGw5E7qTA@mail.gmail.com>
	<CAJ0HFMAQaEue=mW6+eKvR1V9B4oTH86MO3yb41sbvi-T4pyfwg@mail.gmail.com>
	<CAJ0HFMDLVz8oY9TH7YVCK+a85vLG=xFC=quRADbjv4Mpf4HQhA@mail.gmail.com>
	<CAEroY35uSYOPWdZ0Xnps-VYtvVfJaWvSW8fXDedn79Qry8Dkxg@mail.gmail.com>
	<CAAg5f2Q=zbNjzZ8Ufk3f6aH3OCBaA36vJE5h2+7J+_WFj7ZCuw@mail.gmail.com>
	<CAEroY378zrTUG9icrFvZT+9V+pnOE7iuL4t9SEanTCnFDuYriA@mail.gmail.com>
	<CAJ0HFMCQxvqZKC0z3xeKyTWczK3Yo+pMDU3r2Bt3=28PHik_hQ@mail.gmail.com>
Message-ID: <CAAg5f2SH=EKV+Z94hqt4bHS-NLFceEaPWwZmAa_z5XwBpyioTw@mail.gmail.com>

OK,

I clicked the button \o/

thanks again for testing

On Tue, May 26, 2015 at 2:41 PM, Tadeas Kriz <tkriz at redhat.com> wrote:

> Thanks Lukas!
>
> On Tue, May 26, 2015 at 2:37 PM, Luk?? Fry? <lukas.fryc at gmail.com> wrote:
>
>> Hey Tadeas,
>>
>> as agreed on the IRC, I have opened these jiras:
>>
>> https://issues.jboss.org/browse/AGPUSH-1423 UPS Console: bulk of Admin
>> UI/UX issues
>> https://issues.jboss.org/browse/AGPUSH-1421 UPS Console: re-introduce
>> double-check confirmation for app/variant remove/secret-reset
>> https://issues.jboss.org/browse/AGPUSH-1422 Describe test spec for
>> testing new Push Opened Analytics feature
>>
>>
>> Cheers,
>>
>> ~ Lukas
>>
>> On Tue, May 26, 2015 at 10:40 AM, Matthias Wessendorf <matzew at apache.org>
>> wrote:
>>
>>> Hi,
>>>
>>> thanks for the testing. Looks like we are good to go w/ the beta.1
>>> release.
>>> Like Lukas already asked, are you able to create a few JIRAs to capture
>>> the issues on the UI ?
>>>
>>> Thanks
>>>
>>> On Fri, May 22, 2015 at 1:30 PM, Luk?? Fry? <lukas.fryc at gmail.com>
>>> wrote:
>>>
>>>> Thanks Tadeas,
>>>>
>>>> that's wonderful feedback!
>>>>
>>>> On Fri, May 22, 2015 at 3:24 AM, Tadeas Kriz <tkriz at redhat.com> wrote:
>>>>
>>>>> UnifiedPush Server 1.1.0-beta.1 testing report
>>>>>
>>>>> Hello there again,
>>>>>
>>>>> so I have tested the UPS using the UI console, iOS 8.0 and Android
>>>>> 5.1. I have used the HelloPush example as to me it seems the best for
>>>>> testing the server and messaging.
>>>>>
>>>>> I have not tested the Windows, SimplePush and Amazon. The Simple Push
>>>>> was tested in the automated integration tests, but that does not apply for
>>>>> Windows and Amazon as we do not have the test cases for those. I also could
>>>>> not test them manually because I do not have Windows nor Amazon developer
>>>>> accounts.
>>>>>
>>>>> I have tortured the Admin UI quite thoroughly and it did really well.
>>>>> There were some bugs and some UX quirks that I suggest we fix into the next
>>>>> beta release.
>>>>> Kudos for:
>>>>>
>>>>>    - Absolutely f***ing awesome wizard in the UnifiedPush Server
>>>>>    Admin UI. I have loved every step of it and what totally amazed me was that
>>>>>    when I deployed the app on the device and the app registered itself to the
>>>>>    UPS, the wizard automagically progreessed to the next step! That is so damn
>>>>>    awesome and the UX is just wonderful.
>>>>>       - It was so great that I (as a user) would not mind if it was
>>>>>       shown also when creating another variants in an application that already
>>>>>       has some, because it makes it more friendly and gives the feedback when the
>>>>>       first registration is successful.
>>>>>    - It is also great that the user does not need to click on a link
>>>>>    to keep logged in and only focusing the window is enough. Thanks for that.
>>>>>    - iOS HelloPush example is Swift 1.2 ready!
>>>>>    - Very nice error reporting in iOS HelloPush example (I set the
>>>>>    URL wrong and the app told me about registration issue)
>>>>>
>>>>> Found bugs
>>>>>
>>>>>    -
>>>>>
>>>>>    When sending push message using the UI, the following can happen:
>>>>>    1. Check one or more variants in the variants list
>>>>>       2. Uncheck all of the variants (this will leave you in the same
>>>>>       visual state as it was before step 1.)
>>>>>       3. Send the message
>>>>>       4. Wonder why it was not sent to any of the devices
>>>>>
>>>>>    It seems that when I open the dialog, it shows *No variants*, but
>>>>>    it really means *All variants*. However when I check some variants
>>>>>    and then uncheck them all, it will still say *No variants*, but
>>>>>    now it really means it as *No variants*. My suggestion is to start
>>>>>    with having all the variants checked and instead of listing them all
>>>>>    separated by commas, we should show*All variants*.
>>>>>    -
>>>>>
>>>>>    For some strange reason there is a lot of space in the bottom and
>>>>>    I can scroll away all the content.
>>>>>    - There are *?* help icons/buttons in the lower-right corners [5]
>>>>>    in the analytics panel, but they do not do or show anything.
>>>>>    - In the variant list it still shows *0 delivered*[7] even when I
>>>>>    already sent and delivered messages.
>>>>>    - In *Sender API* tab there is always *Set up Java UPS* on top of
>>>>>    the other sender platform (see [2, 3, 4])
>>>>>    - Clicking the *Read more* about master secret and push app id
>>>>>    security [8] leads to */ag-push/#* (and somehow corrupts the
>>>>>    history and I could not hit back button).
>>>>>    - Search in PushApplication list does not work (and I am not sure
>>>>>    if it is necessary as there should not be that many apps).
>>>>>
>>>>> UI/UX Quirks
>>>>>
>>>>>    - Variant creation dialog wraps text when there is a lot of space
>>>>>    [1].
>>>>>    - The area between number of devices and *edit* button shows the
>>>>>    *hand* cursor, but it is not clickable. I would suggest to make it
>>>>>    clickable and the action would be expanding/collapsing the variant detail.
>>>>>    - The *+*/*-* button for expanding/collapsing the statistics does
>>>>>    not show *hand* cursor when mouse is above it.
>>>>>    - In the top right corner of the window, there is the *warnings* information,
>>>>>    however it is strange when there are no warnings so I would suggest one of
>>>>>    these:
>>>>>       1. Do not show it in the bar altogether when there are no
>>>>>       warnings
>>>>>       2. Disable the *clickability* of it when there are no warnings
>>>>>       3. When the popup is shown, it should not be just an empty
>>>>>       box[6], but should show something like *No warnings*
>>>>>    - When hitting the *Edit* variant button, it shows a dialog where
>>>>>    I can change only the name of the variant. However when I click the*Change
>>>>>    network options* button, I am presented with the possibility to
>>>>>    change both the name of the variant and the network specific configuration.
>>>>>    I would therefore suggest to not show the name field in the *Change
>>>>>    network options* dialog as it is not considered a good practise to
>>>>>    have two ways of doing the same thing in UI.
>>>>>    - It is a bit strange that when I hover over the *copy* (sources)
>>>>>    in variant detail, the *edit* and delete buttons disappear until I
>>>>>    move the mouse away from the *copy*.
>>>>>    - Links to *Android*, *Chrome*, *iOS*, *Cordova* etc. in variant
>>>>>    detail should open the documentation in a new tab like the rest of
>>>>>    documentation links. Now it opens in the same app which is not good because
>>>>>    the user wants to stay in the Admin UI.
>>>>>    - When I click on the *in the documentation* link on the *no
>>>>>    variants* screen, I get redirected correcly, but it takes a while
>>>>>    for the images to load and it pushes the content away and I lose track
>>>>>    where was the help I came for. I would suggest to set the dimensions into
>>>>>    the <img> tags therefore it will not push the screen away, but simply load
>>>>>    into the empty space.
>>>>>
>>>>> This is aerogear.org bug, could you report that?
>>>>
>>>>>
>>>>>    - Each time the user wants to do a destructive action (i.e. *deleting
>>>>>    application*, *deleting variant*,*reseting master secret*) he
>>>>>    should be presented with a dialog in which he would have to type the name
>>>>>    of the *variant*or *application* in order to continue. This was
>>>>>    already in before and I am not sure why was it removed.
>>>>>
>>>>>  We have discussed this with Andres and he believes it is unnecessary
>>>> from UX PoV: clicking big red button should be enough. :-)
>>>>
>>>> But since this is re-occuring report to the new UI, we should probably
>>>> rethink that and introduce confirmation back.
>>>>
>>>>> Questions
>>>>>
>>>>>    - I am not sure what *x receivers / y opened* means as well as the
>>>>>    meaning of *first time opened* and*last time opened*.
>>>>>    - Is there a way to access the list of registered installations as
>>>>>    it was before? Should it?
>>>>>    - In analytics there are *Push opens* statistics. Does that mean
>>>>>    there is some new API in UnifiedPush Server? If so should we test it? If so
>>>>>    how?
>>>>>
>>>>> Yes, all these are related to the new Analytics - push notification
>>>> sent to devices / devices opened metric.
>>>>
>>>>> One more thing
>>>>>
>>>>> It would be great if we implemented documentation versioning similar
>>>>> to readthedocs.org <http://www.readthedocs.org/>. That way there
>>>>> could be more versions of the documentation hosted on the aerogear.org
>>>>> <http://www.aerogear.org/> site and each version of UnifiedPush
>>>>> Server Admin UI could point to the specific version. It would lead to
>>>>> better user experience because they would see the documentation exactly for
>>>>> their version.
>>>>>
>>>>
>>>> Something what we could consider is hosting generated documentation in
>>>> version-prefixed directories, such as here:
>>>> http://docs.jboss.org/richfaces/
>>>>
>>>> This is probably worth separated thread.
>>>>
>>>>
>>>>> All taken into consideration the team did a great job on the 1.1.0 and
>>>>> even though it is still just beta.1, it is working very well. Thanks guys!
>>>>>
>>>>> PS: Sorry for the order of images, it is 3 am and I was too tired to
>>>>> reorganize them. Also I did not yet create any JIRA tickets for the bugs. I
>>>>> just wanted to share the report with you guys so we can discuss which of
>>>>> the items will be moved into the JIRA as tickets and which are not
>>>>> important or would me marked as "won't fix".
>>>>>
>>>>
>>>>
>>>> @Tadeas: could I ask you to report the bugs in one or two JIRAs (+
>>>> JIRAs specific to aerogear.org, such as page scrolling issue)? Let's
>>>> report them in a bulk and assigned to me, I will split them as necessary
>>>> into subtasks.
>>>>
>>>>> Thanks,
>>>>> Tadeas Kriz
>>>>>
>>>>> 1 -
>>>>> https://lh5.googleusercontent.com/-OHKxiXEIT88/VV6DvB0uRKI/AAAAAAAAX5I/a-m6umCfZUo/w593-h758-no/Screen%2BShot%2B2015-05-22%2Bat%2B12.14.05%2Bam.png
>>>>> 2 -
>>>>> https://lh5.googleusercontent.com/-KzruF4kzwj4/VV6Dyuu1kxI/AAAAAAAAX5o/RFuCFGzxtXo/w1192-h512-no/Screen%2BShot%2B2015-05-22%2Bat%2B1.27.53%2Bam.png
>>>>> 3 -
>>>>> https://lh6.googleusercontent.com/-ZAlJzi51BX0/VV6Dx1J3SxI/AAAAAAAAX5k/UQiql9TMye4/w1187-h571-no/Screen%2BShot%2B2015-05-22%2Bat%2B1.27.58%2Bam.png
>>>>> 4 -
>>>>> https://lh6.googleusercontent.com/-LHyvZPW5AzI/VV6DxSuf-yI/AAAAAAAAX5c/bi9eJaQ6RLc/w1199-h491-no/Screen%2BShot%2B2015-05-22%2Bat%2B1.28.04%2Bam.png
>>>>> 5 -
>>>>> https://lh6.googleusercontent.com/-A-dpKMM4IcU/VV6D1WjHp5I/AAAAAAAAX54/XeQC-2KUqVg/w373-h146-no/Screen%2BShot%2B2015-05-22%2Bat%2B1.12.15%2Bam.png
>>>>> 6 -
>>>>> https://lh3.googleusercontent.com/-dU4Weqwf5as/VV6D2OFf-II/AAAAAAAAX6A/T5CDLREzT-w/w277-h83-no/Screen%2BShot%2B2015-05-22%2Bat%2B1.09.51%2Bam.png
>>>>> 7 -
>>>>> https://lh5.googleusercontent.com/-q_0F21tJZgo/VV6Dz4jZJPI/AAAAAAAAX5w/ngGABCT_AUM/w320-h316-no/Screen%2BShot%2B2015-05-22%2Bat%2B1.19.53%2Bam.png
>>>>> 8 -
>>>>> https://lh5.googleusercontent.com/-57qlJTvJEBI/VV6Dwg3i0SI/AAAAAAAAX5Q/KPQxgw1DS0w/w644-h63-no/Screen%2BShot%2B2015-05-22%2Bat%2B1.28.56%2Bam.png
>>>>>
>>>>>
>>>>> On Thu, May 21, 2015 at 11:39 PM, Tadeas Kriz <tkriz at redhat.com>
>>>>> wrote:
>>>>>
>>>>>> Hey,
>>>>>>
>>>>>> I've just run integration tests and the UnifiedPush Server works
>>>>>> great. One huge downside is the change that breaks the API of Java Sender
>>>>>> and that the API is currently in somehow inconsistent state (it is
>>>>>> synchronous, but it uses callback to deliver the `success` state and throws
>>>>>> exception to deliver the `failed` state).
>>>>>>
>>>>>> Now I'm going to proceed with the real-device testing.
>>>>>>
>>>>>> On Thu, May 21, 2015 at 10:33 PM, Matthias Wessendorf <
>>>>>> matzew at apache.org> wrote:
>>>>>>
>>>>>>> NEVERMIND, see
>>>>>>> https://github.com/aerogear/aerogear-unifiedpush-server/pull/568
>>>>>>> for details
>>>>>>>
>>>>>>> staging stays, and we continue w/ 1.1.0 of Keycloak
>>>>>>>
>>>>>>> On Thu, May 21, 2015 at 10:18 PM, Matthias Wessendorf <
>>>>>>> matzew at apache.org> wrote:
>>>>>>>
>>>>>>>> please give it a spin, so that I can merege it, in order to
>>>>>>>> actually do the re-staging
>>>>>>>>
>>>>>>>> On Thu, May 21, 2015 at 10:15 PM, Matthias Wessendorf <
>>>>>>>> mwessendorf at gmail.com> wrote:
>>>>>>>>
>>>>>>>>> we need to re-stage, due to this bug:
>>>>>>>>> https://github.com/aerogear/aerogear-unifiedpush-server/pull/568
>>>>>>>>>
>>>>>>>>> On Thu, May 21, 2015 at 9:21 PM, Matthias Wessendorf <
>>>>>>>>> mwessendorf at gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> after month of work, here is the first beta release for the UPS
>>>>>>>>>> 1.1.0. It contains more features and inprovements around UI, JMS for
>>>>>>>>>> enhanced scalability and a lot of other stuff:
>>>>>>>>>> https://issues.jboss.org/browse/AGPUSH/fixforversion/12326579
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Please test the staged release:
>>>>>>>>>>
>>>>>>>>>> https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-5605/
>>>>>>>>>>
>>>>>>>>>> Like w/ the previous alpha.2, please make sure you use a full
>>>>>>>>>> profile WildFly or EAP server for tests, since we now have JMS hooks ;-)
>>>>>>>>>> (See README for details)
>>>>>>>>>>
>>>>>>>>>> On Wednesday I'd like to press the button to release it to the
>>>>>>>>>> wild.
>>>>>>>>>>
>>>>>>>>>> PS: Since this is the first beta release we won't yet be updating
>>>>>>>>>> our Openshift cartridge - that will stay on 1.0.3 (stable) for a little
>>>>>>>>>> longer time. For the next release (beta.2) in a few weeks we may get to
>>>>>>>>>> this Openshift update.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Matthias
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> 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
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Matthias Wessendorf
>>>>>>>
>>>>>>> blog: http://matthiaswessendorf.wordpress.com/
>>>>>>> sessions: http://www.slideshare.net/mwessendorf
>>>>>>> twitter: http://twitter.com/mwessendorf
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> aerogear-dev mailing list
>>>>>>> aerogear-dev at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> --
>>>>>> Tadeas Kriz
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> --
>>>>> Tadeas Kriz
>>>>>
>>>>> _______________________________________________
>>>>> aerogear-dev mailing list
>>>>> aerogear-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> aerogear-dev mailing list
>>>> aerogear-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>
>>>
>>>
>>>
>>> --
>>> Matthias Wessendorf
>>>
>>> blog: http://matthiaswessendorf.wordpress.com/
>>> sessions: http://www.slideshare.net/mwessendorf
>>> twitter: http://twitter.com/mwessendorf
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
>
> --
> --
> Tadeas Kriz
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.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/20150526/6aea857d/attachment-0001.html 

From mwessendorf at gmail.com  Tue May 26 11:18:08 2015
From: mwessendorf at gmail.com (Matthias Wessendorf)
Date: Tue, 26 May 2015 17:18:08 +0200
Subject: [aerogear-dev] [ANN] UnifiedPush Server 1.1.0-beta.1 is out
Message-ID: <CAAg5f2T4-PQOZgq4ikerP=Qjwo+ii3jryr9+UTGO_TyTC1TNYg@mail.gmail.com>

Folks,

after month of work, the AeroGear team is happy to announce the first beta
release for the UPS 1.1.0!

A list of highlights:
* Analytic endpoint for "app opened due to push"
* Analytic UI (nice graphs for the engagement)
* lot's of UI improvements since last alpha.2 release
* More JMS enhancements for scalability

All content for this release is is visible here:
https://issues.jboss.org/browse/AGPUSH/fixforversion/12326579


The items are downloadable on Github:
https://github.com/aerogear/aerogear-unifiedpush-server/releases/tag/1.1.0-beta.1

And the maven central repos should be sync'd by tomorrow morning (EU)

Have fun!
-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/20150526/087bac50/attachment.html 

From matzew at apache.org  Tue May 26 11:45:10 2015
From: matzew at apache.org (Matthias Wessendorf)
Date: Tue, 26 May 2015 17:45:10 +0200
Subject: [aerogear-dev] Aerogear UPS 1.0.3 - Wildfly server error on
	login
In-Reply-To: <1432647421048-11683.post@n5.nabble.com>
References: <1432647421048-11683.post@n5.nabble.com>
Message-ID: <CAAg5f2THGNL8dSu3McMv3YPWHTr2rZCgug0UyMTE8uCV=COxKQ@mail.gmail.com>

Howdy,

was that a fresh install, or on upgrading?

can you share the properties file from the migrator (which actually creates
the UPS schema too).
Any chance to perform a run w/ some more logging? (e.g. ./bin/ups-migrator
--logLevel=DEBUG update)

thanks

On Tue, May 26, 2015 at 3:37 PM, delalis <delalis at gmail.com> wrote:

> Hey guys, Ive been following this tutorial to get my server set up, The war
> file deploy successfully, but I am getting an error when logging into the
> UPS dashboard, I believe it might be caused by something I did incorrectly
> when setting up the database schema.  I did not fully understand the whole
> ups-migrator update and liquibase stuff...and might have done it
> incorrectly.
>
> https://aerogear.org/docs/unifiedpush/ups_userguide/index/#schema
>
> Here is the error:
>
> https://gist.github.com/delalis/264b3e9b4e18e5328492
>
> Any ideas?  does it look like the error is tied to my database schema being
> wrong? or perhaps my datasource isnt set up properly?
>
> Any help would be appreciated.  thanks
>
>
>
> --
> View this message in context:
> http://aerogear-dev.1069024.n5.nabble.com/Aerogear-UPS-1-0-3-Wildfly-server-error-on-login-tp11683.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/20150526/624341bd/attachment.html 

From delalis at gmail.com  Tue May 26 11:54:59 2015
From: delalis at gmail.com (delalis)
Date: Tue, 26 May 2015 08:54:59 -0700 (MST)
Subject: [aerogear-dev] Aerogear UPS 1.0.3 - Wildfly server error on
 login
In-Reply-To: <CAAg5f2THGNL8dSu3McMv3YPWHTr2rZCgug0UyMTE8uCV=COxKQ@mail.gmail.com>
References: <1432647421048-11683.post@n5.nabble.com>
	<CAAg5f2THGNL8dSu3McMv3YPWHTr2rZCgug0UyMTE8uCV=COxKQ@mail.gmail.com>
Message-ID: <1432655699217-11687.post@n5.nabble.com>

Actually, I skipped that step because a previous employee had already run the
migrator in windows 7 (since windows doesnt have a native shell scripting
processor via cmd prompt) using this command he found somewhere:

java -classpath ups-migrator.jar
-Dliquibase.databaseChangeLogTableName="ups_db
_changelog" 
-Dliquibase.databaseChangeLogLockTableName="ups_db_changeloglock" l
iquibase.integration.commandline.Main "--defaultsFile=liquibase.properties"
upda
te


Apparently that worked for him in UPS 1.0.2, but I am trying to do a fresh
install to the same mySQL database and I had hoped his migrator run had done
the trick but clearly not.

What would you recommend I do?  I was thinking I would install CYGWIN on the
windows box so that I could run the migrator shell script, wipe the
database, set up a fresh one as per the tutorial i mentioned above, and then
I could run "./bin/ups-migrator --logLevel=DEBUG update" as per your request

thoughts?





--
View this message in context: http://aerogear-dev.1069024.n5.nabble.com/Aerogear-UPS-1-0-3-Wildfly-server-error-on-login-tp11683p11687.html
Sent from the aerogear-dev mailing list archive at Nabble.com.

From lholmqui at redhat.com  Tue May 26 12:38:34 2015
From: lholmqui at redhat.com (Luke Holmquist)
Date: Tue, 26 May 2015 12:38:34 -0400
Subject: [aerogear-dev] [ANN] UnifiedPush Server 1.1.0-beta.1 is out
In-Reply-To: <CAAg5f2T4-PQOZgq4ikerP=Qjwo+ii3jryr9+UTGO_TyTC1TNYg@mail.gmail.com>
References: <CAAg5f2T4-PQOZgq4ikerP=Qjwo+ii3jryr9+UTGO_TyTC1TNYg@mail.gmail.com>
Message-ID: <CALD3Fd3djHv93vTJjfuXGmh6j-yPTqhbKzQ+6gL05g4YXdGkcA@mail.gmail.com>

Great Job Folks

On Tue, May 26, 2015 at 11:18 AM, Matthias Wessendorf <mwessendorf at gmail.com
> wrote:

> Folks,
>
> after month of work, the AeroGear team is happy to announce the first beta
> release for the UPS 1.1.0!
>
> A list of highlights:
> * Analytic endpoint for "app opened due to push"
> * Analytic UI (nice graphs for the engagement)
> * lot's of UI improvements since last alpha.2 release
> * More JMS enhancements for scalability
>
> All content for this release is is visible here:
> https://issues.jboss.org/browse/AGPUSH/fixforversion/12326579
>
>
> The items are downloadable on Github:
>
> https://github.com/aerogear/aerogear-unifiedpush-server/releases/tag/1.1.0-beta.1
>
> And the maven central repos should be sync'd by tomorrow morning (EU)
>
> Have fun!
> -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/20150526/0f245f72/attachment.html 

From corinnekrych at gmail.com  Wed May 27 02:31:16 2015
From: corinnekrych at gmail.com (Corinne Krych)
Date: Wed, 27 May 2015 08:31:16 +0200
Subject: [aerogear-dev] Versioning Documentation
In-Reply-To: <CALD3Fd28VYD0K+8ekcVMDhg=tzoFT4TPhnNkY7ua=pBySjYMkQ@mail.gmail.com>
References: <CAEroY35p9_G5U_bV-vZSYOc4Fzdfv4JiSYpx_PMt1WAPbKBRiA@mail.gmail.com>
	<CALD3Fd28VYD0K+8ekcVMDhg=tzoFT4TPhnNkY7ua=pBySjYMkQ@mail.gmail.com>
Message-ID: <CAL8vO=cgO=qWtsc+Omu34ou1XhrqmU_L6vvPU9U=+XvpiFCC0w@mail.gmail.com>

+1
specially for a guide
it would be nice to match the released version.

On 26 May 2015 at 14:53, Luke Holmquist <lholmqui at redhat.com> wrote:

> this would be nice.
>
> On Tue, May 26, 2015 at 7:58 AM, Luk?? Fry? <lukas at fryc.eu> wrote:
>
>> Hey guys,
>>
>> Tadeas started a discussion about versioning documentation in the thread
>> [1],
>>
>>
>> and I must agree - it is a good idea to version documentation (and
>> possibly also guides),
>>
>> especially since our UPS Console now points from the UI to the
>> documentation -
>> that is a great feature but I'm worried about maintanance of that
>> solution, a documentation tend to change in time, with links no longer
>> being valid.
>>
>>
>> Lot of projects publish generated documentation separately, hosting it
>> e.g. on docs.jboss.org (see [2] for a sample).
>>
>> I'd suggest to version both, API documentation and guides on a separated
>> server.
>> Perhaps we could version whole site?
>>
>>
>>
>> WDYT?
>>
>>
>> Cheers,
>>
>> ~ Lukas
>>
>> [1]
>> http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-UnifiedPush-Server-1-1-0-beta-1-tp11665p11672.html
>> [2] http://docs.jboss.org/richfaces/
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.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/20150527/4122faa7/attachment.html 

From matzew at apache.org  Wed May 27 04:16:58 2015
From: matzew at apache.org (Matthias Wessendorf)
Date: Wed, 27 May 2015 10:16:58 +0200
Subject: [aerogear-dev] Versioning Documentation
In-Reply-To: <CAL8vO=cgO=qWtsc+Omu34ou1XhrqmU_L6vvPU9U=+XvpiFCC0w@mail.gmail.com>
References: <CAEroY35p9_G5U_bV-vZSYOc4Fzdfv4JiSYpx_PMt1WAPbKBRiA@mail.gmail.com>
	<CALD3Fd28VYD0K+8ekcVMDhg=tzoFT4TPhnNkY7ua=pBySjYMkQ@mail.gmail.com>
	<CAL8vO=cgO=qWtsc+Omu34ou1XhrqmU_L6vvPU9U=+XvpiFCC0w@mail.gmail.com>
Message-ID: <CAAg5f2RJcu4_TA50paqDQw0h28nEbpJV7VqFtrxFYgquS4bx+Q@mail.gmail.com>

What's the JIRA ? :)

On Wed, May 27, 2015 at 8:31 AM, Corinne Krych <corinnekrych at gmail.com>
wrote:

> +1
> specially for a guide
> it would be nice to match the released version.
>
> On 26 May 2015 at 14:53, Luke Holmquist <lholmqui at redhat.com> wrote:
>
>> this would be nice.
>>
>> On Tue, May 26, 2015 at 7:58 AM, Luk?? Fry? <lukas at fryc.eu> wrote:
>>
>>> Hey guys,
>>>
>>> Tadeas started a discussion about versioning documentation in the thread
>>> [1],
>>>
>>>
>>> and I must agree - it is a good idea to version documentation (and
>>> possibly also guides),
>>>
>>> especially since our UPS Console now points from the UI to the
>>> documentation -
>>> that is a great feature but I'm worried about maintanance of that
>>> solution, a documentation tend to change in time, with links no longer
>>> being valid.
>>>
>>>
>>> Lot of projects publish generated documentation separately, hosting it
>>> e.g. on docs.jboss.org (see [2] for a sample).
>>>
>>> I'd suggest to version both, API documentation and guides on a separated
>>> server.
>>> Perhaps we could version whole site?
>>>
>>>
>>>
>>> WDYT?
>>>
>>>
>>> Cheers,
>>>
>>> ~ Lukas
>>>
>>> [1]
>>> http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-UnifiedPush-Server-1-1-0-beta-1-tp11665p11672.html
>>> [2] http://docs.jboss.org/richfaces/
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev at lists.jboss.org
>>> https://lists.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/20150527/54163069/attachment-0001.html 

From delalis at gmail.com  Wed May 27 09:10:30 2015
From: delalis at gmail.com (delalis)
Date: Wed, 27 May 2015 06:10:30 -0700 (MST)
Subject: [aerogear-dev] Aerogear UPS 1.0.3 - Wildfly server error on
 login
In-Reply-To: <CAAg5f2THGNL8dSu3McMv3YPWHTr2rZCgug0UyMTE8uCV=COxKQ@mail.gmail.com>
References: <1432647421048-11683.post@n5.nabble.com>
	<CAAg5f2THGNL8dSu3McMv3YPWHTr2rZCgug0UyMTE8uCV=COxKQ@mail.gmail.com>
Message-ID: <1432732230444-11691.post@n5.nabble.com>

So, any ideas regarding running this ups-migrator script in windows?  Should
I install cygwin? 



--
View this message in context: http://aerogear-dev.1069024.n5.nabble.com/Aerogear-UPS-1-0-3-Wildfly-server-error-on-login-tp11683p11691.html
Sent from the aerogear-dev mailing list archive at Nabble.com.

From avibelli at redhat.com  Wed May 27 09:10:41 2015
From: avibelli at redhat.com (Andrea Vibelli)
Date: Wed, 27 May 2015 06:10:41 -0700 (MST)
Subject: [aerogear-dev] Missing instruction in Android Aerogear Guides
Message-ID: <1432732241663-11692.post@n5.nabble.com>

Hi all, 
after having followed the Aerogear Guide for Android
(https://aerogear.org/docs/guides/aerogear-android/how-to-build-aerogear-android/),
I encountered an error while building the aerogear-android-push SDK:

/Could not resolve dependencies for project
org.jboss.aerogear:aerogear-android-push:aar:2.2.0-SNAPSHOT: Failure to find
com.google.android.gms:play-services:aar:6.1.11 /

It turned out that I needed to install the Google Repository in order to
have that dependency, so I believe it should be added in the guide (fourth
bullet point in the Prereqs):

Latest Android Support Library, Google Play Services and Google Repository.

Thanks!
Andrea



--
View this message in context: http://aerogear-dev.1069024.n5.nabble.com/Missing-instruction-in-Android-Aerogear-Guides-tp11692.html
Sent from the aerogear-dev mailing list archive at Nabble.com.

From supittma at redhat.com  Wed May 27 09:28:44 2015
From: supittma at redhat.com (Summers Pittman)
Date: Wed, 27 May 2015 09:28:44 -0400
Subject: [aerogear-dev] Missing instruction in Android Aerogear Guides
In-Reply-To: <1432732241663-11692.post@n5.nabble.com>
References: <1432732241663-11692.post@n5.nabble.com>
Message-ID: <CAEQz2CtRfMath_QbDe9Ym47aYjdHJai9VJkiFR2woQ7AkuXN7A@mail.gmail.com>

On Wed, May 27, 2015 at 9:10 AM, Andrea Vibelli <avibelli at redhat.com> wrote:

> Hi all,
> after having followed the Aerogear Guide for Android
> (
> https://aerogear.org/docs/guides/aerogear-android/how-to-build-aerogear-android/
> ),
> I encountered an error while building the aerogear-android-push SDK:
>
> /Could not resolve dependencies for project
> org.jboss.aerogear:aerogear-android-push:aar:2.2.0-SNAPSHOT: Failure to
> find
> com.google.android.gms:play-services:aar:6.1.11 /
>
> It turned out that I needed to install the Google Repository in order to
> have that dependency, so I believe it should be added in the guide (fourth
> bullet point in the Prereqs):
>
> Latest Android Support Library, Google Play Services and Google Repository.
>
https://github.com/secondsun/aerogear.org/tree/android_add_repo_req
^^^ Does this look right?

>
> Thanks!
> Andrea
>
>
>
> --
> View this message in context:
> http://aerogear-dev.1069024.n5.nabble.com/Missing-instruction-in-Android-Aerogear-Guides-tp11692.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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20150527/12ba2ae3/attachment.html 

From matzew at apache.org  Wed May 27 09:43:38 2015
From: matzew at apache.org (Matthias Wessendorf)
Date: Wed, 27 May 2015 15:43:38 +0200
Subject: [aerogear-dev] Parent 0.2.15 -> staging
Message-ID: <CAAg5f2QiU9Z7s_Dx5qyW5_apU8-cTe9srvDjS7q5jGeiwBoByw@mail.gmail.com>

Ahoy!

A new release of aerogear-parent was staged at:
https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-5639/

I'm considering to release it on Friday, after some feedback. If you want
the release to be postoned to another day, let me know.

-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/20150527/cbf6d909/attachment.html 

From supittma at redhat.com  Wed May 27 09:57:31 2015
From: supittma at redhat.com (Summers Pittman)
Date: Wed, 27 May 2015 09:57:31 -0400
Subject: [aerogear-dev] Versioning Documentation
In-Reply-To: <CAAg5f2RJcu4_TA50paqDQw0h28nEbpJV7VqFtrxFYgquS4bx+Q@mail.gmail.com>
References: <CAEroY35p9_G5U_bV-vZSYOc4Fzdfv4JiSYpx_PMt1WAPbKBRiA@mail.gmail.com>
	<CALD3Fd28VYD0K+8ekcVMDhg=tzoFT4TPhnNkY7ua=pBySjYMkQ@mail.gmail.com>
	<CAL8vO=cgO=qWtsc+Omu34ou1XhrqmU_L6vvPU9U=+XvpiFCC0w@mail.gmail.com>
	<CAAg5f2RJcu4_TA50paqDQw0h28nEbpJV7VqFtrxFYgquS4bx+Q@mail.gmail.com>
Message-ID: <CAEQz2Cs-aNJus30q8d4cnWiL3WE+hzf2w3JcruDCvw1Hz9n3+w@mail.gmail.com>

On Wed, May 27, 2015 at 4:16 AM, Matthias Wessendorf <matzew at apache.org>
wrote:

> What's the JIRA ? :)
>
The thing I don't browse on a daily basis for the latest good idea someone
has spitballed.

>
> On Wed, May 27, 2015 at 8:31 AM, Corinne Krych <corinnekrych at gmail.com>
> wrote:
>
>> +1
>> specially for a guide
>> it would be nice to match the released version.
>>
>> On 26 May 2015 at 14:53, Luke Holmquist <lholmqui at redhat.com> wrote:
>>
>>> this would be nice.
>>>
>>> On Tue, May 26, 2015 at 7:58 AM, Luk?? Fry? <lukas at fryc.eu> wrote:
>>>
>>>> Hey guys,
>>>>
>>>> Tadeas started a discussion about versioning documentation in the
>>>> thread [1],
>>>>
>>>>
>>>> and I must agree - it is a good idea to version documentation (and
>>>> possibly also guides),
>>>>
>>>> especially since our UPS Console now points from the UI to the
>>>> documentation -
>>>> that is a great feature but I'm worried about maintanance of that
>>>> solution, a documentation tend to change in time, with links no longer
>>>> being valid.
>>>>
>>>>
>>>> Lot of projects publish generated documentation separately, hosting it
>>>> e.g. on docs.jboss.org (see [2] for a sample).
>>>>
>>>> I'd suggest to version both, API documentation and guides on a
>>>> separated server.
>>>> Perhaps we could version whole site?
>>>>
>>>>
>>>>
>>>> WDYT?
>>>>
>>>>
>>>> Cheers,
>>>>
>>>> ~ Lukas
>>>>
>>>> [1]
>>>> http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-UnifiedPush-Server-1-1-0-beta-1-tp11665p11672.html
>>>> [2] http://docs.jboss.org/richfaces/
>>>>
>>>> _______________________________________________
>>>> aerogear-dev mailing list
>>>> aerogear-dev at lists.jboss.org
>>>> https://lists.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/20150527/720fb692/attachment.html 

From bruno at abstractj.org  Wed May 27 10:07:16 2015
From: bruno at abstractj.org (Bruno Oliveira)
Date: Wed, 27 May 2015 11:07:16 -0300
Subject: [aerogear-dev] Versioning Documentation
In-Reply-To: <CAEroY35p9_G5U_bV-vZSYOc4Fzdfv4JiSYpx_PMt1WAPbKBRiA@mail.gmail.com>
References: <CAEroY35p9_G5U_bV-vZSYOc4Fzdfv4JiSYpx_PMt1WAPbKBRiA@mail.gmail.com>
Message-ID: <CAM5SUC7n7zMDAc+mfBhyky_oJ1cCQaWL44e3Z6m9yOG334Zajw@mail.gmail.com>

+1 go ahead

On Tue, May 26, 2015 at 8:58 AM, Luk?? Fry? <lukas at fryc.eu> wrote:

> Hey guys,
>
> Tadeas started a discussion about versioning documentation in the thread
> [1],
>
>
> and I must agree - it is a good idea to version documentation (and
> possibly also guides),
>
> especially since our UPS Console now points from the UI to the
> documentation -
> that is a great feature but I'm worried about maintanance of that
> solution, a documentation tend to change in time, with links no longer
> being valid.
>
>
> Lot of projects publish generated documentation separately, hosting it
> e.g. on docs.jboss.org (see [2] for a sample).
>
> I'd suggest to version both, API documentation and guides on a separated
> server.
> Perhaps we could version whole site?
>
>
>
> WDYT?
>
>
> Cheers,
>
> ~ Lukas
>
> [1]
> http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-UnifiedPush-Server-1-1-0-beta-1-tp11665p11672.html
> [2] http://docs.jboss.org/richfaces/
>
> _______________________________________________
> 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/20150527/aae51908/attachment-0001.html 

From bruno at abstractj.org  Wed May 27 10:09:13 2015
From: bruno at abstractj.org (Bruno Oliveira)
Date: Wed, 27 May 2015 11:09:13 -0300
Subject: [aerogear-dev] Parent 0.2.15 -> staging
In-Reply-To: <CAAg5f2QiU9Z7s_Dx5qyW5_apU8-cTe9srvDjS7q5jGeiwBoByw@mail.gmail.com>
References: <CAAg5f2QiU9Z7s_Dx5qyW5_apU8-cTe9srvDjS7q5jGeiwBoByw@mail.gmail.com>
Message-ID: <CAM5SUC44SMndMcR+6AByEu6nJHDe040ThD7D4+WAfbAex1ei2g@mail.gmail.com>

Ship it!

On Wed, May 27, 2015 at 10:43 AM, Matthias Wessendorf <matzew at apache.org>
wrote:

> Ahoy!
>
> A new release of aerogear-parent was staged at:
>
> https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-5639/
>
> I'm considering to release it on Friday, after some feedback. If you want
> the release to be postoned to another day, let me know.
>
> -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
>



-- 

-- 
"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/20150527/af14ee69/attachment.html 

From avibelli at redhat.com  Wed May 27 10:34:59 2015
From: avibelli at redhat.com (Andrea Vibelli)
Date: Wed, 27 May 2015 07:34:59 -0700 (MST)
Subject: [aerogear-dev] Missing instruction in Android Aerogear Guides
In-Reply-To: <CAEQz2CtRfMath_QbDe9Ym47aYjdHJai9VJkiFR2woQ7AkuXN7A@mail.gmail.com>
References: <1432732241663-11692.post@n5.nabble.com>
	<CAEQz2CtRfMath_QbDe9Ym47aYjdHJai9VJkiFR2woQ7AkuXN7A@mail.gmail.com>
Message-ID: <1432737299764-11698.post@n5.nabble.com>

Yes, thanks!

Andrea
Summers Pittman wrote
> On Wed, May 27, 2015 at 9:10 AM, Andrea Vibelli &lt;

> avibelli@

> &gt; wrote:
> 
>> Hi all,
>> after having followed the Aerogear Guide for Android
>> (
>> https://aerogear.org/docs/guides/aerogear-android/how-to-build-aerogear-android/
>> ),
>> I encountered an error while building the aerogear-android-push SDK:
>>
>> /Could not resolve dependencies for project
>> org.jboss.aerogear:aerogear-android-push:aar:2.2.0-SNAPSHOT: Failure to
>> find
>> com.google.android.gms:play-services:aar:6.1.11 /
>>
>> It turned out that I needed to install the Google Repository in order to
>> have that dependency, so I believe it should be added in the guide
>> (fourth
>> bullet point in the Prereqs):
>>
>> Latest Android Support Library, Google Play Services and Google
>> Repository.
>>
> https://github.com/secondsun/aerogear.org/tree/android_add_repo_req
> ^^^ Does this look right?
> 
>>
>> Thanks!
>> Andrea
>>
>>
>>
>> --
>> View this message in context:
>> http://aerogear-dev.1069024.n5.nabble.com/Missing-instruction-in-Android-Aerogear-Guides-tp11692.html
>> Sent from the aerogear-dev mailing list archive at Nabble.com.
>> _______________________________________________
>> aerogear-dev mailing list
>> 

> aerogear-dev at .jboss

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

> aerogear-dev at .jboss

> https://lists.jboss.org/mailman/listinfo/aerogear-dev





--
View this message in context: http://aerogear-dev.1069024.n5.nabble.com/Missing-instruction-in-Android-Aerogear-Guides-tp11692p11698.html
Sent from the aerogear-dev mailing list archive at Nabble.com.

From lukas.fryc at gmail.com  Wed May 27 10:50:59 2015
From: lukas.fryc at gmail.com (=?UTF-8?B?THVrw6HFoSBGcnnEjQ==?=)
Date: Wed, 27 May 2015 14:50:59 +0000
Subject: [aerogear-dev] Versioning Documentation
In-Reply-To: <CAM5SUC7n7zMDAc+mfBhyky_oJ1cCQaWL44e3Z6m9yOG334Zajw@mail.gmail.com>
References: <CAEroY35p9_G5U_bV-vZSYOc4Fzdfv4JiSYpx_PMt1WAPbKBRiA@mail.gmail.com>
	<CAM5SUC7n7zMDAc+mfBhyky_oJ1cCQaWL44e3Z6m9yOG334Zajw@mail.gmail.com>
Message-ID: <CAEroY35DChcR_Ss8dhB2PzxUCysiMeBsxz9U-ZAjX2VT6V0Zig@mail.gmail.com>

I've created this issue: https://issues.jboss.org/browse/AEROGEAR-1686

One problem we will have to overcome is that we have many different modules
versioned differently, so we can't simply version whole site as it is. This
will need some cleverish idea :-)

st 27. 5. 2015 v 16:08 odes?latel Bruno Oliveira <bruno at abstractj.org>
napsal:

> +1 go ahead
>
> On Tue, May 26, 2015 at 8:58 AM, Luk?? Fry? <lukas at fryc.eu> wrote:
>
>> Hey guys,
>>
>> Tadeas started a discussion about versioning documentation in the thread
>> [1],
>>
>>
>> and I must agree - it is a good idea to version documentation (and
>> possibly also guides),
>>
>> especially since our UPS Console now points from the UI to the
>> documentation -
>> that is a great feature but I'm worried about maintanance of that
>> solution, a documentation tend to change in time, with links no longer
>> being valid.
>>
>>
>> Lot of projects publish generated documentation separately, hosting it
>> e.g. on docs.jboss.org (see [2] for a sample).
>>
>> I'd suggest to version both, API documentation and guides on a separated
>> server.
>> Perhaps we could version whole site?
>>
>>
>>
>> WDYT?
>>
>>
>> Cheers,
>>
>> ~ Lukas
>>
>> [1]
>> http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-UnifiedPush-Server-1-1-0-beta-1-tp11665p11672.html
>> [2] http://docs.jboss.org/richfaces/
>>
>> _______________________________________________
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20150527/ed6f9657/attachment.html 

From delalis at gmail.com  Wed May 27 13:52:31 2015
From: delalis at gmail.com (delalis)
Date: Wed, 27 May 2015 10:52:31 -0700 (MST)
Subject: [aerogear-dev] Aerogear UPS 1.0.3 - Wildfly server error on
 login
In-Reply-To: <1432732230444-11691.post@n5.nabble.com>
References: <1432647421048-11683.post@n5.nabble.com>
	<CAAg5f2THGNL8dSu3McMv3YPWHTr2rZCgug0UyMTE8uCV=COxKQ@mail.gmail.com>
	<1432732230444-11691.post@n5.nabble.com>
Message-ID: <1432749151797-11700.post@n5.nabble.com>

nevermind, instead of using CYGWIN, I simple ran the ups-migrator like so: 


java -classpath "C:\path_to_jar/ups-migrator.jar
-Dliquibase.databaseChangeLogTableName="ups_db_changelog"
-Dliquibase.databaseChangeLogLockTableName="ups_db_changeloglock"
liquibase.integration.commandline.Main "--defaultsFile=liquibase.properties"
update

and then rebooted the JBOSS server in order for the keycloak to create the
required tables (i.e. realm table etc) after rebooting jboss the numebr of
SQL tables increased from 14 to 43.



--
View this message in context: http://aerogear-dev.1069024.n5.nabble.com/Aerogear-UPS-1-0-3-Wildfly-server-error-on-login-tp11683p11700.html
Sent from the aerogear-dev mailing list archive at Nabble.com.

From delalis at gmail.com  Wed May 27 13:58:45 2015
From: delalis at gmail.com (delalis)
Date: Wed, 27 May 2015 10:58:45 -0700 (MST)
Subject: [aerogear-dev] aerogear UPS 1.0.3 - PUSH NOTIFICATIONS DONT SHOW UP
	ON DEVICES
Message-ID: <1432749525522-11701.post@n5.nabble.com>

Hi again, hopefully this will be my last post requiring help, I have
successfully set up Aerogear and have 4 devices registered in 4 different
variants (2 android, two apple.

I sent some test notifications and the Aerogear logs say that it was
successfully sent to both APNs and GCM, but my devices are not receiving the
push notifications...

See this log...looks good to me, no idea why the registered devices arent
receiving the pushes...not sure how to debug further at this point...any
help would be greatly appreciated!

https://gist.github.com/delalis/3338a2801d8aa1298eb0



--
View this message in context: http://aerogear-dev.1069024.n5.nabble.com/aerogear-UPS-1-0-3-PUSH-NOTIFICATIONS-DONT-SHOW-UP-ON-DEVICES-tp11701.html
Sent from the aerogear-dev mailing list archive at Nabble.com.

From delalis at gmail.com  Wed May 27 14:24:48 2015
From: delalis at gmail.com (delalis)
Date: Wed, 27 May 2015 11:24:48 -0700 (MST)
Subject: [aerogear-dev] aerogear UPS 1.0.3 - PUSH NOTIFICATIONS DONT
	SHOW UP ON DEVICES
In-Reply-To: <1432749525522-11701.post@n5.nabble.com>
References: <1432749525522-11701.post@n5.nabble.com>
Message-ID: <1432751088164-11702.post@n5.nabble.com>

update, I got apple working successfully by using a development profile and
also making sure the aerogear variant was set to "development"...

doesnt explain why GCM pushes arent going through though.  Aerogear doesnt
have a development versus production radio button option.


Any ideas?



--
View this message in context: http://aerogear-dev.1069024.n5.nabble.com/aerogear-UPS-1-0-3-PUSH-NOTIFICATIONS-DONT-SHOW-UP-ON-DEVICES-tp11701p11702.html
Sent from the aerogear-dev mailing list archive at Nabble.com.

From scm.blanc at gmail.com  Wed May 27 14:33:00 2015
From: scm.blanc at gmail.com (Sebastien Blanc)
Date: Wed, 27 May 2015 20:33:00 +0200
Subject: [aerogear-dev] aerogear UPS 1.0.3 - PUSH NOTIFICATIONS DONT
 SHOW UP ON DEVICES
In-Reply-To: <1432749525522-11701.post@n5.nabble.com>
References: <1432749525522-11701.post@n5.nabble.com>
Message-ID: <CAD_dpu0Sgeok48v-as0SUi_NCUWBK8akszpRUEfFH77Sjz=Cwg@mail.gmail.com>

I saw on IRC that you managed to get APNs working, great :)
But you still have issues for Android, could check the logcat of your
devices to be sure you're message is not arriving and that maybe the
problem is somewhere else in your client code ?

Bonne chance !

Sebi


On Wed, May 27, 2015 at 7:58 PM, delalis <delalis at gmail.com> wrote:

> Hi again, hopefully this will be my last post requiring help, I have
> successfully set up Aerogear and have 4 devices registered in 4 different
> variants (2 android, two apple.
>
> I sent some test notifications and the Aerogear logs say that it was
> successfully sent to both APNs and GCM, but my devices are not receiving
> the
> push notifications...
>
> See this log...looks good to me, no idea why the registered devices arent
> receiving the pushes...not sure how to debug further at this point...any
> help would be greatly appreciated!
>
> https://gist.github.com/delalis/3338a2801d8aa1298eb0
>
>
>
> --
> View this message in context:
> http://aerogear-dev.1069024.n5.nabble.com/aerogear-UPS-1-0-3-PUSH-NOTIFICATIONS-DONT-SHOW-UP-ON-DEVICES-tp11701.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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20150527/bef73204/attachment-0001.html 

From dpassos at redhat.com  Wed May 27 14:33:19 2015
From: dpassos at redhat.com (Daniel Passos)
Date: Wed, 27 May 2015 15:33:19 -0300
Subject: [aerogear-dev] Missing instruction in Android Aerogear Guides
In-Reply-To: <1432737299764-11698.post@n5.nabble.com>
References: <1432732241663-11692.post@n5.nabble.com>
	<CAEQz2CtRfMath_QbDe9Ym47aYjdHJai9VJkiFR2woQ7AkuXN7A@mail.gmail.com>
	<1432737299764-11698.post@n5.nabble.com>
Message-ID: <CADF=h2vNd4B9oQ9b5bSBj1OZ=RjURkupg-pKE5fci-=1gOguFQ@mail.gmail.com>

Merged. I also fixed some format :D

On Wed, May 27, 2015 at 11:34 AM, Andrea Vibelli <avibelli at redhat.com>
wrote:

> Yes, thanks!
>
> Andrea
> Summers Pittman wrote
> > On Wed, May 27, 2015 at 9:10 AM, Andrea Vibelli &lt;
>
> > avibelli@
>
> > &gt; wrote:
> >
> >> Hi all,
> >> after having followed the Aerogear Guide for Android
> >> (
> >>
> https://aerogear.org/docs/guides/aerogear-android/how-to-build-aerogear-android/
> >> ),
> >> I encountered an error while building the aerogear-android-push SDK:
> >>
> >> /Could not resolve dependencies for project
> >> org.jboss.aerogear:aerogear-android-push:aar:2.2.0-SNAPSHOT: Failure to
> >> find
> >> com.google.android.gms:play-services:aar:6.1.11 /
> >>
> >> It turned out that I needed to install the Google Repository in order to
> >> have that dependency, so I believe it should be added in the guide
> >> (fourth
> >> bullet point in the Prereqs):
> >>
> >> Latest Android Support Library, Google Play Services and Google
> >> Repository.
> >>
> > https://github.com/secondsun/aerogear.org/tree/android_add_repo_req
> > ^^^ Does this look right?
> >
> >>
> >> Thanks!
> >> Andrea
> >>
> >>
> >>
> >> --
> >> View this message in context:
> >>
> http://aerogear-dev.1069024.n5.nabble.com/Missing-instruction-in-Android-Aerogear-Guides-tp11692.html
> >> Sent from the aerogear-dev mailing list archive at Nabble.com.
> >> _______________________________________________
> >> aerogear-dev mailing list
> >>
>
> > aerogear-dev at .jboss
>
> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >>
> >
> > _______________________________________________
> > aerogear-dev mailing list
>
> > aerogear-dev at .jboss
>
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
>
>
> --
> View this message in context:
> http://aerogear-dev.1069024.n5.nabble.com/Missing-instruction-in-Android-Aerogear-Guides-tp11692p11698.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
>



-- 
-- Passos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20150527/4581b81e/attachment.html 

From dpassos at redhat.com  Wed May 27 14:34:56 2015
From: dpassos at redhat.com (Daniel Passos)
Date: Wed, 27 May 2015 15:34:56 -0300
Subject: [aerogear-dev] aerogear UPS 1.0.3 - PUSH NOTIFICATIONS DONT
 SHOW UP ON DEVICES
In-Reply-To: <CAD_dpu0Sgeok48v-as0SUi_NCUWBK8akszpRUEfFH77Sjz=Cwg@mail.gmail.com>
References: <1432749525522-11701.post@n5.nabble.com>
	<CAD_dpu0Sgeok48v-as0SUi_NCUWBK8akszpRUEfFH77Sjz=Cwg@mail.gmail.com>
Message-ID: <CADF=h2shbbfSyeFPJO9Wgzp_vDrx2V0fB7rEgZ5_=M_s4XHEBA@mail.gmail.com>

Or test using this app =>
https://github.com/jboss-mobile/unified-push-helloworld/tree/master/android

On Wed, May 27, 2015 at 3:33 PM, Sebastien Blanc <scm.blanc at gmail.com>
wrote:

> I saw on IRC that you managed to get APNs working, great :)
> But you still have issues for Android, could check the logcat of your
> devices to be sure you're message is not arriving and that maybe the
> problem is somewhere else in your client code ?
>
> Bonne chance !
>
> Sebi
>
>
> On Wed, May 27, 2015 at 7:58 PM, delalis <delalis at gmail.com> wrote:
>
>> Hi again, hopefully this will be my last post requiring help, I have
>> successfully set up Aerogear and have 4 devices registered in 4 different
>> variants (2 android, two apple.
>>
>> I sent some test notifications and the Aerogear logs say that it was
>> successfully sent to both APNs and GCM, but my devices are not receiving
>> the
>> push notifications...
>>
>> See this log...looks good to me, no idea why the registered devices arent
>> receiving the pushes...not sure how to debug further at this point...any
>> help would be greatly appreciated!
>>
>> https://gist.github.com/delalis/3338a2801d8aa1298eb0
>>
>>
>>
>> --
>> View this message in context:
>> http://aerogear-dev.1069024.n5.nabble.com/aerogear-UPS-1-0-3-PUSH-NOTIFICATIONS-DONT-SHOW-UP-ON-DEVICES-tp11701.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
>>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>



-- 
-- Passos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20150527/409987b9/attachment.html 

From delalis at gmail.com  Wed May 27 14:38:08 2015
From: delalis at gmail.com (delalis)
Date: Wed, 27 May 2015 11:38:08 -0700 (MST)
Subject: [aerogear-dev] aerogear UPS 1.0.3 - PUSH NOTIFICATIONS DONT
 SHOW UP ON DEVICES
In-Reply-To: <CADF=h2shbbfSyeFPJO9Wgzp_vDrx2V0fB7rEgZ5_=M_s4XHEBA@mail.gmail.com>
References: <1432749525522-11701.post@n5.nabble.com>
	<CAD_dpu0Sgeok48v-as0SUi_NCUWBK8akszpRUEfFH77Sjz=Cwg@mail.gmail.com>
	<CADF=h2shbbfSyeFPJO9Wgzp_vDrx2V0fB7rEgZ5_=M_s4XHEBA@mail.gmail.com>
Message-ID: <1432751888280-11706.post@n5.nabble.com>

Thanks guys, I will have a look tomorrow morning and let you know on this
thread.  



--
View this message in context: http://aerogear-dev.1069024.n5.nabble.com/aerogear-UPS-1-0-3-PUSH-NOTIFICATIONS-DONT-SHOW-UP-ON-DEVICES-tp11701p11706.html
Sent from the aerogear-dev mailing list archive at Nabble.com.

From corinnekrych at gmail.com  Thu May 28 02:14:22 2015
From: corinnekrych at gmail.com (Corinne Krych)
Date: Thu, 28 May 2015 08:14:22 +0200
Subject: [aerogear-dev] Versioning Documentation
In-Reply-To: <CAEroY35DChcR_Ss8dhB2PzxUCysiMeBsxz9U-ZAjX2VT6V0Zig@mail.gmail.com>
References: <CAEroY35p9_G5U_bV-vZSYOc4Fzdfv4JiSYpx_PMt1WAPbKBRiA@mail.gmail.com>
	<CAM5SUC7n7zMDAc+mfBhyky_oJ1cCQaWL44e3Z6m9yOG334Zajw@mail.gmail.com>
	<CAEroY35DChcR_Ss8dhB2PzxUCysiMeBsxz9U-ZAjX2VT6V0Zig@mail.gmail.com>
Message-ID: <CAL8vO=e0aq12=y3i7fxNOzN6dxTvD-RPsW5r0NSanu5GyH08ZA@mail.gmail.com>

We can have an site umbrella versionning but it would be good to know let's
say for example UPS 1.1.0 guide is in aerogear.org 2.6.0

wdyt?
++
Corinne

On 27 May 2015 at 16:50, Luk?? Fry? <lukas.fryc at gmail.com> wrote:

> I've created this issue: https://issues.jboss.org/browse/AEROGEAR-1686
>
> One problem we will have to overcome is that we have many different
> modules versioned differently, so we can't simply version whole site as it
> is. This will need some cleverish idea :-)
>
> st 27. 5. 2015 v 16:08 odes?latel Bruno Oliveira <bruno at abstractj.org>
> napsal:
>
>> +1 go ahead
>>
>> On Tue, May 26, 2015 at 8:58 AM, Luk?? Fry? <lukas at fryc.eu> wrote:
>>
>>> Hey guys,
>>>
>>> Tadeas started a discussion about versioning documentation in the thread
>>> [1],
>>>
>>>
>>> and I must agree - it is a good idea to version documentation (and
>>> possibly also guides),
>>>
>>> especially since our UPS Console now points from the UI to the
>>> documentation -
>>> that is a great feature but I'm worried about maintanance of that
>>> solution, a documentation tend to change in time, with links no longer
>>> being valid.
>>>
>>>
>>> Lot of projects publish generated documentation separately, hosting it
>>> e.g. on docs.jboss.org (see [2] for a sample).
>>>
>>> I'd suggest to version both, API documentation and guides on a separated
>>> server.
>>> Perhaps we could version whole site?
>>>
>>>
>>>
>>> WDYT?
>>>
>>>
>>> Cheers,
>>>
>>> ~ Lukas
>>>
>>> [1]
>>> http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-UnifiedPush-Server-1-1-0-beta-1-tp11665p11672.html
>>> [2] http://docs.jboss.org/richfaces/
>>>
>>> _______________________________________________
>>> 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
>
>
> _______________________________________________
> 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/20150528/e914cffa/attachment.html 

From lukas at fryc.eu  Thu May 28 03:22:01 2015
From: lukas at fryc.eu (=?UTF-8?B?THVrw6HFoSBGcnnEjQ==?=)
Date: Thu, 28 May 2015 09:22:01 +0200
Subject: [aerogear-dev] Versioning Documentation
In-Reply-To: <CAL8vO=e0aq12=y3i7fxNOzN6dxTvD-RPsW5r0NSanu5GyH08ZA@mail.gmail.com>
References: <CAEroY35p9_G5U_bV-vZSYOc4Fzdfv4JiSYpx_PMt1WAPbKBRiA@mail.gmail.com>
	<CAM5SUC7n7zMDAc+mfBhyky_oJ1cCQaWL44e3Z6m9yOG334Zajw@mail.gmail.com>
	<CAEroY35DChcR_Ss8dhB2PzxUCysiMeBsxz9U-ZAjX2VT6V0Zig@mail.gmail.com>
	<CAL8vO=e0aq12=y3i7fxNOzN6dxTvD-RPsW5r0NSanu5GyH08ZA@mail.gmail.com>
Message-ID: <CAEroY36VMzBy+znYC70j0QGycDRh-J5D6eD4uQKYw0c-CqPodQ@mail.gmail.com>

Yes,

That would work if we have some kind of mapping.

I guess we could find lot of information from commit history, maybe having
tags specific to each versioned component and then jekyll plugin that can
make sense from it.
On May 28, 2015 8:14 AM, "Corinne Krych" <corinnekrych at gmail.com> wrote:

> We can have an site umbrella versionning but it would be good to know
> let's say for example UPS 1.1.0 guide is in aerogear.org 2.6.0
>
> wdyt?
> ++
> Corinne
>
> On 27 May 2015 at 16:50, Luk?? Fry? <lukas.fryc at gmail.com> wrote:
>
>> I've created this issue: https://issues.jboss.org/browse/AEROGEAR-1686
>>
>> One problem we will have to overcome is that we have many different
>> modules versioned differently, so we can't simply version whole site as it
>> is. This will need some cleverish idea :-)
>>
>> st 27. 5. 2015 v 16:08 odes?latel Bruno Oliveira <bruno at abstractj.org>
>> napsal:
>>
>>> +1 go ahead
>>>
>>> On Tue, May 26, 2015 at 8:58 AM, Luk?? Fry? <lukas at fryc.eu> wrote:
>>>
>>>> Hey guys,
>>>>
>>>> Tadeas started a discussion about versioning documentation in the
>>>> thread [1],
>>>>
>>>>
>>>> and I must agree - it is a good idea to version documentation (and
>>>> possibly also guides),
>>>>
>>>> especially since our UPS Console now points from the UI to the
>>>> documentation -
>>>> that is a great feature but I'm worried about maintanance of that
>>>> solution, a documentation tend to change in time, with links no longer
>>>> being valid.
>>>>
>>>>
>>>> Lot of projects publish generated documentation separately, hosting it
>>>> e.g. on docs.jboss.org (see [2] for a sample).
>>>>
>>>> I'd suggest to version both, API documentation and guides on a
>>>> separated server.
>>>> Perhaps we could version whole site?
>>>>
>>>>
>>>>
>>>> WDYT?
>>>>
>>>>
>>>> Cheers,
>>>>
>>>> ~ Lukas
>>>>
>>>> [1]
>>>> http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-UnifiedPush-Server-1-1-0-beta-1-tp11665p11672.html
>>>> [2] http://docs.jboss.org/richfaces/
>>>>
>>>> _______________________________________________
>>>> 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
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.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/20150528/ef09ad80/attachment-0001.html 

From edewit at redhat.com  Thu May 28 05:25:39 2015
From: edewit at redhat.com (Erik Jan de Wit)
Date: Thu, 28 May 2015 11:25:39 +0200
Subject: [aerogear-dev] Android 2.x and cordova
Message-ID: <CAO2B-fbXPVW1sibkA3kSeDYk5ANk7JzmyG=7-3Lk1QFf=j4_fQ@mail.gmail.com>

Hi,

We are going to add metric support to the cordova push plugin. This
functionality was introduced in the 2.x version of the android push
lib. The android 2.x version uses 'aar' for packaging. This means the
new version can only be used with cordova android platform 4.0 as that
introduced 'aar' framework support.

Or we use a source include, we do that for the oauth2 plugin, it might
also open the option to get inclusion into phonegap build as binary
dependencies are not allowed there.

For the metrics in cordova we can make it super easy and fully
automatic all you'll have to do is add "sendMetricInfo": true in your
pushConfig:

var pushConfig = {
   pushServerURL: "http://localhost:8080/ag-push",
   sendMetricInfo: true,
   android: {
      senderID: "<senderID 123>",
      variantID: "<variantID e.g. 1234456-234320>",
      variantSecret: "<variantSecret e.g. 1234456-234320>"
  },
   ios: {
      variantID: "<variantID e.g. 1234456-234320>",
      variantSecret: "<variantSecret e.g. 1234456-234320>"
   }
};

-- 
Cheers,
       Erik Jan

From supittma at redhat.com  Thu May 28 10:26:12 2015
From: supittma at redhat.com (Summers Pittman)
Date: Thu, 28 May 2015 10:26:12 -0400
Subject: [aerogear-dev] Android 2.x and cordova
In-Reply-To: <CAO2B-fbXPVW1sibkA3kSeDYk5ANk7JzmyG=7-3Lk1QFf=j4_fQ@mail.gmail.com>
References: <CAO2B-fbXPVW1sibkA3kSeDYk5ANk7JzmyG=7-3Lk1QFf=j4_fQ@mail.gmail.com>
Message-ID: <CAEQz2Cvjh2F15PAX+7qGfdrZPVOifoB_Y38r-U3wM_VK7Gkyww@mail.gmail.com>

On Thu, May 28, 2015 at 5:25 AM, Erik Jan de Wit <edewit at redhat.com> wrote:

> Hi,
>
> We are going to add metric support to the cordova push plugin. This
> functionality was introduced in the 2.x version of the android push
> lib. The android 2.x version uses 'aar' for packaging. This means the
> new version can only be used with cordova android platform 4.0 as that
> introduced 'aar' framework support.
>
> Or we use a source include, we do that for the oauth2 plugin, it might
> also open the option to get inclusion into phonegap build as binary
> dependencies are not allowed there.
>
>
I may be showing my Java bias but upgrading to Cordova 4 and leaning
against the aar sounds the most "correct".

However if doing a source include is not a maintenance nightmare (IE
someone has to manually update the sources all the time) AND it gets us in
phonegap's official packaging system then +1 to that.

For the metrics in cordova we can make it super easy and fully
> automatic all you'll have to do is add "sendMetricInfo": true in your
> pushConfig:


> var pushConfig = {
>    pushServerURL: "http://localhost:8080/ag-push",
>    sendMetricInfo: true,
>    android: {
>       senderID: "<senderID 123>",
>       variantID: "<variantID e.g. 1234456-234320>",
>       variantSecret: "<variantSecret e.g. 1234456-234320>"
>   },
>    ios: {
>       variantID: "<variantID e.g. 1234456-234320>",
>       variantSecret: "<variantSecret e.g. 1234456-234320>"
>    }
> };
>
> I thought that a requirement of metrics was that it is the developer who
picks when to send them not the library?

> --
> Cheers,
>        Erik Jan
> _______________________________________________
> 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/20150528/111850f9/attachment.html 

From edewit at redhat.com  Thu May 28 10:33:13 2015
From: edewit at redhat.com (Erik Jan de Wit)
Date: Thu, 28 May 2015 16:33:13 +0200
Subject: [aerogear-dev] Android 2.x and cordova
In-Reply-To: <CAEQz2Cvjh2F15PAX+7qGfdrZPVOifoB_Y38r-U3wM_VK7Gkyww@mail.gmail.com>
References: <CAO2B-fbXPVW1sibkA3kSeDYk5ANk7JzmyG=7-3Lk1QFf=j4_fQ@mail.gmail.com>
	<CAEQz2Cvjh2F15PAX+7qGfdrZPVOifoB_Y38r-U3wM_VK7Gkyww@mail.gmail.com>
Message-ID: <CAO2B-fZsZvGxQDEAJB2PcESLdBgyuKkF+AMjz83Akuwzrm+EFQ@mail.gmail.com>

>
> I may be showing my Java bias but upgrading to Cordova 4 and leaning against
> the aar sounds the most "correct".

Right I'm leaning more to this one as well.

> However if doing a source include is not a maintenance nightmare (IE someone
> has to manually update the sources all the time) AND it gets us in
> phonegap's official packaging system then +1 to that.

Especially for push it still might be hard as they have there
'official' push plugin.

> I thought that a requirement of metrics was that it is the developer who
> picks when to send them not the library?

It could be automatic it doesn't need to be, default would be that it
doesn't send metrics information and by adding sendMetricInfo to true
you would enable it.

From matzew at apache.org  Fri May 29 02:18:16 2015
From: matzew at apache.org (Matthias Wessendorf)
Date: Fri, 29 May 2015 08:18:16 +0200
Subject: [aerogear-dev] Android 2.x and cordova
In-Reply-To: <CAO2B-fZsZvGxQDEAJB2PcESLdBgyuKkF+AMjz83Akuwzrm+EFQ@mail.gmail.com>
References: <CAO2B-fbXPVW1sibkA3kSeDYk5ANk7JzmyG=7-3Lk1QFf=j4_fQ@mail.gmail.com>
	<CAEQz2Cvjh2F15PAX+7qGfdrZPVOifoB_Y38r-U3wM_VK7Gkyww@mail.gmail.com>
	<CAO2B-fZsZvGxQDEAJB2PcESLdBgyuKkF+AMjz83Akuwzrm+EFQ@mail.gmail.com>
Message-ID: <CAAg5f2QLb+h-ag1QttDXi77Yxhj9iZswfnhDgJTaO=4KVki8Dg@mail.gmail.com>

On Thursday, May 28, 2015, Erik Jan de Wit <edewit at redhat.com> wrote:

> >
> > I may be showing my Java bias but upgrading to Cordova 4 and leaning
> against
> > the aar sounds the most "correct".
>
> Right I'm leaning more to this one as well.


+1


>
> > However if doing a source include is not a maintenance nightmare (IE
> someone
> > has to manually update the sources all the time) AND it gets us in
> > phonegap's official packaging system then +1 to that.
>
> Especially for push it still might be hard as they have there
> 'official' push plugin.
>
> > I thought that a requirement of metrics was that it is the developer who
> > picks when to send them not the library?
>
> It could be automatic it doesn't need to be, default would be that it
> doesn't send metrics information and by adding sendMetricInfo to true
> you would enable it.
> _______________________________________________
> 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/20150529/120294f4/attachment.html 

From edewit at redhat.com  Fri May 29 04:15:09 2015
From: edewit at redhat.com (Erik Jan de Wit)
Date: Fri, 29 May 2015 10:15:09 +0200
Subject: [aerogear-dev] Android 2.x and cordova
In-Reply-To: <CAAg5f2QLb+h-ag1QttDXi77Yxhj9iZswfnhDgJTaO=4KVki8Dg@mail.gmail.com>
References: <CAO2B-fbXPVW1sibkA3kSeDYk5ANk7JzmyG=7-3Lk1QFf=j4_fQ@mail.gmail.com>
	<CAEQz2Cvjh2F15PAX+7qGfdrZPVOifoB_Y38r-U3wM_VK7Gkyww@mail.gmail.com>
	<CAO2B-fZsZvGxQDEAJB2PcESLdBgyuKkF+AMjz83Akuwzrm+EFQ@mail.gmail.com>
	<CAAg5f2QLb+h-ag1QttDXi77Yxhj9iZswfnhDgJTaO=4KVki8Dg@mail.gmail.com>
Message-ID: <CAO2B-fYKHaNgmumW1qG7UMA3OWVz2J0EV6NCLvm7aZTRUTXxMg@mail.gmail.com>

The support is even better then I had anticipated, one can add a
gradle script that gets injected into the main gradle file, this means
the plugin doesn't even have to have the libraries but they can be
fetched from maven at build time.

So I'm totally picking this option as it's the best of both worlds


On Fri, May 29, 2015 at 8:18 AM, Matthias Wessendorf <matzew at apache.org> wrote:
>
>
> On Thursday, May 28, 2015, Erik Jan de Wit <edewit at redhat.com> wrote:
>>
>> >
>> > I may be showing my Java bias but upgrading to Cordova 4 and leaning
>> > against
>> > the aar sounds the most "correct".
>>
>> Right I'm leaning more to this one as well.
>
>
> +1
>
>>
>>
>> > However if doing a source include is not a maintenance nightmare (IE
>> > someone
>> > has to manually update the sources all the time) AND it gets us in
>> > phonegap's official packaging system then +1 to that.
>>
>> Especially for push it still might be hard as they have there
>> 'official' push plugin.
>>
>> > I thought that a requirement of metrics was that it is the developer who
>> > picks when to send them not the library?
>>
>> It could be automatic it doesn't need to be, default would be that it
>> doesn't send metrics information and by adding sendMetricInfo to true
>> you would enable it.
>> _______________________________________________
>> 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



-- 
Cheers,
       Erik Jan

From matzew at apache.org  Fri May 29 04:28:27 2015
From: matzew at apache.org (Matthias Wessendorf)
Date: Fri, 29 May 2015 10:28:27 +0200
Subject: [aerogear-dev] Android 2.x and cordova
In-Reply-To: <CAO2B-fYKHaNgmumW1qG7UMA3OWVz2J0EV6NCLvm7aZTRUTXxMg@mail.gmail.com>
References: <CAO2B-fbXPVW1sibkA3kSeDYk5ANk7JzmyG=7-3Lk1QFf=j4_fQ@mail.gmail.com>
	<CAEQz2Cvjh2F15PAX+7qGfdrZPVOifoB_Y38r-U3wM_VK7Gkyww@mail.gmail.com>
	<CAO2B-fZsZvGxQDEAJB2PcESLdBgyuKkF+AMjz83Akuwzrm+EFQ@mail.gmail.com>
	<CAAg5f2QLb+h-ag1QttDXi77Yxhj9iZswfnhDgJTaO=4KVki8Dg@mail.gmail.com>
	<CAO2B-fYKHaNgmumW1qG7UMA3OWVz2J0EV6NCLvm7aZTRUTXxMg@mail.gmail.com>
Message-ID: <CAAg5f2RhU8-7rDEttt4Pd6Ggt=aWcDL2aTti=pQRJu-oRqST+A@mail.gmail.com>

great, thanks for the updates

On Fri, May 29, 2015 at 10:15 AM, Erik Jan de Wit <edewit at redhat.com> wrote:

> The support is even better then I had anticipated, one can add a
> gradle script that gets injected into the main gradle file, this means
> the plugin doesn't even have to have the libraries but they can be
> fetched from maven at build time.
>
> So I'm totally picking this option as it's the best of both worlds
>
>
> On Fri, May 29, 2015 at 8:18 AM, Matthias Wessendorf <matzew at apache.org>
> wrote:
> >
> >
> > On Thursday, May 28, 2015, Erik Jan de Wit <edewit at redhat.com> wrote:
> >>
> >> >
> >> > I may be showing my Java bias but upgrading to Cordova 4 and leaning
> >> > against
> >> > the aar sounds the most "correct".
> >>
> >> Right I'm leaning more to this one as well.
> >
> >
> > +1
> >
> >>
> >>
> >> > However if doing a source include is not a maintenance nightmare (IE
> >> > someone
> >> > has to manually update the sources all the time) AND it gets us in
> >> > phonegap's official packaging system then +1 to that.
> >>
> >> Especially for push it still might be hard as they have there
> >> 'official' push plugin.
> >>
> >> > I thought that a requirement of metrics was that it is the developer
> who
> >> > picks when to send them not the library?
> >>
> >> It could be automatic it doesn't need to be, default would be that it
> >> doesn't send metrics information and by adding sendMetricInfo to true
> >> you would enable it.
> >> _______________________________________________
> >> 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
>
>
>
> --
> Cheers,
>        Erik Jan
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.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/20150529/5d7a0259/attachment-0001.html 

From bruno at abstractj.org  Fri May 29 09:09:48 2015
From: bruno at abstractj.org (Bruno Oliveira)
Date: Fri, 29 May 2015 10:09:48 -0300
Subject: [aerogear-dev] AeroGear Cordova Security Release
Message-ID: <CAM5SUC6nBCcT5-HymJqHRRWTfAkjW5a2Ki4YDyms+=1peAO4sQ@mail.gmail.com>

For details:
https://aerogear.org/news/2015/05/29/aerogear-cordova-security-release/index.html

-- 

-- 
"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/20150529/e4c7fb8d/attachment.html 

From delalis at gmail.com  Sun May 31 17:02:08 2015
From: delalis at gmail.com (delalis)
Date: Sun, 31 May 2015 14:02:08 -0700 (MST)
Subject: [aerogear-dev] Sndroid Background push notifications not working
Message-ID: <1433106128657-11716.post@n5.nabble.com>

Hello, Aerogear is sending android push notifications properly when the app
is open (foreground) on an android device and the onNotificationGCM()
function is being called successfully when the app is open.  But it is not
even putting a notification in the system notification tray when the app is
in the background or not running at all...

We are using phonegap and pushplugin on the client side and a lot of people
on google are saying that if the server is not constructing the message
payload structure properly, then Android devices will not create a
notification in the android notification tray.

Any suggestions???

here is the link I found during my research suggesting maybe Aerogear isnt
structuring message payloads properly for background notifications tray
alerts...(scroll to bottom)

http://community.phonegap.com/nitobi/topics/_pushplugin_background_notifications_dont_seem_to_work




--
View this message in context: http://aerogear-dev.1069024.n5.nabble.com/Sndroid-Background-push-notifications-not-working-tp11716.html
Sent from the aerogear-dev mailing list archive at Nabble.com.

From delalis at gmail.com  Sun May 31 17:10:39 2015
From: delalis at gmail.com (delalis)
Date: Sun, 31 May 2015 14:10:39 -0700 (MST)
Subject: [aerogear-dev] Android Background push notifications not working
In-Reply-To: <1433106128657-11716.post@n5.nabble.com>
References: <1433106128657-11716.post@n5.nabble.com>
Message-ID: <1433106639731-11717.post@n5.nabble.com>

This post also talks about a "message" variable needing to be present

http://stackoverflow.com/questions/22889969/apigee-push-notifications-on-android-not-delivered-when-app-in-background-phone

we are using Aerogear 1.0.3



--
View this message in context: http://aerogear-dev.1069024.n5.nabble.com/Android-Background-push-notifications-not-working-tp11716p11717.html
Sent from the aerogear-dev mailing list archive at Nabble.com.