3:48 p.m.
Hi all,
I have been working on a POC around geolocation. Like we discussed in
another thread, we decided not to have a "deep" integration with the Push
server but instead a separate component / microservice. Well the POC is
more a miniservice ;)
So, the idea is to have a server to which devices can register by providing
their positions. On the other side, the server provide an endpoint to make
spatial queries, like give me all the installations within a radius of 10
km around this lat/ltg.
Thanks to Forge, I created/scaffolded a really simple server providing the
registration endpoint and the search endpoint.
I tried to make a decent readme that will give you more details :
https://github.com/sebastienblanc/unified-geo-server
And as usual, I made a little screencast showing all that in action ;)
https://www.youtube.com/watch?v=R-qdLJh4EWQ
Please remember this is a POC, so the security is almost inexistant, the
console is awful ;)
What about the Client SDKs ?
If we reach some kind of consensus arounf the concept of Unfied Geo Server
we can start building the Client SDKs / POCs , they will be quite simple :
retrieve geolocation and register to the geo endpoint.
Sebi
4:23 p.m.
Really nice, looks great already, one question how do I use the data
from the geo search to send push notifications?
4:28 p.m.
On Wed, Dec 10, 2014 at 4:23 PM, Erik Jan de Wit <edewit(a)redhat.com> wrote:
Really nice, looks great already, one question how do I use the data
from the geo search to send push notifications?
When the device registers to the geo server, it also provides an
"alias".
The idea is that the developer has to use the same "alias" when registering
to the UPS, then it's up to the backend app to retrieve the aliases for the
geoserver and use these as criteria when sending a push notif to UPS.
It tried to described that here :
https://github.com/sebastienblanc/unified-geo-server#integration-with-push
One idea for the alias, is to use the Keycloak (or whatever auth system)
username as alias to have it somehow "unified"
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
4:46 p.m.
Nice work Sebastien!
If you I can help with app or console design, please let me know.
----- Original Message -----
From: "Sebastien Blanc" <scm.blanc(a)gmail.com>
To: "AeroGear Developer Mailing List" <aerogear-dev(a)lists.jboss.org>
Sent: Wednesday, December 10, 2014 12:28:43 PM
Subject: Re: [aerogear-dev] [POC] Unified Geo Server
On Wed, Dec 10, 2014 at 4:23 PM, Erik Jan de Wit < edewit(a)redhat.com > wrote:
Really nice, looks great already, one question how do I use the data
from the geo search to send push notifications?
When the device registers to the geo server, it also provides an "alias". The
idea is that the developer has to use the same "alias" when registering to the
UPS, then it's up to the backend app to retrieve the aliases for the geoserver and use
these as criteria when sending a push notif to UPS.
It tried to described that here :
https://github.com/sebastienblanc/unified-geo-server#integration-with-push
One idea for the alias, is to use the Keycloak (or whatever auth system) username as alias
to have it somehow "unified"
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
5:12 p.m.
On Wed, Dec 10, 2014 at 4:46 PM, Andres Galante <agalante(a)redhat.com> wrote:
Nice work Sebastien!
If you I can help with app or console design, please let me know.
Thanks ! A good strategy would probably to follow the Push Server and
LiveOak (Angular/patternfly) model.
----- Original Message -----
From: "Sebastien Blanc" <scm.blanc(a)gmail.com>
To: "AeroGear Developer Mailing List" <aerogear-dev(a)lists.jboss.org>
Sent: Wednesday, December 10, 2014 12:28:43 PM
Subject: Re: [aerogear-dev] [POC] Unified Geo Server
On Wed, Dec 10, 2014 at 4:23 PM, Erik Jan de Wit < edewit(a)redhat.com >
wrote:
Really nice, looks great already, one question how do I use the data
from the geo search to send push notifications?
When the device registers to the geo server, it also provides an "alias".
The idea is that the developer has to use the same "alias" when registering
to the UPS, then it's up to the backend app to retrieve the aliases for the
geoserver and use these as criteria when sending a push notif to UPS.
It tried to described that here :
https://github.com/sebastienblanc/unified-geo-server#integration-with-push
One idea for the alias, is to use the Keycloak (or whatever auth system)
username as alias to have it somehow "unified"
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
8:55 p.m.
Nice POC indeed, it makes things more concrete.
Looking at the the similar process for UGS and UPS and thinking we might need similar
mini/micro services, I think eventually we will benefit having a form of aggregator where
you say: create an app for UPS with plugin UGS, under the cover, 2 app ids are created and
unified with one appId + a map of corresponding app ids.
With the same idea some of the admin console for creating app could be mutualised.
This is more a ‘for the future’ improvement and does not interfere with your POC.
++
Corinne
On 10 Dec 2014, at 17:12, Sebastien Blanc <scm.blanc(a)gmail.com>
wrote:
On Wed, Dec 10, 2014 at 4:46 PM, Andres Galante <agalante(a)redhat.com> wrote:
Nice work Sebastien!
If you I can help with app or console design, please let me know.
Thanks ! A good strategy would probably to follow the Push Server and LiveOak
(Angular/patternfly) model.
----- Original Message -----
From: "Sebastien Blanc" <scm.blanc(a)gmail.com>
To: "AeroGear Developer Mailing List" <aerogear-dev(a)lists.jboss.org>
Sent: Wednesday, December 10, 2014 12:28:43 PM
Subject: Re: [aerogear-dev] [POC] Unified Geo Server
On Wed, Dec 10, 2014 at 4:23 PM, Erik Jan de Wit < edewit(a)redhat.com > wrote:
Really nice, looks great already, one question how do I use the data
from the geo search to send push notifications?
When the device registers to the geo server, it also provides an "alias". The
idea is that the developer has to use the same "alias" when registering to the
UPS, then it's up to the backend app to retrieve the aliases for the geoserver and use
these as criteria when sending a push notif to UPS.
It tried to described that here :
https://github.com/sebastienblanc/unified-geo-server#integration-with-push
One idea for the alias, is to use the Keycloak (or whatever auth system) username as
alias to have it somehow "unified"
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
9:04 p.m.
+1
We are thinking of this kind of scenarios for the next step on the console UI. The way we
have the navigation now it is not flexible enough. Hopefully I'll have updates on
console UX to share with you soon :)
----- Original Message -----
From: "Corinne Krych" <corinnekrych(a)gmail.com>
To: "AeroGear Developer Mailing List" <aerogear-dev(a)lists.jboss.org>
Sent: Wednesday, December 10, 2014 4:55:56 PM
Subject: Re: [aerogear-dev] [POC] Unified Geo Server
Nice POC indeed, it makes things more concrete.
Looking at the the similar process for UGS and UPS and thinking we might need similar
mini/micro services, I think eventually we will benefit having a form of aggregator where
you say: create an app for UPS with plugin UGS, under the cover, 2 app ids are created and
unified with one appId + a map of corresponding app ids.
With the same idea some of the admin console for creating app could be mutualised.
This is more a ‘for the future’ improvement and does not interfere with your POC.
++
Corinne
On 10 Dec 2014, at 17:12, Sebastien Blanc <scm.blanc(a)gmail.com>
wrote:
On Wed, Dec 10, 2014 at 4:46 PM, Andres Galante <agalante(a)redhat.com> wrote:
Nice work Sebastien!
If you I can help with app or console design, please let me know.
Thanks ! A good strategy would probably to follow the Push Server and LiveOak
(Angular/patternfly) model.
----- Original Message -----
From: "Sebastien Blanc" <scm.blanc(a)gmail.com>
To: "AeroGear Developer Mailing List" <aerogear-dev(a)lists.jboss.org>
Sent: Wednesday, December 10, 2014 12:28:43 PM
Subject: Re: [aerogear-dev] [POC] Unified Geo Server
On Wed, Dec 10, 2014 at 4:23 PM, Erik Jan de Wit < edewit(a)redhat.com > wrote:
Really nice, looks great already, one question how do I use the data
from the geo search to send push notifications?
When the device registers to the geo server, it also provides an "alias". The
idea is that the developer has to use the same "alias" when registering to the
UPS, then it's up to the backend app to retrieve the aliases for the geoserver and use
these as criteria when sending a push notif to UPS.
It tried to described that here :
https://github.com/sebastienblanc/unified-geo-server#integration-with-push
One idea for the alias, is to use the Keycloak (or whatever auth system) username as
alias to have it somehow "unified"
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
8:53 a.m.
On Wed, Dec 10, 2014 at 9:04 PM, Andres Galante <agalante(a)redhat.com> wrote:
+1
We are thinking of this kind of scenarios for the next step on the console
UI.
Can you explain more?
The way we have the navigation now it is not flexible enough.
Hopefully
I'll have updates on console UX to share with you soon :)
----- Original Message -----
From: "Corinne Krych" <corinnekrych(a)gmail.com>
To: "AeroGear Developer Mailing List" <aerogear-dev(a)lists.jboss.org>
Sent: Wednesday, December 10, 2014 4:55:56 PM
Subject: Re: [aerogear-dev] [POC] Unified Geo Server
Nice POC indeed, it makes things more concrete.
Looking at the the similar process for UGS and UPS and thinking we might
need similar mini/micro services, I think eventually we will benefit having
a form of aggregator where you say: create an app for UPS with plugin UGS,
under the cover, 2 app ids are created and unified with one appId + a map
of corresponding app ids.
With the same idea some of the admin console for creating app could be
mutualised.
This is more a ‘for the future’ improvement and does not interfere with
your POC.
++
Corinne
> On 10 Dec 2014, at 17:12, Sebastien Blanc <scm.blanc(a)gmail.com> wrote:
>
>
>
> On Wed, Dec 10, 2014 at 4:46 PM, Andres Galante <agalante(a)redhat.com>
wrote:
> Nice work Sebastien!
> If you I can help with app or console design, please let me know.
> Thanks ! A good strategy would probably to follow the Push Server and
LiveOak (Angular/patternfly) model.
>
> ----- Original Message -----
> From: "Sebastien Blanc" <scm.blanc(a)gmail.com>
> To: "AeroGear Developer Mailing List"
<aerogear-dev(a)lists.jboss.org>
> Sent: Wednesday, December 10, 2014 12:28:43 PM
> Subject: Re: [aerogear-dev] [POC] Unified Geo Server
>
>
>
> On Wed, Dec 10, 2014 at 4:23 PM, Erik Jan de Wit < edewit(a)redhat.com >
wrote:
>
>
> Really nice, looks great already, one question how do I use the data
> from the geo search to send push notifications?
> When the device registers to the geo server, it also provides an
"alias". The idea is that the developer has to use the same "alias"
when
registering to the UPS, then it's up to the backend app to retrieve the
aliases for the geoserver and use these as criteria when sending a push
notif to UPS.
> It tried to described that here :
https://github.com/sebastienblanc/unified-geo-server#integration-with-push
>
> One idea for the alias, is to use the Keycloak (or whatever auth system)
username as alias to have it somehow "unified"
>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
1:36 p.m.
Better show than tell, but I have nothing to show at the moment :(
The problem with the current console is that the sidebar as a main navigation doesn't
allow for sub navigation or expansions. We are researching with Matt and Gabriel applying
paternally and how to adapt it to mobile products. There has been a lot of talk internally
in the UX team but I haven't been able to start with it until yesterday.
Since changing the console is not a short term goal, please give me a couple of days to
work on it and I'll share as I have things to share.
----- Original Message -----
From: "Matthias Wessendorf" <matzew(a)apache.org>
To: "AeroGear Developer Mailing List" <aerogear-dev(a)lists.jboss.org>
Sent: Thursday, December 11, 2014 4:53:28 AM
Subject: Re: [aerogear-dev] [POC] Unified Geo Server
On Wed, Dec 10, 2014 at 9:04 PM, Andres Galante < agalante(a)redhat.com > wrote:
+1
We are thinking of this kind of scenarios for the next step on the console UI.
Can you explain more?
The way we have the navigation now it is not flexible enough. Hopefully I'll have
updates on console UX to share with you soon :)
----- Original Message -----
From: "Corinne Krych" < corinnekrych(a)gmail.com >
To: "AeroGear Developer Mailing List" < aerogear-dev(a)lists.jboss.org >
Sent: Wednesday, December 10, 2014 4:55:56 PM
Subject: Re: [aerogear-dev] [POC] Unified Geo Server
Nice POC indeed, it makes things more concrete.
Looking at the the similar process for UGS and UPS and thinking we might need similar
mini/micro services, I think eventually we will benefit having a form of aggregator where
you say: create an app for UPS with plugin UGS, under the cover, 2 app ids are created and
unified with one appId + a map of corresponding app ids.
With the same idea some of the admin console for creating app could be mutualised.
This is more a ‘for the future’ improvement and does not interfere with your POC.
++
Corinne
On 10 Dec 2014, at 17:12, Sebastien Blanc < scm.blanc(a)gmail.com
> wrote:
On Wed, Dec 10, 2014 at 4:46 PM, Andres Galante < agalante(a)redhat.com > wrote:
Nice work Sebastien!
If you I can help with app or console design, please let me know.
Thanks ! A good strategy would probably to follow the Push Server and LiveOak
(Angular/patternfly) model.
----- Original Message -----
From: "Sebastien Blanc" < scm.blanc(a)gmail.com >
To: "AeroGear Developer Mailing List" < aerogear-dev(a)lists.jboss.org >
Sent: Wednesday, December 10, 2014 12:28:43 PM
Subject: Re: [aerogear-dev] [POC] Unified Geo Server
On Wed, Dec 10, 2014 at 4:23 PM, Erik Jan de Wit < edewit(a)redhat.com > wrote:
Really nice, looks great already, one question how do I use the data
from the geo search to send push notifications?
When the device registers to the geo server, it also provides an "alias". The
idea is that the developer has to use the same "alias" when registering to the
UPS, then it's up to the backend app to retrieve the aliases for the geoserver and use
these as criteria when sending a push notif to UPS.
It tried to described that here :
https://github.com/sebastienblanc/unified-geo-server#integration-with-push
One idea for the alias, is to use the Keycloak (or whatever auth system) username as
alias to have it somehow "unified"
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
3:13 p.m.
On Thu, Dec 11, 2014 at 1:36 PM, Andres Galante <agalante(a)redhat.com> wrote:
Better show than tell, but I have nothing to show at the moment :(
The problem with the current console is that the sidebar as a main
navigation doesn't allow for sub navigation or expansions. We are
researching with Matt and Gabriel applying paternally and how to adapt it
to mobile products.
ah, you mean generic - not specific to this POC.
For this POC, let's just focus on the RESTful endpoints, not the UI at the
moment - it's a proof of concepts, not more
-M
There has been a lot of talk internally in the UX team but I
haven't been
able to start with it until yesterday.
Since changing the console is not a short term goal, please give me a
couple of days to work on it and I'll share as I have things to share.
----- Original Message -----
From: "Matthias Wessendorf" <matzew(a)apache.org>
To: "AeroGear Developer Mailing List" <aerogear-dev(a)lists.jboss.org>
Sent: Thursday, December 11, 2014 4:53:28 AM
Subject: Re: [aerogear-dev] [POC] Unified Geo Server
On Wed, Dec 10, 2014 at 9:04 PM, Andres Galante < agalante(a)redhat.com >
wrote:
+1
We are thinking of this kind of scenarios for the next step on the console
UI.
Can you explain more?
The way we have the navigation now it is not flexible enough. Hopefully
I'll have updates on console UX to share with you soon :)
----- Original Message -----
From: "Corinne Krych" < corinnekrych(a)gmail.com >
To: "AeroGear Developer Mailing List" < aerogear-dev(a)lists.jboss.org >
Sent: Wednesday, December 10, 2014 4:55:56 PM
Subject: Re: [aerogear-dev] [POC] Unified Geo Server
Nice POC indeed, it makes things more concrete.
Looking at the the similar process for UGS and UPS and thinking we might
need similar mini/micro services, I think eventually we will benefit having
a form of aggregator where you say: create an app for UPS with plugin UGS,
under the cover, 2 app ids are created and unified with one appId + a map
of corresponding app ids.
With the same idea some of the admin console for creating app could be
mutualised.
This is more a ‘for the future’ improvement and does not interfere with
your POC.
++
Corinne
> On 10 Dec 2014, at 17:12, Sebastien Blanc < scm.blanc(a)gmail.com > wrote:
>
>
>
> On Wed, Dec 10, 2014 at 4:46 PM, Andres Galante < agalante(a)redhat.com >
wrote:
> Nice work Sebastien!
> If you I can help with app or console design, please let me know.
> Thanks ! A good strategy would probably to follow the Push Server and
LiveOak (Angular/patternfly) model.
>
> ----- Original Message -----
> From: "Sebastien Blanc" < scm.blanc(a)gmail.com >
> To: "AeroGear Developer Mailing List" < aerogear-dev(a)lists.jboss.org
>
> Sent: Wednesday, December 10, 2014 12:28:43 PM
> Subject: Re: [aerogear-dev] [POC] Unified Geo Server
>
>
>
> On Wed, Dec 10, 2014 at 4:23 PM, Erik Jan de Wit < edewit(a)redhat.com >
wrote:
>
>
> Really nice, looks great already, one question how do I use the data
> from the geo search to send push notifications?
> When the device registers to the geo server, it also provides an
"alias". The idea is that the developer has to use the same "alias"
when
registering to the UPS, then it's up to the backend app to retrieve the
aliases for the geoserver and use these as criteria when sending a push
notif to UPS.
> It tried to described that here :
https://github.com/sebastienblanc/unified-geo-server#integration-with-push
>
> One idea for the alias, is to use the Keycloak (or whatever auth system)
username as alias to have it somehow "unified"
>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
9:23 p.m.
Envoyé de mon iPhone
Le 10 déc. 2014 à 20:55, Corinne Krych <corinnekrych(a)gmail.com>
a écrit :
Nice POC indeed, it makes things more concrete.
Looking at the the similar process for UGS and UPS and thinking we might need similar
mini/micro services, I think eventually we will benefit having a form of aggregator where
you say: create an app for UPS with plugin UGS, under the cover, 2 app ids are created and
unified with one appId + a map of corresponding app ids.
With the same idea some of the admin console for creating app could be mutualised.
Make totally sense and I have also been thinking about that.
My first thoughts would be something's around fabric8/fuse and using amq.
One concrete example that I will try to add to the POC is sending a message on a amq
channel when a device registers. Other apps could consume this queue. That might be a
start.
This is more a ‘for the future’ improvement and does not interfere with your POC.
++
Corinne
> On 10 Dec 2014, at 17:12, Sebastien Blanc <scm.blanc(a)gmail.com> wrote:
>
>
>
> On Wed, Dec 10, 2014 at 4:46 PM, Andres Galante <agalante(a)redhat.com> wrote:
> Nice work Sebastien!
> If you I can help with app or console design, please let me know.
> Thanks ! A good strategy would probably to follow the Push Server and LiveOak
(Angular/patternfly) model.
>
> ----- Original Message -----
> From: "Sebastien Blanc" <scm.blanc(a)gmail.com>
> To: "AeroGear Developer Mailing List" <aerogear-dev(a)lists.jboss.org>
> Sent: Wednesday, December 10, 2014 12:28:43 PM
> Subject: Re: [aerogear-dev] [POC] Unified Geo Server
>
>
>
> On Wed, Dec 10, 2014 at 4:23 PM, Erik Jan de Wit < edewit(a)redhat.com > wrote:
>
>
> Really nice, looks great already, one question how do I use the data
> from the geo search to send push notifications?
> When the device registers to the geo server, it also provides an "alias".
The idea is that the developer has to use the same "alias" when registering to
the UPS, then it's up to the backend app to retrieve the aliases for the geoserver and
use these as criteria when sending a push notif to UPS.
> It tried to described that here :
https://github.com/sebastienblanc/unified-geo-server#integration-with-push
>
> One idea for the alias, is to use the Keycloak (or whatever auth system) username as
alias to have it somehow "unified"
>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
8:31 a.m.
Thanks for the screencast!
On 10 December 2014 at 21:23, Sébastien Blanc <scm.blanc(a)gmail.com> wrote:
Envoyé de mon iPhone
> Le 10 déc. 2014 à 20:55, Corinne Krych <corinnekrych(a)gmail.com> a écrit
:
>
> Nice POC indeed, it makes things more concrete.
>
> Looking at the the similar process for UGS and UPS and thinking we might
need similar mini/micro services, I think eventually we will benefit having
a form of aggregator where you say: create an app for UPS with plugin UGS,
under the cover, 2 app ids are created and unified with one appId + a map
of corresponding app ids.
> With the same idea some of the admin console for creating app could be
mutualised.
Make totally sense and I have also been thinking about that.
My first thoughts would be something's around fabric8/fuse and using amq.
One concrete example that I will try to add to the POC is sending a
message on a amq channel when a device registers. Other apps could consume
this queue. That might be a start.
>
> This is more a ‘for the future’ improvement and does not interfere with
your POC.
>
> ++
> Corinne
>
>> On 10 Dec 2014, at 17:12, Sebastien Blanc <scm.blanc(a)gmail.com> wrote:
>>
>>
>>
>> On Wed, Dec 10, 2014 at 4:46 PM, Andres Galante <agalante(a)redhat.com>
wrote:
>> Nice work Sebastien!
>> If you I can help with app or console design, please let me know.
>> Thanks ! A good strategy would probably to follow the Push Server and
LiveOak (Angular/patternfly) model.
>>
>> ----- Original Message -----
>> From: "Sebastien Blanc" <scm.blanc(a)gmail.com>
>> To: "AeroGear Developer Mailing List"
<aerogear-dev(a)lists.jboss.org>
>> Sent: Wednesday, December 10, 2014 12:28:43 PM
>> Subject: Re: [aerogear-dev] [POC] Unified Geo Server
>>
>>
>>
>> On Wed, Dec 10, 2014 at 4:23 PM, Erik Jan de Wit < edewit(a)redhat.com >
wrote:
>>
>>
>> Really nice, looks great already, one question how do I use the data
>> from the geo search to send push notifications?
>> When the device registers to the geo server, it also provides an
"alias". The idea is that the developer has to use the same "alias"
when
registering to the UPS, then it's up to the backend app to retrieve the
aliases for the geoserver and use these as criteria when sending a push
notif to UPS.
>> It tried to described that here :
https://github.com/sebastienblanc/unified-geo-server#integration-with-push
>>
>> One idea for the alias, is to use the Keycloak (or whatever auth
system) username as alias to have it somehow "unified"
>>
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
8:53 a.m.
Nice POC, Sebi! and great screencast!
On Wed, Dec 10, 2014 at 8:55 PM, Corinne Krych <corinnekrych(a)gmail.com>
wrote:
Nice POC indeed, it makes things more concrete.
Looking at the the similar process for UGS and UPS and thinking we might
need similar mini/micro services,
I have analytics in mind (e.g. leveraging RHQ metrics, as a possible option)
I think eventually we will benefit having a form of aggregator where
you
say: create an app for UPS with plugin UGS, under the cover, 2 app ids are
created and unified with one appId + a map of corresponding app ids.
This overall aggregator would be an MBaaS, like FH or LiveOak. That's
really not what we need to create here
-Matthias
With the same idea some of the admin console for creating app could
be
mutualised.
This is more a ‘for the future’ improvement and does not interfere with
your POC.
++
Corinne
> On 10 Dec 2014, at 17:12, Sebastien Blanc <scm.blanc(a)gmail.com> wrote:
>
>
>
> On Wed, Dec 10, 2014 at 4:46 PM, Andres Galante <agalante(a)redhat.com>
wrote:
> Nice work Sebastien!
> If you I can help with app or console design, please let me know.
> Thanks ! A good strategy would probably to follow the Push Server and
LiveOak (Angular/patternfly) model.
>
> ----- Original Message -----
> From: "Sebastien Blanc" <scm.blanc(a)gmail.com>
> To: "AeroGear Developer Mailing List"
<aerogear-dev(a)lists.jboss.org>
> Sent: Wednesday, December 10, 2014 12:28:43 PM
> Subject: Re: [aerogear-dev] [POC] Unified Geo Server
>
>
>
> On Wed, Dec 10, 2014 at 4:23 PM, Erik Jan de Wit < edewit(a)redhat.com >
wrote:
>
>
> Really nice, looks great already, one question how do I use the data
> from the geo search to send push notifications?
> When the device registers to the geo server, it also provides an
"alias". The idea is that the developer has to use the same "alias"
when
registering to the UPS, then it's up to the backend app to retrieve the
aliases for the geoserver and use these as criteria when sending a push
notif to UPS.
> It tried to described that here :
https://github.com/sebastienblanc/unified-geo-server#integration-with-push
>
> One idea for the alias, is to use the Keycloak (or whatever auth system)
username as alias to have it somehow "unified"
>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
9:08 p.m.
Good morning, first nice screencast Sebi and even knowing this is just a
PoC I have some considerations:
1. What would be the use case scenario to justify a separated server
instead of just a module on AGPUSH?
2. How do you plan to prevent people from faking their location?
3. Do we have a privacy policy to make the developer real aware about
what's being collected?
4. Will collecting geo location be opt in or default?
5. Why is necessary to store current user's position? Couldn't admin
specify a range and check how many devices are active on that region?
Into this way you don't need to store their positions. I'm not the Geo
specialist here but the idea is:
1. Admin specify the range when a push message must be sent. For
example: Whole Florida
2. Client opt in and sent her its position to the server
3. Server compares and sent the push message
I'm very concerned about privacy here, I'm not against the
solution, but Geo location is like to open a Pandora box.
We might be careful about unintentional disclosure of geolocation information,
because it carries physical risks to the client (theft, to stalking, kidnapping
and domestic violence — I'm not exaggerating).
Again, I know this is a proof of concept, but sooner we have it in mind, the
better.
On 2014-12-10, Sebastien Blanc wrote:
Hi all,
I have been working on a POC around geolocation. Like we discussed in
another thread, we decided not to have a "deep" integration with the Push
server but instead a separate component / microservice. Well the POC is
more a miniservice ;)
So, the idea is to have a server to which devices can register by providing
their positions. On the other side, the server provide an endpoint to make
spatial queries, like give me all the installations within a radius of 10
km around this lat/ltg.
Thanks to Forge, I created/scaffolded a really simple server providing the
registration endpoint and the search endpoint.
I tried to make a decent readme that will give you more details :
https://github.com/sebastienblanc/unified-geo-server
And as usual, I made a little screencast showing all that in action ;)
https://www.youtube.com/watch?v=R-qdLJh4EWQ
Please remember this is a POC, so the security is almost inexistant, the
console is awful ;)
What about the Client SDKs ?
If we reach some kind of consensus arounf the concept of Unfied Geo Server
we can start building the Client SDKs / POCs , they will be quite simple :
retrieve geolocation and register to the geo endpoint.
Sebi
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
abstractj
PGP: 0x84DC9914
9:37 p.m.
On Mon, Dec 15, 2014 at 9:08 PM, Bruno Oliveira <bruno(a)abstractj.org> wrote:
Good morning, first nice screencast Sebi and even knowing this is just a
PoC I have some considerations:
1. What would be the use case scenario to justify a separated server
instead of just a module on AGPUSH?
I think main discussion around this at F2F meeting was, it might be useful
for other scenarios as well,
and we don't want to hard-wire geo to the push server
2. How do you plan to prevent people from faking their location?
I'd assume that a Geo SDK would be based on-top of the mobile OS's
facility, to receive the long/lat values.
I think in the future we can have some sort of checks, like validating the
users IP address, if it somewhat matches the submitted geo data.
3. Do we have a privacy policy to make the developer real aware about
what's being collected?
I think that the level of collected geo data is up to the developer of the
app, using the Geo SDK.
4. Will collecting geo location be opt in or default?
If the Geo-data SDK is used w/in an app, I think it will still ask,
up-front, if location based services are OK to use (at least apple). And
I'd argue that users can still disable the geo usage, per app (at least
apple)
5. Why is necessary to store current user's position?
I think that's up to the use case, and its usage of the Geo SDK.
Couldn't admin
specify a range and check how many devices are active on that region?
Into this way you don't need to store their positions. I'm not the Geo
specialist here but the idea is:
1. Admin specify the range when a push message must be sent. For
example: Whole Florida
2. Client opt in and sent her its position to the server
3. Server compares and sent the push message
I'm very concerned about privacy here, I'm not against the
solution, but Geo location is like to open a Pandora box.
yeah, it's also creepy :) I have not much services that I give my geo data
We might be careful about unintentional disclosure of geolocation
information,
because it carries physical risks to the client (theft, to stalking,
kidnapping
and domestic violence — I'm not exaggerating).
+1 I'd argue that the "Geo server" would be, initially, a 'simple'
back
end, that is able to store n pairs of long/lat values (grouped by a
user/device).
The mobile SDK for it basically store the 'collected' data to this backend
(somewhat similar to the push registration SDK)
Again, I know this is a proof of concept, but sooner we have it in mind,
the
better.
+1 fully agree. Replied to your questions with my POV on this
On 2014-12-10, Sebastien Blanc wrote:
> Hi all,
>
> I have been working on a POC around geolocation. Like we discussed in
> another thread, we decided not to have a "deep" integration with the Push
> server but instead a separate component / microservice. Well the POC is
> more a miniservice ;)
>
> So, the idea is to have a server to which devices can register by
providing
> their positions. On the other side, the server provide an endpoint to
make
> spatial queries, like give me all the installations within a radius of 10
> km around this lat/ltg.
>
> Thanks to Forge, I created/scaffolded a really simple server providing
the
> registration endpoint and the search endpoint.
>
> I tried to make a decent readme that will give you more details :
>
> https://github.com/sebastienblanc/unified-geo-server
>
> And as usual, I made a little screencast showing all that in action ;)
>
> https://www.youtube.com/watch?v=R-qdLJh4EWQ
>
> Please remember this is a POC, so the security is almost inexistant, the
> console is awful ;)
>
> What about the Client SDKs ?
>
> If we reach some kind of consensus arounf the concept of Unfied Geo
Server
> we can start building the Client SDKs / POCs , they will be quite simple
:
> retrieve geolocation and register to the geo endpoint.
>
> Sebi
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
abstractj
PGP: 0x84DC9914
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
9:57 p.m.
Lots of things I was going to answer as already be done Matthias ;)
But first of all thanks Bruno for this detailed answer.
All your concerns make totally sense and it's by tackling them in the SDKs and the
server that will make it a valuable piece of software that people would like to use.
Some extra answers inline
Envoyé de mon iPhone
Le 15 déc. 2014 à 21:37, Matthias Wessendorf
<matzew(a)apache.org> a écrit :
> On Mon, Dec 15, 2014 at 9:08 PM, Bruno Oliveira <bruno(a)abstractj.org> wrote:
> Good morning, first nice screencast Sebi and even knowing this is just a
> PoC I have some considerations:
>
> 1. What would be the use case scenario to justify a separated server
> instead of just a module on AGPUSH?
I think main discussion around this at F2F meeting was, it might be useful for other
scenarios as well,
and we don't want to hard-wire geo to the push server
Yes, for instance all
mobile apps would not need Push but would like use geo stuff.
>
> 2. How do you plan to prevent people from faking their location?
I'd assume that a Geo SDK would be based on-top of the mobile OS's facility, to
receive the long/lat values.
I think in the future we can have some sort of checks, like validating the users IP
address, if it somewhat matches the submitted geo data.
Yes adding this kind of
security would really make the difference than a simple "send-my-location"
library.
Could keycloak for instance help to authenticate the SDK call ? Or token based stuff ?
>
> 3. Do we have a privacy policy to make the developer real aware about
> what's being collected?
I think that the level of collected geo data is up to the developer of the app, using the
Geo SDK.
We could also add extra warnings in the documentation like Cordova does
https://github.com/apache/cordova-plugin-geolocation/blob/master/doc/inde...
>
> 4. Will collecting geo location be opt in or default?
If the Geo-data SDK is used w/in an app, I think it will still ask, up-front, if location
based services are OK to use (at least apple). And I'd argue that users can still
disable the geo usage, per app (at least apple)
>
> 5. Why is necessary to store current user's position?
I think that's up to the use case, and its usage of the Geo SDK.
> Couldn't admin
> specify a range and check how many devices are active on that region?
> Into this way you don't need to store their positions. I'm not the Geo
> specialist here but the idea is:
>
> 1. Admin specify the range when a push message must be sent. For
> example: Whole Florida
> 2. Client opt in and sent her its position to the server
> 3. Server compares and sent the push message
>
> I'm very concerned about privacy here, I'm not against the
> solution, but Geo location is like to open a Pandora box.
yeah, it's also creepy :) I have not much services that I give my geo data
>
> We might be careful about unintentional disclosure of geolocation information,
> because it carries physical risks to the client (theft, to stalking, kidnapping
> and domestic violence — I'm not exaggerating).
+1 I'd argue that the "Geo server" would be, initially, a 'simple'
back end, that is able to store n pairs of long/lat values (grouped by a user/device).
The mobile SDK for it basically store the 'collected' data to this backend
(somewhat similar to the push registration SDK)
>
> Again, I know this is a proof of concept, but sooner we have it in mind, the
> better.
+1 fully agree. Replied to your questions with my POV on this
+1 as I said in the
beginning of my message.
>
>
>
>
> On 2014-12-10, Sebastien Blanc wrote:
> > Hi all,
> >
> > I have been working on a POC around geolocation. Like we discussed in
> > another thread, we decided not to have a "deep" integration with the
Push
> > server but instead a separate component / microservice. Well the POC is
> > more a miniservice ;)
> >
> > So, the idea is to have a server to which devices can register by providing
> > their positions. On the other side, the server provide an endpoint to make
> > spatial queries, like give me all the installations within a radius of 10
> > km around this lat/ltg.
> >
> > Thanks to Forge, I created/scaffolded a really simple server providing the
> > registration endpoint and the search endpoint.
> >
> > I tried to make a decent readme that will give you more details :
> >
> > https://github.com/sebastienblanc/unified-geo-server
> >
> > And as usual, I made a little screencast showing all that in action ;)
> >
> > https://www.youtube.com/watch?v=R-qdLJh4EWQ
> >
> > Please remember this is a POC, so the security is almost inexistant, the
> > console is awful ;)
> >
> > What about the Client SDKs ?
> >
> > If we reach some kind of consensus arounf the concept of Unfied Geo Server
> > we can start building the Client SDKs / POCs , they will be quite simple :
> > retrieve geolocation and register to the geo endpoint.
> >
> > Sebi
>
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
> --
>
> abstractj
> PGP: 0x84DC9914
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
11:36 p.m.
On 2014-12-15, Sébastien Blanc wrote:
Lots of things I was going to answer as already be done Matthias ;)
But first of all thanks Bruno for this detailed answer.
All your concerns make totally sense and it's by tackling them in the SDKs and the
server that will make it a valuable piece of software that people would like to use.
Some extra answers inline
Envoyé de mon iPhone
> Le 15 déc. 2014 à 21:37, Matthias Wessendorf <matzew(a)apache.org> a écrit :
>
>
>
>> On Mon, Dec 15, 2014 at 9:08 PM, Bruno Oliveira <bruno(a)abstractj.org>
wrote:
>> Good morning, first nice screencast Sebi and even knowing this is just a
>> PoC I have some considerations:
>>
>> 1. What would be the use case scenario to justify a separated server
>> instead of just a module on AGPUSH?
>
> I think main discussion around this at F2F meeting was, it might be useful for other
scenarios as well,
> and we don't want to hard-wire geo to the push server
Yes, for instance all mobile apps would not need Push but would like use geo stuff.
>
>
>>
>> 2. How do you plan to prevent people from faking their location?
>
> I'd assume that a Geo SDK would be based on-top of the mobile OS's facility,
to receive the long/lat values.
> I think in the future we can have some sort of checks, like validating the users IP
address, if it somewhat matches the submitted geo data.
Yes adding this kind of security would really make the difference than a simple
"send-my-location" library.
Could keycloak for instance help to authenticate the SDK call ? Or token based stuff ?
Yes, it's possible to have some sorta of integration with Keycloak, but
must be evaluated.
>
>
>>
>> 3. Do we have a privacy policy to make the developer real aware about
>> what's being collected?
>
> I think that the level of collected geo data is up to the developer of the app,
using the Geo SDK.
We could also add extra warnings in the documentation like Cordova does
https://github.com/apache/cordova-plugin-geolocation/blob/master/doc/inde...
That makes sense, or https://www.google.com/privacy/lsf.html.
>
>>
>> 4. Will collecting geo location be opt in or default?
>
> If the Geo-data SDK is used w/in an app, I think it will still ask, up-front, if
location based services are OK to use (at least apple). And I'd argue that users can
still disable the geo usage, per app (at least apple)
>
>
>
>>
>> 5. Why is necessary to store current user's position?
>
> I think that's up to the use case, and its usage of the Geo SDK.
>
>> Couldn't admin
>> specify a range and check how many devices are active on that region?
>> Into this way you don't need to store their positions. I'm not the Geo
>> specialist here but the idea is:
>>
>> 1. Admin specify the range when a push message must be sent. For
>> example: Whole Florida
>> 2. Client opt in and sent her its position to the server
>> 3. Server compares and sent the push message
>>
>> I'm very concerned about privacy here, I'm not against the
>> solution, but Geo location is like to open a Pandora box.
>
> yeah, it's also creepy :) I have not much services that I give my geo data
>
>>
>> We might be careful about unintentional disclosure of geolocation information,
>> because it carries physical risks to the client (theft, to stalking, kidnapping
>> and domestic violence — I'm not exaggerating).
>
> +1 I'd argue that the "Geo server" would be, initially, a
'simple' back end, that is able to store n pairs of long/lat values (grouped by a
user/device).
> The mobile SDK for it basically store the 'collected' data to this backend
(somewhat similar to the push registration SDK)
>
>>
>> Again, I know this is a proof of concept, but sooner we have it in mind, the
>> better.
>
> +1 fully agree. Replied to your questions with my POV on this
+1 as I said in the beginning of my message.
>
>
>>
>>
>>
>>
>> On 2014-12-10, Sebastien Blanc wrote:
>> > Hi all,
>> >
>> > I have been working on a POC around geolocation. Like we discussed in
>> > another thread, we decided not to have a "deep" integration with
the Push
>> > server but instead a separate component / microservice. Well the POC is
>> > more a miniservice ;)
>> >
>> > So, the idea is to have a server to which devices can register by
providing
>> > their positions. On the other side, the server provide an endpoint to make
>> > spatial queries, like give me all the installations within a radius of 10
>> > km around this lat/ltg.
>> >
>> > Thanks to Forge, I created/scaffolded a really simple server providing the
>> > registration endpoint and the search endpoint.
>> >
>> > I tried to make a decent readme that will give you more details :
>> >
>> > https://github.com/sebastienblanc/unified-geo-server
>> >
>> > And as usual, I made a little screencast showing all that in action ;)
>> >
>> > https://www.youtube.com/watch?v=R-qdLJh4EWQ
>> >
>> > Please remember this is a POC, so the security is almost inexistant, the
>> > console is awful ;)
>> >
>> > What about the Client SDKs ?
>> >
>> > If we reach some kind of consensus arounf the concept of Unfied Geo Server
>> > we can start building the Client SDKs / POCs , they will be quite simple :
>> > retrieve geolocation and register to the geo endpoint.
>> >
>> > Sebi
>>
>> > _______________________________________________
>> > aerogear-dev mailing list
>> > aerogear-dev(a)lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>
>> --
>>
>> abstractj
>> PGP: 0x84DC9914
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
abstractj
PGP: 0x84DC9914
11:32 p.m.
On 2014-12-15, Matthias Wessendorf wrote:
On Mon, Dec 15, 2014 at 9:08 PM, Bruno Oliveira
<bruno(a)abstractj.org> wrote:
>
> Good morning, first nice screencast Sebi and even knowing this is just a
> PoC I have some considerations:
>
> 1. What would be the use case scenario to justify a separated server
> instead of just a module on AGPUSH?
>
I think main discussion around this at F2F meeting was, it might be useful
for other scenarios as well,
and we don't want to hard-wire geo to the push server
Which scenarios?
>
> 2. How do you plan to prevent people from faking their location?
>
I'd assume that a Geo SDK would be based on-top of the mobile OS's
facility, to receive the long/lat values.
I think in the future we can have some sort of checks, like validating the
users IP address, if it somewhat matches the submitted geo data.
I think Geo based on IPs are a bad idea. This is a very inaccurate method
and should be our last resort, it's easy to spoof IPs.
>
> 3. Do we have a privacy policy to make the developer real aware about
> what's being collected?
>
I think that the level of collected geo data is up to the developer of the
app, using the Geo SDK.
I'm sorry, but I have to disagree. If we don't provide a policy about the usage of
the Geo
server, we're pretty much accountable for it.
Nothing huge, only a simple txt documenting what's being collected and
why.
>
> 4. Will collecting geo location be opt in or default?
>
If the Geo-data SDK is used w/in an app, I think it will still ask,
up-front, if location based services are OK to use (at least apple). And
I'd argue that users can still disable the geo usage, per app (at least
apple)
Most of users have no idea that their data is being collected. I'm
confused about your answer, is that an yes or no?
>
> 5. Why is necessary to store current user's position?
I think that's up to the use case, and its usage of the Geo SDK.
Currently we store. I know this is just a proof of concept.
But I insist to be the boring, and avoid it if possible.
> Couldn't admin
> specify a range and check how many devices are active on that region?
> Into this way you don't need to store their positions. I'm not the Geo
> specialist here but the idea is:
>
> 1. Admin specify the range when a push message must be sent. For
> example: Whole Florida
> 2. Client opt in and sent her its position to the server
> 3. Server compares and sent the push message
>
> I'm very concerned about privacy here, I'm not against the
> solution, but Geo location is like to open a Pandora box.
>
yeah, it's also creepy :) I have not much services that I give my geo data
>
> We might be careful about unintentional disclosure of geolocation
> information,
> because it carries physical risks to the client (theft, to stalking,
> kidnapping
> and domestic violence — I'm not exaggerating).
>
+1 I'd argue that the "Geo server" would be, initially, a 'simple'
back
end, that is able to store n pairs of long/lat values (grouped by a
user/device).
The mobile SDK for it basically store the 'collected' data to this backend
(somewhat similar to the push registration SDK)
>
> Again, I know this is a proof of concept, but sooner we have it in mind,
> the
> better.
>
+1 fully agree. Replied to your questions with my POV on this
>
>
>
>
> On 2014-12-10, Sebastien Blanc wrote:
> > Hi all,
> >
> > I have been working on a POC around geolocation. Like we discussed in
> > another thread, we decided not to have a "deep" integration with the
Push
> > server but instead a separate component / microservice. Well the POC is
> > more a miniservice ;)
> >
> > So, the idea is to have a server to which devices can register by
> providing
> > their positions. On the other side, the server provide an endpoint to
> make
> > spatial queries, like give me all the installations within a radius of 10
> > km around this lat/ltg.
> >
> > Thanks to Forge, I created/scaffolded a really simple server providing
> the
> > registration endpoint and the search endpoint.
> >
> > I tried to make a decent readme that will give you more details :
> >
> > https://github.com/sebastienblanc/unified-geo-server
> >
> > And as usual, I made a little screencast showing all that in action ;)
> >
> > https://www.youtube.com/watch?v=R-qdLJh4EWQ
> >
> > Please remember this is a POC, so the security is almost inexistant, the
> > console is awful ;)
> >
> > What about the Client SDKs ?
> >
> > If we reach some kind of consensus arounf the concept of Unfied Geo
> Server
> > we can start building the Client SDKs / POCs , they will be quite simple
> :
> > retrieve geolocation and register to the geo endpoint.
> >
> > Sebi
>
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
> --
>
> abstractj
> PGP: 0x84DC9914
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
abstractj
PGP: 0x84DC9914
12:10 a.m.
On Mon, Dec 15, 2014 at 11:32 PM, Bruno Oliveira <bruno(a)abstractj.org>
wrote:
On 2014-12-15, Matthias Wessendorf wrote:
> On Mon, Dec 15, 2014 at 9:08 PM, Bruno Oliveira <bruno(a)abstractj.org>
wrote:
> >
> > Good morning, first nice screencast Sebi and even knowing this is just
a
> > PoC I have some considerations:
> >
> > 1. What would be the use case scenario to justify a separated server
> > instead of just a module on AGPUSH?
> >
>
> I think main discussion around this at F2F meeting was, it might be
useful
> for other scenarios as well,
> and we don't want to hard-wire geo to the push server
Which scenarios?
The are several scenarios where geo is needed without push.
For instance, think of a backend system for a transport company that needs
to run analysis each night based on the current location of the truck
drivers in order to plan efficiently the logistics for the next day.
>
>
>
> >
> > 2. How do you plan to prevent people from faking their location?
> >
>
> I'd assume that a Geo SDK would be based on-top of the mobile OS's
> facility, to receive the long/lat values.
> I think in the future we can have some sort of checks, like validating
the
> users IP address, if it somewhat matches the submitted geo data.
I think Geo based on IPs are a bad idea. This is a very inaccurate method
and should be our last resort, it's easy to spoof IPs.
>
>
>
> >
> > 3. Do we have a privacy policy to make the developer real aware about
> > what's being collected?
> >
>
> I think that the level of collected geo data is up to the developer of
the
> app, using the Geo SDK.
I'm sorry, but I have to disagree. If we don't provide a policy about the
usage of the Geo
server, we're pretty much accountable for it.
Nothing huge, only a simple txt documenting what's being collected and
why.
>
>
> >
> > 4. Will collecting geo location be opt in or default?
> >
>
> If the Geo-data SDK is used w/in an app, I think it will still ask,
> up-front, if location based services are OK to use (at least apple). And
> I'd argue that users can still disable the geo usage, per app (at least
> apple)
Most of users have no idea that their data is being collected. I'm
confused about your answer, is that an yes or no?
I think what Matthias means is that when using gelolocation on the device,
being iOS, Android or even Web, the users will be prompted to allow or not
access to his geodata. So, yes it's an opt-in and also, like Matthias said
a the possibility to opt-out.
>
>
>
>
> >
> > 5. Why is necessary to store current user's position?
>
>
> I think that's up to the use case, and its usage of the Geo SDK.
Currently we store. I know this is just a proof of concept.
But I insist to be the boring, and avoid it if possible.
If we don't store we can not make geo queries. Without these queries the
question of having a geo server is quite useless ...
But we could think of a "flavor" or variant ;) where the geo data is not
persisted but just pass through (to a queue, another REST endpoint), It
will more act then like a broker, but again not sure if I can find a
usecase for that.
>
>
> > Couldn't admin
> > specify a range and check how many devices are active on that region?
> > Into this way you don't need to store their positions. I'm not the Geo
> > specialist here but the idea is:
> >
> > 1. Admin specify the range when a push message must be sent. For
> > example: Whole Florida
> > 2. Client opt in and sent her its position to the server
> > 3. Server compares and sent the push message
> >
> > I'm very concerned about privacy here, I'm not against the
> > solution, but Geo location is like to open a Pandora box.
> >
>
> yeah, it's also creepy :) I have not much services that I give my geo
data
>
>
> >
> > We might be careful about unintentional disclosure of geolocation
> > information,
> > because it carries physical risks to the client (theft, to stalking,
> > kidnapping
> > and domestic violence — I'm not exaggerating).
> >
>
> +1 I'd argue that the "Geo server" would be, initially, a
'simple' back
> end, that is able to store n pairs of long/lat values (grouped by a
> user/device).
> The mobile SDK for it basically store the 'collected' data to this
backend
> (somewhat similar to the push registration SDK)
>
>
> >
> > Again, I know this is a proof of concept, but sooner we have it in
mind,
> > the
> > better.
> >
>
> +1 fully agree. Replied to your questions with my POV on this
>
>
>
> >
> >
> >
> >
> > On 2014-12-10, Sebastien Blanc wrote:
> > > Hi all,
> > >
> > > I have been working on a POC around geolocation. Like we discussed in
> > > another thread, we decided not to have a "deep" integration with
the
Push
> > > server but instead a separate component / microservice. Well the POC
is
> > > more a miniservice ;)
> > >
> > > So, the idea is to have a server to which devices can register by
> > providing
> > > their positions. On the other side, the server provide an endpoint to
> > make
> > > spatial queries, like give me all the installations within a radius
of 10
> > > km around this lat/ltg.
> > >
> > > Thanks to Forge, I created/scaffolded a really simple server
providing
> > the
> > > registration endpoint and the search endpoint.
> > >
> > > I tried to make a decent readme that will give you more details :
> > >
> > > https://github.com/sebastienblanc/unified-geo-server
> > >
> > > And as usual, I made a little screencast showing all that in action
;)
> > >
> > > https://www.youtube.com/watch?v=R-qdLJh4EWQ
> > >
> > > Please remember this is a POC, so the security is almost inexistant,
the
> > > console is awful ;)
> > >
> > > What about the Client SDKs ?
> > >
> > > If we reach some kind of consensus arounf the concept of Unfied Geo
> > Server
> > > we can start building the Client SDKs / POCs , they will be quite
simple
> > :
> > > retrieve geolocation and register to the geo endpoint.
> > >
> > > Sebi
> >
> > > _______________________________________________
> > > aerogear-dev mailing list
> > > aerogear-dev(a)lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >
> >
> > --
> >
> > abstractj
> > PGP: 0x84DC9914
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
abstractj
PGP: 0x84DC9914
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
9 p.m.
Great work sebi . How frequently are the lat longs sent to the geo server? and what is
the backend db for the geo server ? is it mongo ?
Regards
From: Sebastien Blanc <scm.blanc(a)gmail.com>
To: AeroGear Developer Mailing List <aerogear-dev(a)lists.jboss.org>
Sent: Monday, December 15, 2014 6:10 PM
Subject: Re: [aerogear-dev] [POC] Unified Geo Server
On Mon, Dec 15, 2014 at 11:32 PM, Bruno Oliveira <bruno(a)abstractj.org> wrote:
On 2014-12-15, Matthias Wessendorf wrote:
On Mon, Dec 15, 2014 at 9:08 PM, Bruno Oliveira
<bruno(a)abstractj.org> wrote:
>
> Good morning, first nice screencast Sebi and even knowing this is just a
> PoC I have some considerations:
>
> 1. What would be the use case scenario to justify a separated server
> instead of just a module on AGPUSH?
>
I think main discussion around this at F2F meeting was, it might be useful
for other scenarios as well,
and we don't want to hard-wire geo to the push server
Which scenarios?
The are several scenarios where geo is needed without push. For instance, think of a
backend system for a transport company that needs to run analysis each night based on the
current location of the truck drivers in order to plan efficiently the logistics for the
next day.
>
> 2. How do you plan to prevent people from faking their location?
>
I'd assume that a Geo SDK would be based on-top of the mobile OS's
facility, to receive the long/lat values.
I think in the future we can have some sort of checks, like validating the
users IP address, if it somewhat matches the submitted geo data.
I think Geo based on IPs are a bad idea. This is a very inaccurate method
and should be our last resort, it's easy to spoof IPs.
>
> 3. Do we have a privacy policy to make the developer real aware about
> what's being collected?
>
I think that the level of collected geo data is up to the developer of the
app, using the Geo SDK.
I'm sorry, but I have to disagree. If we don't provide a policy about the usage of
the Geo
server, we're pretty much accountable for it.
Nothing huge, only a simple txt documenting what's being collected and
why.
>
> 4. Will collecting geo location be opt in or default?
>
If the Geo-data SDK is used w/in an app, I think it will still ask,
up-front, if location based services are OK to use (at least apple). And
I'd argue that users can still disable the geo usage, per app (at least
apple)
Most of users have no idea that their data is being collected. I'm
confused about your answer, is that an yes or no?
I think what Matthias means is that when using gelolocation on the device, being iOS,
Android or even Web, the users will be prompted to allow or not access to his geodata. So,
yes it's an opt-in and also, like Matthias said a the possibility to opt-out.
>
> 5. Why is necessary to store current user's position?
I think that's up to the use case, and its usage of the Geo SDK.
Currently we store. I know this is just a proof of concept.
But I insist to be the boring, and avoid it if possible.
If we don't store we can not make geo queries. Without these queries the question of
having a geo server is quite useless ...
But we could think of a "flavor" or variant ;) where the geo data is not
persisted but just pass through (to a queue, another REST endpoint), It will more act
then like a broker, but again not sure if I can find a usecase for that.
> Couldn't admin
> specify a range and check how many devices are active on that region?
> Into this way you don't need to store their positions. I'm not the Geo
> specialist here but the idea is:
>
> 1. Admin specify the range when a push message must be sent. For
> example: Whole Florida
> 2. Client opt in and sent her its position to the server
> 3. Server compares and sent the push message
>
> I'm very concerned about privacy here, I'm not against the
> solution, but Geo location is like to open a Pandora box.
>
yeah, it's also creepy :) I have not much services that I give my geo data
>
> We might be careful about unintentional disclosure of geolocation
> information,
> because it carries physical risks to the client (theft, to stalking,
> kidnapping
> and domestic violence — I'm not exaggerating).
>
+1 I'd argue that the "Geo server" would be, initially, a 'simple'
back
end, that is able to store n pairs of long/lat values (grouped by a
user/device).
The mobile SDK for it basically store the 'collected' data to this backend
(somewhat similar to the push registration SDK)
>
> Again, I know this is a proof of concept, but sooner we have it in mind,
> the
> better.
>
+1 fully agree. Replied to your questions with my POV on this
>
>
>
>
> On 2014-12-10, Sebastien Blanc wrote:
> > Hi all,
> >
> > I have been working on a POC around geolocation. Like we discussed in
> > another thread, we decided not to have a "deep" integration with the
Push
> > server but instead a separate component / microservice. Well the POC is
> > more a miniservice ;)
> >
> > So, the idea is to have a server to which devices can register by
> providing
> > their positions. On the other side, the server provide an endpoint to
> make
> > spatial queries, like give me all the installations within a radius of 10
> > km around this lat/ltg.
> >
> > Thanks to Forge, I created/scaffolded a really simple server providing
> the
> > registration endpoint and the search endpoint.
> >
> > I tried to make a decent readme that will give you more details :
> >
> > https://github.com/sebastienblanc/unified-geo-server
> >
> > And as usual, I made a little screencast showing all that in action ;)
> >
> > https://www.youtube.com/watch?v=R-qdLJh4EWQ
> >
> > Please remember this is a POC, so the security is almost inexistant, the
> > console is awful ;)
> >
> > What about the Client SDKs ?
> >
> > If we reach some kind of consensus arounf the concept of Unfied Geo
> Server
> > we can start building the Client SDKs / POCs , they will be quite simple
> :
> > retrieve geolocation and register to the geo endpoint.
> >
> > Sebi
>
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
> --
>
> abstractj
> PGP: 0x84DC9914
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
abstractj
PGP: 0x84DC9914
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
10:01 a.m.
On Sat, Dec 20, 2014 at 9:00 PM, Raj Nukala <rajnukala(a)yahoo.com> wrote:
Great work sebi . How frequently are the lat longs sent to the geo
server?
This will be configurable and will depend on the native platform
capabilities
and what is the backend db for the geo server ? is it mongo ?
In this POC, the DB is not really relevant (I use H2) because the geo
search is performed by Hibernate Search (that use Lucene). But it would be
nice to have this POC working with a mongodb since it supports "natively"
geospatial queries.
Regards
------------------------------
*From:* Sebastien Blanc <scm.blanc(a)gmail.com>
*To:* AeroGear Developer Mailing List <aerogear-dev(a)lists.jboss.org>
*Sent:* Monday, December 15, 2014 6:10 PM
*Subject:* Re: [aerogear-dev] [POC] Unified Geo Server
On Mon, Dec 15, 2014 at 11:32 PM, Bruno Oliveira <bruno(a)abstractj.org>
wrote:
On 2014-12-15, Matthias Wessendorf wrote:
> On Mon, Dec 15, 2014 at 9:08 PM, Bruno Oliveira <bruno(a)abstractj.org>
wrote:
> >
> > Good morning, first nice screencast Sebi and even knowing this is just
a
> > PoC I have some considerations:
> >
> > 1. What would be the use case scenario to justify a separated server
> > instead of just a module on AGPUSH?
> >
>
> I think main discussion around this at F2F meeting was, it might be
useful
> for other scenarios as well,
> and we don't want to hard-wire geo to the push server
Which scenarios?
The are several scenarios where geo is needed without push.
For instance, think of a backend system for a transport company that needs
to run analysis each night based on the current location of the truck
drivers in order to plan efficiently the logistics for the next day.
>
>
>
> >
> > 2. How do you plan to prevent people from faking their location?
> >
>
> I'd assume that a Geo SDK would be based on-top of the mobile OS's
> facility, to receive the long/lat values.
> I think in the future we can have some sort of checks, like validating
the
> users IP address, if it somewhat matches the submitted geo data.
I think Geo based on IPs are a bad idea. This is a very inaccurate method
and should be our last resort, it's easy to spoof IPs.
>
>
>
> >
> > 3. Do we have a privacy policy to make the developer real aware about
> > what's being collected?
> >
>
> I think that the level of collected geo data is up to the developer of
the
> app, using the Geo SDK.
I'm sorry, but I have to disagree. If we don't provide a policy about the
usage of the Geo
server, we're pretty much accountable for it.
Nothing huge, only a simple txt documenting what's being collected and
why.
>
>
> >
> > 4. Will collecting geo location be opt in or default?
> >
>
> If the Geo-data SDK is used w/in an app, I think it will still ask,
> up-front, if location based services are OK to use (at least apple). And
> I'd argue that users can still disable the geo usage, per app (at least
> apple)
Most of users have no idea that their data is being collected. I'm
confused about your answer, is that an yes or no?
I think what Matthias means is that when using gelolocation on the device,
being iOS, Android or even Web, the users will be prompted to allow or not
access to his geodata. So, yes it's an opt-in and also, like Matthias said
a the possibility to opt-out.
>
>
>
>
> >
> > 5. Why is necessary to store current user's position?
>
>
> I think that's up to the use case, and its usage of the Geo SDK.
Currently we store. I know this is just a proof of concept.
But I insist to be the boring, and avoid it if possible.
If we don't store we can not make geo queries. Without these queries the
question of having a geo server is quite useless ...
But we could think of a "flavor" or variant ;) where the geo data is not
persisted but just pass through (to a queue, another REST endpoint), It
will more act then like a broker, but again not sure if I can find a
usecase for that.
>
>
> > Couldn't admin
> > specify a range and check how many devices are active on that region?
> > Into this way you don't need to store their positions. I'm not the Geo
> > specialist here but the idea is:
> >
> > 1. Admin specify the range when a push message must be sent. For
> > example: Whole Florida
> > 2. Client opt in and sent her its position to the server
> > 3. Server compares and sent the push message
> >
> > I'm very concerned about privacy here, I'm not against the
> > solution, but Geo location is like to open a Pandora box.
> >
>
> yeah, it's also creepy :) I have not much services that I give my geo
data
>
>
> >
> > We might be careful about unintentional disclosure of geolocation
> > information,
> > because it carries physical risks to the client (theft, to stalking,
> > kidnapping
> > and domestic violence — I'm not exaggerating).
> >
>
> +1 I'd argue that the "Geo server" would be, initially, a
'simple' back
> end, that is able to store n pairs of long/lat values (grouped by a
> user/device).
> The mobile SDK for it basically store the 'collected' data to this
backend
> (somewhat similar to the push registration SDK)
>
>
> >
> > Again, I know this is a proof of concept, but sooner we have it in
mind,
> > the
> > better.
> >
>
> +1 fully agree. Replied to your questions with my POV on this
>
>
>
> >
> >
> >
> >
> > On 2014-12-10, Sebastien Blanc wrote:
> > > Hi all,
> > >
> > > I have been working on a POC around geolocation. Like we discussed in
> > > another thread, we decided not to have a "deep" integration with
the
Push
> > > server but instead a separate component / microservice. Well the POC
is
> > > more a miniservice ;)
> > >
> > > So, the idea is to have a server to which devices can register by
> > providing
> > > their positions. On the other side, the server provide an endpoint to
> > make
> > > spatial queries, like give me all the installations within a radius
of 10
> > > km around this lat/ltg.
> > >
> > > Thanks to Forge, I created/scaffolded a really simple server
providing
> > the
> > > registration endpoint and the search endpoint.
> > >
> > > I tried to make a decent readme that will give you more details :
> > >
> > > https://github.com/sebastienblanc/unified-geo-server
> > >
> > > And as usual, I made a little screencast showing all that in action
;)
> > >
> > > https://www.youtube.com/watch?v=R-qdLJh4EWQ
> > >
> > > Please remember this is a POC, so the security is almost inexistant,
the
> > > console is awful ;)
> > >
> > > What about the Client SDKs ?
> > >
> > > If we reach some kind of consensus arounf the concept of Unfied Geo
> > Server
> > > we can start building the Client SDKs / POCs , they will be quite
simple
> > :
> > > retrieve geolocation and register to the geo endpoint.
> > >
> > > Sebi
> >
> > > _______________________________________________
> > > aerogear-dev mailing list
> > > aerogear-dev(a)lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >
> >
> > --
> >
> > abstractj
> > PGP: 0x84DC9914
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
abstractj
PGP: 0x84DC9914
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
6:13 a.m.
On Mon, Dec 15, 2014 at 11:32 PM, Bruno Oliveira <bruno(a)abstractj.org>
wrote:
On 2014-12-15, Matthias Wessendorf wrote:
> On Mon, Dec 15, 2014 at 9:08 PM, Bruno Oliveira <bruno(a)abstractj.org>
wrote:
> >
> > Good morning, first nice screencast Sebi and even knowing this is just
a
> > PoC I have some considerations:
> >
> > 1. What would be the use case scenario to justify a separated server
> > instead of just a module on AGPUSH?
> >
>
> I think main discussion around this at F2F meeting was, it might be
useful
> for other scenarios as well,
> and we don't want to hard-wire geo to the push server
Which scenarios?
anything else that may require geo data. E.g. other systems may benefit
from interacting with geo as well.
I really do not see a reason why geo is hard-wired to push.
the geo server should be a system to store any sorts of geo data (long/lat)
+ some APIs to query.
>
>
>
> >
> > 2. How do you plan to prevent people from faking their location?
> >
>
> I'd assume that a Geo SDK would be based on-top of the mobile OS's
> facility, to receive the long/lat values.
> I think in the future we can have some sort of checks, like validating
the
> users IP address, if it somewhat matches the submitted geo data.
I think Geo based on IPs are a bad idea. This is a very inaccurate method
and should be our last resort, it's easy to spoof IPs.
:-) yeah. I'd assume that we offer minimal/simple SDKs for iOS/Android,
which underneath
leverage the OS facilities for Geo-Data. Like CoreLocation on iOS.
Regarding the IP, I had this in mind (not sure if that is a good idea or
not):
* if long/lat (can be faked with man-in-the-middle) says Germany, but IP
says singapore,
our server could see: something is wrong.
or if we get weird long/lats from the same device (.e.g. 12:00 Germany,
12:30 UK, 14:00 USA, 14:30 China),
we might know something is wrong too. But that's perhaps not for the
initial scope of the poc
>
>
>
> >
> > 3. Do we have a privacy policy to make the developer real aware about
> > what's being collected?
> >
>
> I think that the level of collected geo data is up to the developer of
the
> app, using the Geo SDK.
I'm sorry, but I have to disagree. If we don't provide a policy about the
usage of the Geo
server, we're pretty much accountable for it.
Nothing huge, only a simple txt documenting what's being collected and
why.
I'd think that, if we provide an SDK (and the POC will get us there), we do
not really track anything 'silently'.
I hope that the SDK would allow me to get the current position (e.g. using
CoreLocation), and store it with a name (e.g. home, work, my fav. cinema)
and some metadata (e.g. username).
But I'd not imagine our SDK constantly tracks all positions and silently
sends them to the Geo Server.
>
>
> >
> > 4. Will collecting geo location be opt in or default?
> >
>
> If the Geo-data SDK is used w/in an app, I think it will still ask,
> up-front, if location based services are OK to use (at least apple). And
> I'd argue that users can still disable the geo usage, per app (at least
> apple)
Most of users have no idea that their data is being collected. I'm
confused about your answer, is that an yes or no?
I mean yes, see above.
-MAtthias
>
>
>
>
> >
> > 5. Why is necessary to store current user's position?
>
>
> I think that's up to the use case, and its usage of the Geo SDK.
Currently we store. I know this is just a proof of concept.
But I insist to be the boring, and avoid it if possible.
>
>
> > Couldn't admin
> > specify a range and check how many devices are active on that region?
> > Into this way you don't need to store their positions. I'm not the Geo
> > specialist here but the idea is:
> >
> > 1. Admin specify the range when a push message must be sent. For
> > example: Whole Florida
> > 2. Client opt in and sent her its position to the server
> > 3. Server compares and sent the push message
> >
> > I'm very concerned about privacy here, I'm not against the
> > solution, but Geo location is like to open a Pandora box.
> >
>
> yeah, it's also creepy :) I have not much services that I give my geo
data
>
>
> >
> > We might be careful about unintentional disclosure of geolocation
> > information,
> > because it carries physical risks to the client (theft, to stalking,
> > kidnapping
> > and domestic violence — I'm not exaggerating).
> >
>
> +1 I'd argue that the "Geo server" would be, initially, a
'simple' back
> end, that is able to store n pairs of long/lat values (grouped by a
> user/device).
> The mobile SDK for it basically store the 'collected' data to this
backend
> (somewhat similar to the push registration SDK)
>
>
> >
> > Again, I know this is a proof of concept, but sooner we have it in
mind,
> > the
> > better.
> >
>
> +1 fully agree. Replied to your questions with my POV on this
>
>
>
> >
> >
> >
> >
> > On 2014-12-10, Sebastien Blanc wrote:
> > > Hi all,
> > >
> > > I have been working on a POC around geolocation. Like we discussed in
> > > another thread, we decided not to have a "deep" integration with
the
Push
> > > server but instead a separate component / microservice. Well the POC
is
> > > more a miniservice ;)
> > >
> > > So, the idea is to have a server to which devices can register by
> > providing
> > > their positions. On the other side, the server provide an endpoint to
> > make
> > > spatial queries, like give me all the installations within a radius
of 10
> > > km around this lat/ltg.
> > >
> > > Thanks to Forge, I created/scaffolded a really simple server
providing
> > the
> > > registration endpoint and the search endpoint.
> > >
> > > I tried to make a decent readme that will give you more details :
> > >
> > > https://github.com/sebastienblanc/unified-geo-server
> > >
> > > And as usual, I made a little screencast showing all that in action
;)
> > >
> > > https://www.youtube.com/watch?v=R-qdLJh4EWQ
> > >
> > > Please remember this is a POC, so the security is almost inexistant,
the
> > > console is awful ;)
> > >
> > > What about the Client SDKs ?
> > >
> > > If we reach some kind of consensus arounf the concept of Unfied Geo
> > Server
> > > we can start building the Client SDKs / POCs , they will be quite
simple
> > :
> > > retrieve geolocation and register to the geo endpoint.
> > >
> > > Sebi
> >
> > > _______________________________________________
> > > aerogear-dev mailing list
> > > aerogear-dev(a)lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >
> >
> > --
> >
> > abstractj
> > PGP: 0x84DC9914
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
abstractj
PGP: 0x84DC9914
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
6:42 p.m.
This is great . I missed the screencast is there a recording somewhere?
For my project i need geofencing features and if only this is well documented and there is
a binary i would love to use it .
RegardsRaj
From: Matthias Wessendorf <matzew(a)apache.org>
To: AeroGear Developer Mailing List <aerogear-dev(a)lists.jboss.org>
Sent: Tuesday, December 16, 2014 12:13 AM
Subject: Re: [aerogear-dev] [POC] Unified Geo Server
On Mon, Dec 15, 2014 at 11:32 PM, Bruno Oliveira <bruno(a)abstractj.org> wrote:
On 2014-12-15, Matthias Wessendorf wrote:
On Mon, Dec 15, 2014 at 9:08 PM, Bruno Oliveira
<bruno(a)abstractj.org> wrote:
>
> Good morning, first nice screencast Sebi and even knowing this is just a
> PoC I have some considerations:
>
> 1. What would be the use case scenario to justify a separated server
> instead of just a module on AGPUSH?
>
I think main discussion around this at F2F meeting was, it might be useful
for other scenarios as well,
and we don't want to hard-wire geo to the push server
Which scenarios?
anything else that may require geo data. E.g. other systems may benefit from interacting
with geo as well.I really do not see a reason why geo is hard-wired to push.
the geo server should be a system to store any sorts of geo data (long/lat) + some APIs to
query.
>
> 2. How do you plan to prevent people from faking their location?
>
I'd assume that a Geo SDK would be based on-top of the mobile OS's
facility, to receive the long/lat values.
I think in the future we can have some sort of checks, like validating the
users IP address, if it somewhat matches the submitted geo data.
I think Geo based on IPs are a bad idea. This is a very inaccurate method
and should be our last resort, it's easy to spoof IPs.
:-) yeah. I'd assume that we offer minimal/simple SDKs for iOS/Android, which
underneathleverage the OS facilities for Geo-Data. Like CoreLocation on iOS.
Regarding the IP, I had this in mind (not sure if that is a good idea or not):* if
long/lat (can be faked with man-in-the-middle) says Germany, but IP says singapore,our
server could see: something is wrong.
or if we get weird long/lats from the same device (.e.g. 12:00 Germany, 12:30 UK, 14:00
USA, 14:30 China),we might know something is wrong too. But that's perhaps not for the
initial scope of the poc
>
> 3. Do we have a privacy policy to make the developer real aware about
> what's being collected?
>
I think that the level of collected geo data is up to the developer of the
app, using the Geo SDK.
I'm sorry, but I have to disagree. If we don't provide a policy about the usage of
the Geo
server, we're pretty much accountable for it.
Nothing huge, only a simple txt documenting what's being collected and
why.
I'd think that, if we provide an SDK (and the POC will get us there), we do not really
track anything 'silently'.I hope that the SDK would allow me to get the current
position (e.g. using CoreLocation), and store it with a name (e.g. home, work, my fav.
cinema) and some metadata (e.g. username).
But I'd not imagine our SDK constantly tracks all positions and silently sends them to
the Geo Server.
>
> 4. Will collecting geo location be opt in or default?
>
If the Geo-data SDK is used w/in an app, I think it will still ask,
up-front, if location based services are OK to use (at least apple). And
I'd argue that users can still disable the geo usage, per app (at least
apple)
Most of users have no idea that their data is being collected. I'm
confused about your answer, is that an yes or no?
I mean yes, see above.
-MAtthias
>
> 5. Why is necessary to store current user's position?
I think that's up to the use case, and its usage of the Geo SDK.
Currently we store. I know this is just a proof of concept.
But I insist to be the boring, and avoid it if possible.
> Couldn't admin
> specify a range and check how many devices are active on that region?
> Into this way you don't need to store their positions. I'm not the Geo
> specialist here but the idea is:
>
> 1. Admin specify the range when a push message must be sent. For
> example: Whole Florida
> 2. Client opt in and sent her its position to the server
> 3. Server compares and sent the push message
>
> I'm very concerned about privacy here, I'm not against the
> solution, but Geo location is like to open a Pandora box.
>
yeah, it's also creepy :) I have not much services that I give my geo data
>
> We might be careful about unintentional disclosure of geolocation
> information,
> because it carries physical risks to the client (theft, to stalking,
> kidnapping
> and domestic violence — I'm not exaggerating).
>
+1 I'd argue that the "Geo server" would be, initially, a 'simple'
back
end, that is able to store n pairs of long/lat values (grouped by a
user/device).
The mobile SDK for it basically store the 'collected' data to this backend
(somewhat similar to the push registration SDK)
>
> Again, I know this is a proof of concept, but sooner we have it in mind,
> the
> better.
>
+1 fully agree. Replied to your questions with my POV on this
>
>
>
>
> On 2014-12-10, Sebastien Blanc wrote:
> > Hi all,
> >
> > I have been working on a POC around geolocation. Like we discussed in
> > another thread, we decided not to have a "deep" integration with the
Push
> > server but instead a separate component / microservice. Well the POC is
> > more a miniservice ;)
> >
> > So, the idea is to have a server to which devices can register by
> providing
> > their positions. On the other side, the server provide an endpoint to
> make
> > spatial queries, like give me all the installations within a radius of 10
> > km around this lat/ltg.
> >
> > Thanks to Forge, I created/scaffolded a really simple server providing
> the
> > registration endpoint and the search endpoint.
> >
> > I tried to make a decent readme that will give you more details :
> >
> > https://github.com/sebastienblanc/unified-geo-server
> >
> > And as usual, I made a little screencast showing all that in action ;)
> >
> > https://www.youtube.com/watch?v=R-qdLJh4EWQ
> >
> > Please remember this is a POC, so the security is almost inexistant, the
> > console is awful ;)
> >
> > What about the Client SDKs ?
> >
> > If we reach some kind of consensus arounf the concept of Unfied Geo
> Server
> > we can start building the Client SDKs / POCs , they will be quite simple
> :
> > retrieve geolocation and register to the geo endpoint.
> >
> > Sebi
>
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
> --
>
> abstractj
> PGP: 0x84DC9914
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
abstractj
PGP: 0x84DC9914
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
9:59 a.m.
On Sat, Dec 20, 2014 at 6:42 PM, Raj Nukala <rajnukala(a)yahoo.com> wrote:
This is great .
Thx
I missed the screencast is there a recording somewhere?
Sure, you can watch it here https://www.youtube.com/watch?v=R-qdLJh4EWQ
For my project i need geofencing features and if only this is well
documented and there is a binary i would love to use it .
It's not (yet) related to the Geo Server but we have a geofencing Cordova
plugin : https://github.com/aerogear/aerogear-geo-cordova
Regards
Raj
------------------------------
*From:* Matthias Wessendorf <matzew(a)apache.org>
*To:* AeroGear Developer Mailing List <aerogear-dev(a)lists.jboss.org>
*Sent:* Tuesday, December 16, 2014 12:13 AM
*Subject:* Re: [aerogear-dev] [POC] Unified Geo Server
On Mon, Dec 15, 2014 at 11:32 PM, Bruno Oliveira <bruno(a)abstractj.org>
wrote:
On 2014-12-15, Matthias Wessendorf wrote:
> On Mon, Dec 15, 2014 at 9:08 PM, Bruno Oliveira <bruno(a)abstractj.org>
wrote:
> >
> > Good morning, first nice screencast Sebi and even knowing this is just
a
> > PoC I have some considerations:
> >
> > 1. What would be the use case scenario to justify a separated server
> > instead of just a module on AGPUSH?
> >
>
> I think main discussion around this at F2F meeting was, it might be
useful
> for other scenarios as well,
> and we don't want to hard-wire geo to the push server
Which scenarios?
anything else that may require geo data. E.g. other systems may benefit
from interacting with geo as well.
I really do not see a reason why geo is hard-wired to push.
the geo server should be a system to store any sorts of geo data
(long/lat) + some APIs to query.
>
>
>
> >
> > 2. How do you plan to prevent people from faking their location?
> >
>
> I'd assume that a Geo SDK would be based on-top of the mobile OS's
> facility, to receive the long/lat values.
> I think in the future we can have some sort of checks, like validating
the
> users IP address, if it somewhat matches the submitted geo data.
I think Geo based on IPs are a bad idea. This is a very inaccurate method
and should be our last resort, it's easy to spoof IPs.
:-) yeah. I'd assume that we offer minimal/simple SDKs for iOS/Android,
which underneath
leverage the OS facilities for Geo-Data. Like CoreLocation on iOS.
Regarding the IP, I had this in mind (not sure if that is a good idea or
not):
* if long/lat (can be faked with man-in-the-middle) says Germany, but IP
says singapore,
our server could see: something is wrong.
or if we get weird long/lats from the same device (.e.g. 12:00 Germany,
12:30 UK, 14:00 USA, 14:30 China),
we might know something is wrong too. But that's perhaps not for the
initial scope of the poc
>
>
>
> >
> > 3. Do we have a privacy policy to make the developer real aware about
> > what's being collected?
> >
>
> I think that the level of collected geo data is up to the developer of
the
> app, using the Geo SDK.
I'm sorry, but I have to disagree. If we don't provide a policy about the
usage of the Geo
server, we're pretty much accountable for it.
Nothing huge, only a simple txt documenting what's being collected and
why.
I'd think that, if we provide an SDK (and the POC will get us there), we
do not really track anything 'silently'.
I hope that the SDK would allow me to get the current position (e.g. using
CoreLocation), and store it with a name (e.g. home, work, my fav. cinema)
and some metadata (e.g. username).
But I'd not imagine our SDK constantly tracks all positions and silently
sends them to the Geo Server.
>
>
> >
> > 4. Will collecting geo location be opt in or default?
> >
>
> If the Geo-data SDK is used w/in an app, I think it will still ask,
> up-front, if location based services are OK to use (at least apple). And
> I'd argue that users can still disable the geo usage, per app (at least
> apple)
Most of users have no idea that their data is being collected. I'm
confused about your answer, is that an yes or no?
I mean yes, see above.
-MAtthias
>
>
>
>
> >
> > 5. Why is necessary to store current user's position?
>
>
> I think that's up to the use case, and its usage of the Geo SDK.
Currently we store. I know this is just a proof of concept.
But I insist to be the boring, and avoid it if possible.
>
>
> > Couldn't admin
> > specify a range and check how many devices are active on that region?
> > Into this way you don't need to store their positions. I'm not the Geo
> > specialist here but the idea is:
> >
> > 1. Admin specify the range when a push message must be sent. For
> > example: Whole Florida
> > 2. Client opt in and sent her its position to the server
> > 3. Server compares and sent the push message
> >
> > I'm very concerned about privacy here, I'm not against the
> > solution, but Geo location is like to open a Pandora box.
> >
>
> yeah, it's also creepy :) I have not much services that I give my geo
data
>
>
> >
> > We might be careful about unintentional disclosure of geolocation
> > information,
> > because it carries physical risks to the client (theft, to stalking,
> > kidnapping
> > and domestic violence — I'm not exaggerating).
> >
>
> +1 I'd argue that the "Geo server" would be, initially, a
'simple' back
> end, that is able to store n pairs of long/lat values (grouped by a
> user/device).
> The mobile SDK for it basically store the 'collected' data to this
backend
> (somewhat similar to the push registration SDK)
>
>
> >
> > Again, I know this is a proof of concept, but sooner we have it in
mind,
> > the
> > better.
> >
>
> +1 fully agree. Replied to your questions with my POV on this
>
>
>
> >
> >
> >
> >
> > On 2014-12-10, Sebastien Blanc wrote:
> > > Hi all,
> > >
> > > I have been working on a POC around geolocation. Like we discussed in
> > > another thread, we decided not to have a "deep" integration with
the
Push
> > > server but instead a separate component / microservice. Well the POC
is
> > > more a miniservice ;)
> > >
> > > So, the idea is to have a server to which devices can register by
> > providing
> > > their positions. On the other side, the server provide an endpoint to
> > make
> > > spatial queries, like give me all the installations within a radius
of 10
> > > km around this lat/ltg.
> > >
> > > Thanks to Forge, I created/scaffolded a really simple server
providing
> > the
> > > registration endpoint and the search endpoint.
> > >
> > > I tried to make a decent readme that will give you more details :
> > >
> > > https://github.com/sebastienblanc/unified-geo-server
> > >
> > > And as usual, I made a little screencast showing all that in action
;)
> > >
> > > https://www.youtube.com/watch?v=R-qdLJh4EWQ
> > >
> > > Please remember this is a POC, so the security is almost inexistant,
the
> > > console is awful ;)
> > >
> > > What about the Client SDKs ?
> > >
> > > If we reach some kind of consensus arounf the concept of Unfied Geo
> > Server
> > > we can start building the Client SDKs / POCs , they will be quite
simple
> > :
> > > retrieve geolocation and register to the geo endpoint.
> > >
> > > Sebi
> >
> > > _______________________________________________
> > > aerogear-dev mailing list
> > > aerogear-dev(a)lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >
> >
> > --
> >
> > abstractj
> > PGP: 0x84DC9914
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
abstractj
PGP: 0x84DC9914
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
3390
days inactive
3418
days old
23 comments
9 participants
participants (9)
-
Andres Galante -
Bruno Oliveira -
Corinne Krych -
Daniel Bevenius -
Erik Jan de Wit -
Matthias Wessendorf -
Raj Nukala -
Sebastien Blanc -
Sébastien Blanc