On Thu, Nov 27, 2014 at 11:05 PM, Matthias Wessendorf <matzew(a)apache.org>
wrote:
Hrm,
not sure on that hard integration. Originally we thought about something
like:
1) write little native libs (Android/iOS) that help to collect long/lat.
2) combine them with the registration SDK
If location is enabled/allowed, store the long/lat to _a_ database - not
the database of the existing metadata. So that would be a completely
different REST api hook
We could even model that as a separate (micro) service.
Yes, after thinking about this over the weekend, I like that :)
Some kind of independant server/(micro-service) , a sort of UGS (Unified
Geo Server ;) ).
It would offer 2 endpoints :
- registration / updating of geo data coupled with an "alias" / devicetoken
or smt else we have to agree on.
- a "search" api that returns the aliases or devicetokens
Then the question is, do we want this service to interact directly with the
clients/devices ? Or that UPS "talks" with that geoserver and act a bit
like a broker ? One benefit of this latest approach is that this geoserver
could be in the same KC realm as UPS.
Currently I am not sure if it's a good idea to blow up the metadata (with
geo data) and doing the same for the sender.
On Thu, Nov 27, 2014 at 5:52 PM, Sebastien Blanc <scm.blanc(a)gmail.com>
wrote:
> Hi Folks !
>
> During our last f2f we agreed on adding some geolocation support for the
> next UnifiedPush Release (1.1). I would like to start here a thread to
> discuss this topic.
>
> Let's keep in mind : *Crawl, Walk, Run*
>
> I would like to start with a concrete proposition and initiate the
> discussions from there :
>
> <
https://gist.github.com/sebastienblanc/d89e41b72c9de537dbde#installations...
> Installations
>
<
https://gist.github.com/sebastienblanc/d89e41b72c9de537dbde#model-change&...
> Change
>
> The idea is to add 2 new fields to the Installation Object :
>
> double longitude;
> double latitude;
>
>
> These field *should* be optional !
> <
https://gist.github.com/sebastienblanc/d89e41b72c9de537dbde#registration>
> Registration
>
> When the device registers, along with alias, categories etc ... it will
> also be possible to pass a latitude and longitude.
>
> Later, we will probably offer a endpoint to update these properties. PUT
> /registry/device/{token}
> <
https://gist.github.com/sebastienblanc/d89e41b72c9de537dbde#sender>
> Sender
>
<
https://gist.github.com/sebastienblanc/d89e41b72c9de537dbde#server-side&g...
> Side
>
> We need to extend the current sender API to be able to add geolocation as
> a criteria. I see that as something like :
>
> {
> "message":{
> "alert":"HELLO!
> },
> "criteria":{
> "geolocation":
> {
> "latitude" : 40.2566
> "longitude": 2.36556
> "within" : 5
> "unit" : "Km" // optional, default is Km
> }
> }
> }
>
>
> In this example, the Push Notification will be sent only to devices
> within a radius of 5 km of the supplied location.
>
> On the implementation side, I think it make sense to use Hibernate Search
> since it has nice support forSpatial queries
>
<
https://docs.jboss.org/hibernate/search/4.2/reference/en-US/html/spatial....
> .
>
>
<
https://gist.github.com/sebastienblanc/d89e41b72c9de537dbde#sender-client...
> Client
>
> The different Sender Clients (Java, Node.js, .net) should be updated
> accordingly.
>
<
https://gist.github.com/sebastienblanc/d89e41b72c9de537dbde#client-sdks&g...
> SDKs
>
> In this fisrt iteration, the registration code would to be updated to
> include latitude and longitude for :
>
> - iOS (Including Safari ? )
> - Android ( Including Chrome Apps ?)
> - JS UPS-SPS Lib
> - Cordova Plugin
> - Amazon
> - Windows
>
> Retrieving the current position of the device is not in scope of this
> first version, later we could offer some features around that.
>
> There are some jiras to track these tasks :
>
https://issues.jboss.org/browse/AGPUSH-828
>
> Comments and questions welcome !
>
> Sebi
>
> _______________________________________________
> 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