[Devel] Updated geolocation and navigation design document

[Philip Withnall]

Hi Andre,

I think, if you agree with my reasoning below about choosing a library
over a service/daemon, then we agree about everything and I can update
the design to include the results of all this discussion. If so, I will
try and get it done and internally reviewed by the end of this week.

On Thu, 2016-02-11 at 15:09 +0000, Barkowski Andre (CM-CI1/PRM1) wrote:
> ok, again a step closer to each other. The discussion how is
> something realized (as library or with a dbus api), is of second 
> level detail for me. I still try to clarify the first level
> interests, which is functional deployment & related responsibility of
> code, and if you say something like "Apps are merging POIs with the
> route list", then I understand  that this is part of their code-
> responsibility. But know you clarified, that you intended to provide
> a library for them, so you are more looking from process point of
> view. That is a different level compared to my point of view, so we
> talk past each other a little. All that aspects, process boundaries,
> implementation decisions (library vs messaging) etc, are out of my
> focus at this point in time. Please try to keep that in mind in our
> future discussion.
> So independent if based on a library or dbus (lets discuss that
> later), there is a prepared central solution exposed via an SDK-API
> which applications can use to access aggregated data (POI merged into
> route list). In your current thinking, the solution would be a
> library and internally call the SDK route list API and peer to peer
> POI APIs

Correct.

> At this point the remaining thing of interest for me is, if based on
> this 2 API types (route list & POI) all functionality to be provided
> can be covered.
> Then to prevent misunderstanding:
> >> - we can push the aggregation capabilities of the central service
> w/o impact to app-code / responsibilities
> >> - we can optionally tune the aggregation policies / algorithms
> accordant to OEM requirements per product
> >These are things which I thought we were explicitly avoiding? As I
> >understand it, you want the //providers// of POIs to be in control
> of
> >which of their POIs are added to the route or sent to other
> >applications.
> >It’s certainly possible for a central service to do this instead,
> but it means moving some or all of the responsibility for deciding
> which POIs are shown from POI providers to this centralised service.
> Yes, but please distinguish between both parts: its like 2 steps,
> first the Providing App decides with its build in policy what to
> send. That right and good to see that you keep an eye on it. But its
> up to the consuming App to process it with its build in algorithms,
> and in that regard there is a second step where a policy is
> implemented, deciding which of the received content (POIs) to
> consider how. Since the aggregation takes place in this central
> component, this implementation decides who to deal with duplicates,
> etc so with the final result. This implementation can be tuned, in
> regard to capabilities as also OEM specific policy.  So I do not mean
> to shift things completely away out of the App scope, its simple 2
> steps, Providers decide what to provide, consumers decide how to
> process and about the final result.

OK, that’s possible in the design, regardless of whether the
aggregation is implemented as a library or as a service. If you want
the aggregation to be //enforced//, then it must be implemented as a
service, not a library.

If applications accessed the POI API through an aggregation library, it
could implement any aggregation policy you wish — but if the
application wanted to bypass this policy, it could use the POI API
directly to get the full, unfiltered stream of POIs.

I suspect you do not want the aggregation to be enforced, however, and
want to follow our normal approach of giving the application a high-
level API which does what 90% of applications want (a library which
implements the recommended POI aggregation policy) but allow the 10% of
applications which need special behaviour to use the SDK POI API
directly and perform their own aggregation. (In fact, you’ve said that
below: “where ever we have higher level APIs, we recommend to use them
instead of the low-level ones”, so I’m satisfied.)

> And to follow up with the next topic: yes, we want the ability to
> display the routelist (but no POIs) as an overlay on a libchamplain
> map. That’s unchanged and thx that you keep an eye on it.

OK.

> From my point of view, we now have a common understanding for the
> (high level) scope which I was looking at.

Yes, I feel that too.

> So the remaining discussion now gets reduced to the implementation
> detail of the “horizon component” - which aggregates the low level
> data (route list and POIs) - if it should be a library or a dbus-
> service.
> …
> I like to ask you to reflect and discuss the various aspects of both
> approaches again and to follow up afterwards.

As Simon has said, this is partially a performance matter, and
partially a privilege separation matter.

If we consider memory usage, I think that using a service/daemon for
the aggregation would actually increase memory usage, as each POI would
have to be stored fin the service’s memory for aggregation, plus also
in the memory of each consumer application which is displaying the POI
in its UI. In contrast, a point-to-point implementation only stores the
POIs in the memory of each consumer application. (Both implementations
may also require a copy in the memory of each //producer// application,
depending on how that application produces POIs and whether it needs to
retain them for later processing.)

The main advantage of using a service/daemon is that if aggregation is
expensive in CPU time, or results in a large proportion of POIs being
filtered out, a service means that work is only done once rather than
once for each consumer application.

However, in the case of points of interest, aggregation should be
simply merging points of interest with (for example) the same name and
coordinates, which does not require much CPU power. I don’t expect that
many points of interest would be filtered out.

In contrast, aggregating contacts in libfolks is quite a CPU-intensive
process, as multiple properties need to be checked between all pairs of
contacts (which may number in the thousands) — this is one reason why a
service/daemon-based architecture would be a suitable alternative way
of implementing libfolks.

So overall I would suggest using a library, rather than a daemon.

> An one minor remark, only to take care we are on the same page in
> that too -  like in all other app-centric concepts the User has the
> final control about interaction between Apps. It starts for sure with
> his personal selection of Apps from store – and with that with the
> candidates who are installed in the system - but it continues with
> the detailed selection out of the installed ones which are allowed to
> provide data (POIs) to the horizon as also to consume it. Its some
> kind of per App switch in the settings, if the app is allowed to
> provide data to it as also a switch if it is allowed to access it
> (similar like with access to other databases, like contact, photos,
> etc).
> And this data provider role of an app should also “run” during the
> app is not in foreground. And to minimize system load, we would
> request to provide an agent for this dedicated task, which starts
> with the system startup and keeps running until system shutdown with
> some appropriate scheduling and small resource needs.
> But that is nothing special for this use-case, this is a general
> pattern for apps interacting with OS services.

Noted.

> -----Ursprüngliche Nachricht-----
> Von: Philip Withnall [mailto:philip.withnall at collabora.co.uk]
> Gesendet: Dienstag, 9. Februar 2016 15:50
> An: Barkowski Andre (CM-CI1/PRM1) <Andre.Barkowski at de.bosch.com>; dev
> el at lists.apertis.org
> Betreff: Re: AW: AW: AW: AW: AW: AW: AW: AW: [Devel] Updated
> geolocation and navigation design document
> 
> I see what you mean. My thinking behind providing the route list and
> POIs separately are because other parts of the geolocation design
> require them separately — you wanted the ability to display the route
> list (but no POIs) as an overlay on a libchamplain map in an
> application, for example. So a route list API has to exist; and if
> that
> exists, and the peer-to-peer POI API already exists, why not use the
> two to provide the horizon to applications?
> Andre: yes, that needs to be supported
> In general I see this like higher level APIs of same kind, similar
> like in UI-customization where we come from raw APIs, via some
> building blocks up to well-prepared templates, in this scope coming
> from also raw entities to aggregated ones. So looks like we are on
> the same page for that.

Yes, indeed.

> > And I am not only talking about combining routes from various
> > Sources(Apps). That’s only an example to point out challenges. So
> > don't forget the more common case to add additional objects like
> POIs
> > to a given Route, as also to add attributes (metadata) to already
> > available objects.
> >
> > Once this service is available, we do _not_ need any public route-
> > list API exposed to other Apps anymore, because the route-list data
> > is included in the horizon. So if Apps like to get route-list
> > information, they will find them in the horizon data. 
> I think we’re coming at this from opposite directions: as I said
> above,
> I’m thinking about providing APIs A and B separately, and allowing
> applications to use either or both. You’re thinking about providing
> API
> C (which is a combination of A and B), and applications can use that
> and filter out what they don’t want.
> Andre: my understanding from your explanations above is, that you
> also provide the library to create C (the combination of A and B).
> That’s what I call centralized. So finally, its simple all supported
> by prepared SDK-APIs. That’s fine for me. 

Correct.

> So does this mean that I have misunderstood the need for a
> libchamplain
> map layer which applications can use to display //just// the route
> list
> on top of a map (with no POIs or other horizon data)? Or do you want
> that to be implemented by consuming the horizon API and filtering out
> the POIs to just leave the route list data?
> Andre: no, you did not misunderstood it. The functionality is needed.
> My focus is on the SDK-API, things which gets used by the Apps. Apps
> use libchamplain, so that the SDK-API in this regard. How data lands
> in libchamplain is out of scope of the SDK-API. So we can add the
> route-data (only, w/o POIs) into libchamplain, and nevertheless
> discuss SDK-API for horizon. So we can talk about different lines of
> APIs.
> The libchamplain integration is behind the scene. Its part of the OS,
> behind the SDK-API. Not in the scope which I look to right now.
> Don't be confused, the functionality is required. However, there are
> various ways to implement it, and since it is not impacting the SDK-
> API - it even does not have to use SDK-APIs at all - its completely
> in our hand to make it efficient in the one or the other way. But
> like I said already above, I also like to provide APIs over various
> "levels", so from more native to more aggregating ones, I also
> support to have the native APIs available at SDK-API.

OK, we agree about this then.

Philip

> > -----Ursprüngliche Nachricht-----
> > Von: Philip Withnall [mailto:philip.withnall at collabora.co.uk] 
> > Gesendet: Freitag, 5. Februar 2016 15:34
> > An: Barkowski Andre (CM-CI1/PRM1) <Andre.Barkowski at de.bosch.com>;
> dev
> > el at lists.apertis.org
> > Betreff: Re: AW: AW: AW: AW: AW: AW: AW: [Devel] Updated
> geolocation
> > and navigation design document
> >
> > Hi Andre,
> >
> > On Thu, 2016-02-04 at 09:56 +0000, Barkowski Andre (CM-CI1/PRM1)
> > wrote:
> > > since I still do not know where the blocking factor is let me
> give
> > > some range of feedback, maybe one hits the point
> > > - Apps do not change the system scope, they do not install stuff
> > > (e.g. backends) into the system. They may ship a backend, but all
> > > that belongs and gets installed to its black box environment.
> > > However, they may exposes data to some already available system
> > > service via some SDK-API.
> >
> > We agree on this. The backends for the SDK route list API in my
> > diagram
> > are provided by application bundles.
> >
> > > - App UI (like "Fuel Station application UI" or "Navigation
> > > UI")  belongs the "application bundle"
> >
> > We agree on this. I did not show that in the diagram in order to
> keep
> > it legible.
> >
> > > - So the Navi is completely handled as a App-Bundle covering the
> > > "Backend" (including route planning) as also the "UI" in its own
> > > black box. 
> >
> > We agree on this. Again, I did not show that in the diagram in
> order
> > to
> > keep it legible.
> >
> > > - since the "navigation UI" belongs the nav app-bundle, it is
> > > directly connected to its backend  The Navi UI can use whatever
> > > black-box internal ways to interact with its backend to create
> its
> > > UI. Same like for each other App-Bundle. The Navi is just another
> > > App. However, in addition its proprietary backend may exposes
> some
> > > data to a SDK-API service (route-list "horizon"), and the backend
> > > may
> > > also consumes aggregated data form (this) SDK-API service. 
> >
> > OK, I have noted the potential for an arbitrary connection between
> > the
> > navigation backend and navigation UI.
> >
> > We agree on the rest: in the diagram, the ‘backend provided by
> > navigation application bundle’ exposes data to the SDK route list
> API
> > (which is actually a service/process — it’s a box in the diagram).
> It
> > can also consume data from that API, although that’s not shown in
> the
> > diagram. There is nothing to prevent that.
> >
> > > - its not like discussed for libchamplain or tts or other topics,
> > > where the "backends" reside in the OS scope (functionality
> embedded
> > > in the OS). In these areas the backend of choice gest decided by
> > > the
> > > system integrator at point in time of product definition (it
> cannot
> > > be changed by the User). In contrast to that, for navi we enable
> > > flexibility during runtime. Installing an app changes the
> "backend
> > > used". So the Navi App Bundle ships the backend and its UI, but
> > > does
> > > not change installations in the OS. The App bundle exposes data
> to
> > > the SDK.Route List (Horizon) APIs to other Apps. So we shift the
> > > responsibility by keeping the app-centric approach - from the
> > > integrator to the user and from OS-scope to App-scope.
> >
> > We agree on this.
> >
> > > - With that flexibility, the User has the option to decides for
> the
> > > Navi of his choice.
> >
> > We agree on this.
> >
> > > - if the backend is located in automotive domain, then this is
> > > coupled/bundled with one (maybe build in) "Navi App". 
> >
> > We agree on this.
> >
> > > - The rout-list "horizon" API, is not primary used to create a
> > > User-
> > > Interface for a "Navigation" Application, neither from other Apps
> > > nor
> > > from the App bundle who provides the "backend". The primary
> purpose
> > > for the route-list API "horizon" is _not_ to serve for the
> > > navigation
> > > build-in functionality. Its for location based services/Apps.
> >
> > OK, I had been assuming it could be used for the navigation UI, but
> > if
> > the navigation UI and backend want to use an arbitrary connection
> to
> > communicate routes, that’s fine (as agreed a few points above).
> >
> > We agree on the fact that the SDK route list API (which you call
> > ‘route-list API "horizon"’) is used for location-based services and
> > applications.
> >
> > > - POIs transferred via the pipe mechanism lands in the App
> specific
> > > local "database" (not directly at the UI), the App takes over the
> > > data responsibility/management, its like an import. The App
> decides
> > > about if and how to persistently store it, when to delete etc.
> > > These
> > > data runs like all the other local app data though its app-
> specific
> > > business logic / functionality. Its even possible that these data
> > > gets only consumed by some algorithms and never lands natively at
> > > the
> > > UI. 
> >
> > We agree on this, although I have not discussed the possibility of
> > applications storing points of interest in an internal database.
> What
> > applications do with points of interest once they have received
> them
> > is
> > up to the application developer — they can store the POIs in a
> > database, display them directly in the UI without storage, or
> process
> > them without ever putting them in a UI, as you say. That’s why I
> > haven’t mentioned databases.
> >
> > > - think about a setup w/o any navigation installed. Then there is
> > > no
> > > navi backend installed. Nevertheless, the is a route-list
> "horizon"
> > > API where Apps can consume data from and expose data to
> (accordant
> > > to
> > > their app internal functional scope). 
> >
> > We agree on this: the SDK route list API still exists even if no
> > navigation applications are installed. As I said: it’s a service
> > provided by the SDK (and hence is represented as a box in the
> diagram
> > I
> > sent). It can be running and providing the SDK route list API to
> > applications and services even if no backends are available from
> > navigation application bundles (or other bundles).
> >
> > > - It could even be the case that some Apps who are not being a
> > > "navigation App" provide some most probable path information to
> the
> > > horizon. Its not a route -since no destination is set and even no
> > > navigation installed), but guessing about  the way ahead. It
> could
> > > be
> > > limited in length (e.g. only until next intersection, or a little
> > > ahead of this with even multiple pathes from each intersection,
> > > etc).
> > > And this can also be added in case a route is given, adding more
> > > information about alternative links at intersection could be
> > > benefitail for some other Apps to know. So finally its not only
> > > POI. 
> >
> > We agree on this: such applications could provide a backend for the
> > SDK
> > route list API just like navigation application bundles can.
> >
> > > so some questions:
> > > - which "component" represents the glue (the framework) between
> the
> > > LBS-Apps (like Navi, Restaurants, Sightseeing, etc), to receive
> > > dedicated data from individual producers (LBS Apps), creates and
> > > maintains a combined data set, and deliver the data exposed as
> > > route-
> > > list "horizon" API to consumers (its not the "backend" located in
> > > the
> > > App Bundle if a a Navi App, this backend is itself a producer
> only)
> > > ? 
> >
> > This is a combination of the SDK route list API (and the service
> > which
> > provides it, which is part of the SDK and provided by Apertis), and
> > the
> > POI API with its peer-to-peer connections from any other
> application
> > which provides a points of interest interface.
> >
> > In the design as I see it, there is no ‘combined data set’: the SDK
> > route list API service maintains the route list which has been set
> by
> > one of its backends (with the backend chosen by the user; typically
> a
> > navigation application bundle), but it does not combine different
> > routes. It could provide multiple alternative routes from the
> > different
> > backends, although, I suppose.
> >
> > The ‘combined data set’ of POIs is formed at each application where
> > it
> > receives POIs from other applications — in the diagram, this is
> where
> > all the red arrow heads meet. The application may combine these
> POIs
> > in
> > a database, or do whatever else it likes with them. Typically, it
> > would
> > combine them with the planned navigation route, which it has
> received
> > from the SDK route list API (via the yellow arrows in the diagram).
> >
> > > (Btw, a Navi Backend from a proprietary Supplier may do not has
> at
> > > all any of the capabilities needed to aggregate POI data from
> > > various
> > > sources into a combined set. )
> >
> > In the design there is no need for the navigation backend to
> > aggregate
> > POI data — that is done by the applications which are consuming the
> > POI
> > data (the heads of the red arrows in the diagram).
> >
> > > - in which format/way gets this data forwarded to this component
> ?
> > > It
> > > does not need to be the pipe based POI mechanism only because we
> > > have
> > > it. Geoclue also deals with coordinates and nevertheless uses
> > > another
> > > kind of API to exchange information with its backends. On top its
> > > not
> > > only POIs, ist also links(streets) etc to be provided to the
> > > "horizon" framework. 
> >
> > The design recommends (in §7.6 of version 0.3.1 of the design) a D-
> > Bus
> > interface for the SDK route list API which exposes each possible
> > route
> > as an array of (latitude, longitude) coordinates.
> >
> > Are the areas in the diagram where I’ve highlighted components
> which
> > have responsibility for making decisions correct, in your
> > understanding? These are the blue circles in the diagram.
> >
> > Philip
> >
> > > -----Ursprüngliche Nachricht-----
> > > Von: Philip Withnall [mailto:philip.withnall at collabora.co.uk] 
> > > Gesendet: Mittwoch, 3. Februar 2016 16:18
> > > An: Barkowski Andre (CM-CI1/PRM1) <Andre.Barkowski at de.bosch.com>;
> > > dev
> > > el at lists.apertis.org
> > > Betreff: Re: AW: AW: AW: AW: AW: AW: [Devel] Updated geolocation
> > > and
> > > navigation design document
> > >
> > > Hi Andre,
> > >
> > > As far as I can tell, the design I suggested in my previous e-
> mail
> > > does
> > > match your requirements for which components have responsibility
> > > for
> > > different decisions or pieces of information:
> > >  • Applications choose which POIs to advertise, and the
> navigation
> > > UI
> > > displays them unconditionally (subject to rate limiting)
> > >  • The route list API is provided by the SDK, in the system, and
> > > supports multiple backends — the backend might be provided by the
> > > navigation application bundle, but might instead be in the
> > > automotive
> > > domain, or something else
> > >  • The navigation UI is just another application, and has no
> > > special
> > > powers or functionality
> > >  • Applications choose which waypoints to send to the route list
> > > API
> > > to
> > > be added into the route — this might result in the user being
> > > prompted
> > > ‘do you want to add this waypoint into your route’, or they might
> > > be
> > > added unconditionally
> > >
> > > I have attached a diagram of the system as I described it in my
> > > previous e-mail, and have attempted to highlight all the data
> flows
> > > and
> > > the decisions which drive them. (Apologies for the crudeness of
> the
> > > drawing; I did it rapidly.)
> > >
> > > Please could you take a look and see where our understandings
> > > differ,
> > > and highlight specifically what the differences are.
> > >
> > > Thanks,
> > > Philip
> > >
> > > On Wed, 2016-02-03 at 14:16 +0000, Barkowski Andre (CM-CI1/PRM1)
> > > wrote:
> > > > Hi Philip,
> > > > Thanks for your answer, but we are still not on the same page.
> We
> > > > talking about different things.
> > > > There are other parts beside feature requirements which
> influence
> > > > the
> > > > decomposition. Its seems for me that you are focusing on
> features
> > > > and
> > > > if the design/decomposition proposed is able to realize it. My
> > > > focus
> > > > is alignment with app-centric design, so responsibilities &
> > > > dependencies (I only use features to make things more clear).
> So
> > > > if
> > > > you are saying the design can provide the feature, then that’s
> > > > not
> > > > what I am talking about. I am talking about the design does not
> > > > fit
> > > > to the non-function requirements (app-centric solution). Parts
> of
> > > > the
> > > > functionality belongs to the wrong responsibility or we even do
> > > > need
> > > > to split an entity into parts to deploy the responsibility to
> > > > different parties.
> > > > Since we are iterating in cycles a little bit and I start to
> gets
> > > > doubts about the efficiency of this kind of mail threads, let
> us
> > > > limit the iterations. If within a few next ones we do not
> > > > conclude,
> > > > then lets have a call about it. But for now let me try to
> explain
> > > > my
> > > > intention again via email:
> > > > So yes, one can technically pass everything through the
> > > > navigation
> > > > App, delivering all POIs to the App as also requesting a
> > > > consolidated
> > > > data from it. That’s possible. 
> > > > And the design is done in that way. And that’s not the way how
> it
> > > > shall be. So its not the question if the current design can
> also
> > > > realize the mentioned features.
> > > > The POI mechanism defined already was motivation by the update
> of
> > > > the
> > > > navi-database with data needed for route calculation. Only for
> > > > that
> > > > purpose. So for now, please forget the POI mechanism defined
> > > > already.
> > > > Now we are talking about the “route list”. Maybe the naming is
> > > > not
> > > > beneficial, internally we typically use the term “horizon”. Its
> > > > dedicated scope is to carry information related to the
> (expected)
> > > > vehicle position, starting from the current location up to
> > > > expected
> > > > future positons. This is where the term route-list comes into
> the
> > > > game. The goal now is to provide a framework, where all apps
> can
> > > > consume data from for their internal processing as also provide
> > > > data
> > > > to this framework (to enrich it).
> > > > This all is also valid w/o any route available. In that case
> the
> > > > data
> > > > focus more around the current vehicle position. It is even
> valid,
> > > > if
> > > > there is no navigation app installed at all. There is
> > > > nevertheless
> > > > the current geo position available (e.g. from geoclue, and
> maybe
> > > > even
> > > > only on WLAN based positioning so without any GPS solution,
> that
> > > > doesn’t matter). The navigation App is just another App,
> > > > optionally
> > > > producing data to that framework and/or consuming data from it
> > > > (e.g.
> > > > the information about the current route, including its
> > > > intermediate
> > > > destinations etc). And it could even be that multiple Apps,
> > > > dealing
> > > > with most probable pathes exposes information to this horizon
> > > > (not
> > > > only the Navi App currently maintaining the active route). The
> > > > framework is completely independent of the developer of a
> > > > particular
> > > > Navigation App, this solutions is completely out of the
> > > > scope/responsibility of the navigation provider. It belongs to
> > > > the
> > > > system, the OS.
> > > > And yes, intermediate destinations are provided and handled by
> a 
> > > > navigation app, again via another mechanism (the scheme
> > > > mechanisms,
> > > > not the POI one). And if a new intermediate destination has
> been
> > > > defined via this way, and the route has been updated, then the
> > > > navi
> > > > app can expose it to the said horizon framework. And another
> App
> > > > can
> > > > consume this new information about an intermediate destination
> > > > for
> > > > their scope and may also add new data to this framework
> > > > accordingly.
> > > > So what I am asking for is, to keep the POI mechanism as a way
> of
> > > > choice for database updates, and to add an additional framework
> –
> > > > which we can call “horizon” or something else - where Apps can
> > > > produce data to as also consume data from it. The Navi App
> shall
> > > > be
> > > > able to provide its route list information to it and update it.
> > > > Rgds
> > > > Andre
> > > > -----Ursprüngliche Nachricht-----
> > > > Von: Philip Withnall [mailto:philip.withnall at collabora.co.uk]
> > > > Gesendet: Dienstag, 2. Februar 2016 18:27
> > > > An: Barkowski Andre (CM-CI1/PRM1) <Andre.Barkowski at de.bosch.com
> >;
> > > > dev
> > > > el at lists.apertis.org
> > > > Betreff: Re: AW: AW: AW: AW: AW: [Devel] Updated geolocation
> and
> > > > navigation design document
> > > > Hi Andre,
> > > > Replies inline. I’ve trimmed a few of the parts of the e-mail
> > > > which
> > > > we
> > > > agree on.
> > > > On Tue, 2016-01-26 at 13:03 +0000, Barkowski Andre (CM-
> CI1/PRM1)
> > > > wrote:
> > > > > However, my understanding of
> > > > > https://wiki.apertis.org/Points_of_interest design is, that
> > > > > only
> > > > the
> > > > > control flow runs via a central SDK service, but if allowed
> it
> > > > > establishes a private point-to-point channel (pipe) between
> > > > producer
> > > > > App and consumer App (w/o any SDK service inbetween anymore).
> > > > > With
> > > > > that, the content itself (the POIs) are untouched form the so
> > > > called
> > > > > "central POI service", the POIs are neither stored/cached,
> nor
> > > > > distributed by them. With that, the "SDK-Service" (central
> POI
> > > > > service) does _not_ return points of interest like
> restaurants,
> > > > > filling stations and tourist attractions. As also there is no
> > > > > capability to define filters in that request, since in an
> app-
> > > > centric
> > > > > approach the policies are belonging to the Source/Producer
> App.
> > > > > The
> > > > > SDK service itself only establishes private point to point
> > > > > connections.
> > > > That is correct. I guess when I’ve been saying ‘POI service’ or
> > > > ‘POI
> > > > system’ from the point of view of an application which is
> > > > consuming
> > > > POI
> > > > data (such as the navigation UI, or another application which
> > > > needs
> > > > to
> > > > display POIs), I would consider the ‘POI service/system’ to be
> > > > the
> > > > set
> > > > of all applications which are providing POIs over peer-to-peer
> > > > connections.
> > > > > • Route list: a list of objects which describe the route for
> a
> > > > > navigation, i.e. the roads to take; this might include
> > > > > alternative
> > > > > routes; it _does_ include Point objects like intermediate
> > > > > destinations on the route
> > > > > so there are point type objects already included in that
> > > > > structure
> > > > as
> > > > > also attributes/metadata for each object for further details.
> > > > Yes, although the metadata is limited to a description for the
> > > > location
> > > > and what type of point it is (start, waypoint, waypoint which
> is
> > > > for
> > > > routing only and isn’t a destination, final destination).
> > > > > Please note, that the navigation "route-list" is something
> > > > different
> > > > > than the navigation "guidance". The guidance focus on
> detailed
> > > > > description of turns ahead, the route-list has a different
> > > > > focus
> > > > > -
> > > > it
> > > > > describes the complete trip. So that’s 2 APIs and different
> > > > > structures/objects. I would recommend to adopt the document
> > > > > accordingly.
> > > > Noted — I will include this in the next update to the document.
> > > > > And what I am talking about now is, that apps shall be able
> to
> > > > > augment the route list returned by the SDK-API . The route
> list
> > > > > exposed via the route-list SDK-API for sure gets provided
> (and
> > > > > updated) by the navigation app (somehow similar like it can
> do
> > > > > it
> > > > for
> > > > > the geo-position to geo-clue), but Apps can augment data to
> it.
> > > > > The APIs realizing this capability have second priority for
> me,
> > > > > but
> > > > > nevertheless I like to cover it right from the
> beginning  from
> > > > > conceptual point of view.
> > > > > With "create some functionality" I do mean the samples
> provided
> > > > > to
> > > > > explain use-cases where Apps consume and augment POIs to the
> > > > > route
> > > > > list:
> > > > > -  a Weather App may consumes Intermediate Destination
> > > > > Information
> > > > > from Route List to show entries on top of the user stored
> > > > > locations
> > > > > in its UI to inform the User about weather at this places
> > > > > - a gasoline station app adds a refueling stop into the route
> > > > > list
> > > > > for a location to be reached at a time where the car runs low
> > > > > on
> > > > fuel
> > > > > - a restaurant app may uses information of gasoline stations
> in
> > > > > the
> > > > > route list to add recommended cafeterias into the route list
> to
> > > > align
> > > > > the breaks for the driver
> > > > > - a restaurant app may decides to add restaurant POIs as
> > > > > recommendations into the route list for a location to be
> > > > > reached
> > > > > at
> > > > a
> > > > > time where a break would be wise
> > > > > - a installed “coupon” app may add available discounts
> > > > > available
> > > > > at
> > > > a
> > > > > POI location available in route list.
> > > > > The major thing is, in an app centric approach, the policies
> > > > > are
> > > > > coupled with the source of the data. Its _not_ the navigation
> > > > > app
> > > > > which orchestrates the other apps - like in a systemic
> client-
> > > > server
> > > > > model, what to deliver. This limits the capabilities to
> fantasy
> > > > > provided by the navigation app developer as also his
> > > > > capabilities
> > > > and
> > > > > development work. In an app-centric approach its completely
> > > > > vice
> > > > > versa, each app focus on its essential service, a navigation
> > > > > calculates the route. That’s it. And a restaurant app deals
> the
> > > > POI,
> > > > > and handles all policies and User Interaction to
> choose/handle
> > > > them,
> > > > > even though they may finally gets used to set a new
> destination
> > > > > or
> > > > > they land in the route list.
> > > > OK. I think this fits with my proposed design and the Points of
> > > > Interest design as they currently stand, although I should
> > > > clarify
> > > > things.
> > > > The route list API continues to provide only the list of roads
> to
> > > > take
> > > > (i.e. the geometry of the route) as I described in my previous
> e-
> > > > mail.
> > > > Applications which provide POIs query this API to find out the
> > > > current
> > > > route, as described in the fourth paragraph of
> > > > https://wiki.apertis.org/Points_of_interest#Recommendations.
> > > > The navigation UI uses interface discovery to find applications
> > > > which
> > > > provide POI data. It then queries them (via peer-to-peer
> > > > connections)
> > > > for general and specific POIs, as described in the POI design.
> > > > Its shall not be the responsibility of the Navigation to
> requests
> > > > it/or not.
> > > > Its done by the Providing Apps autonomously.
> > > > It shall not depend on the code (responsibility) of the
> > > > navigation
> > > > App at all if this
> > > > The logic for working out what POIs to send to the navigation
> UI
> > > > lies
> > > > within each application. The navigation UI does no filtering
> > > > based
> > > > on
> > > > content (though for security reasons it might want to apply
> some
> > > > rate
> > > > limiting to prevent DoS attacks). It simply displays all the
> POIs
> > > > it
> > > > receives.
> > > > It might be possible for an application to add metadata to a
> POI
> > > > it
> > > > sends to the navigation UI to say ‘please add this POI as a
> > > > waypoint’,
> > > > in which case the navigation UI could prompt the user about it
> > > > (or
> > > > add
> > > > the destination anyway, or ignore it — this policy is up to the
> > > > navigation UI developer). If the POI is added as a waypoint in
> > > > the
> > > > route, the SDK route list API would signal an update to the
> > > > route,
> > > > which would be received by the navigation UI and all
> applications
> > > > providing POIs to it. This would allow for the coupon use case
> —
> > > > if
> > > > a
> > > > restaurant gets added as a waypoint, the coupon application
> could
> > > > start
> > > > emitting a POI for using coupons there.
> > > > If another application wants to display the same map view as
> the
> > > > navigation UI, showing the route and POIs on it, it has to make
> > > > the
> > > > same API calls as the navigation UI: a call to the SDK route
> list
> > > > API
> > > > to get the route; and interface discovery followed by peer-to-
> > > > peer
> > > > retrieval of POIs from other applications.
> > > > So, in short, the ‘augmented route list’ is provided by a
> > > > combination
> > > > of the route list API and the POI system (i.e. retrieving POIs
> > > > from
> > > > other applications using peer-to-peer connections).
> > > > I hope that makes sense?
> > > > Philip
> > > > > -----Ursprüngliche Nachricht-----
> > > > > Von: Philip Withnall [mailto:philip.withnall at collabora.co.uk]
> > > > > Gesendet: Montag, 25. Januar 2016 15:56
> > > > > An: Barkowski Andre (CM-CI1/PRM1) <Andre.Barkowski at de.bosch.c
> om
> > > > > >;
> > > > dev
> > > > > el at lists.apertis.org
> > > > > Betreff: Re: AW: AW: AW: AW: [Devel] Updated geolocation and
> > > > > navigation design document
> > > > > Hi Andre,
> > > > > On Fri, 2016-01-22 at 17:16 +0000, Barkowski Andre (CM-
> > > > > CI1/PRM1)
> > > > > wrote:
> > > > > > Hi Philip,
> > > > > > I feel we are still not fully on the same page. We closed
> > > > > > some
> > > > gaps
> > > > > > lately (in regard to the assist-window), but it seems to me
> > > > > > that
> > > > we
> > > > > > still have a gap in regard to POI handling itself.
> > > > > > So summarize, let me go one step back and start with
> > > > > > -       POI service is _not_ equal to route-list.
> > > > > > I am talking about a route list, you are talking about a
> > > > > > central
> > > > > poi
> > > > > > service.
> > > > > To check, what do you mean by the terms ‘POI service’ and
> > > > > ‘route
> > > > > list’?
> > > > > I interpret them as:
> > > > >  • POI service: an SDK service which returns points of
> interest
> > > > like
> > > > > restaurants, filling stations and tourist attractions
> > > > >  • Route list: a list of points which describe the plotted
> > > > > route
> > > > for
> > > > > a
> > > > > navigation, i.e. the roads to take; this might include
> > > > > alternative
> > > > > routes; it does not include nearby POIs
> > > > > Andre: hope this is answered above
> > > > > > Let me add:
> > > > > > -       we do _not_ need a central POI service, or vice
> versa
> > > > > > I
> > > > am
> > > > > > not aware about a related requirement.
> > > > > All suggestions I have made about POI handling in the context
> > > > > of
> > > > the
> > > > > Geolocation and Navigation document have been references to
> the
> > > > > existing https://wiki.apertis.org/Points_of_interest design.
> I
> > > > > am
> > > > not
> > > > > suggesting changes to that design, nor am I suggesting
> copying
> > > > parts
> > > > > of
> > > > > it into this design (or any of the navigation APIs).
> > > > > Andre: I see.
> > > > > > We do have the already mentioned 3 Use cases and the
> > > > > > mechanisms
> > > > > > discussed covers the use-cases already perfectly
> > > > > > 1) for in app UI browsing: libchamlain. We have it, fine.
> > > > > Yes.
> > > > > > 2) for app import / handover: Pull mode for various types
> of
> > > > > content
> > > > > > – also TPEG based POI data -
> > > > > > https://wiki.apertis.org/Points_of_interest
> > > > > > (For completion there is also a push mode for various types
> > > > > > of
> > > > > > content – so far no need for TPEG support -  https://wiki.a
> pe
> > > > > > rt
> > > > > > is
> > > > .o
> > > > > rg
> > > > > > /Data_sharing )
> > > > > > again, we have it designed already.
> > > > > Yes.
> > > > > > 3) now we add the route-list to the SDK-API, where I also
> ask
> > > > > > to
> > > > > > provide capabilities to add POIs to it (independent from
> the
> > > > navi-
> > > > > > app)
> > > > > I think this is covered by the SDK navigation route guidance
> > > > > API
> > > > > (§7.6
> > > > > of version 0.3.1 of the document), if we are using the same
> > > > > meaning
> > > > > for
> > > > > ‘route list’ (see above).
> > > > > Andre: see above, I think we do need 2 API scopes, one for
> > > > > “route-
> > > > > list” one for “guidance”
> > > > > > In any case we do need the route list, it has originally
> > > > > > nothing
> > > > to
> > > > > > do with the POI discussion. Apps shall be able to consume
> > > > > information
> > > > > > about the current route and to create some functionality.
> > > > > > That
> > > > the
> > > > > > purpose of the route list essentially.
> > > > > What do you mean by ‘create some functionality’?
> > > > > In the design as it stands currently, applications cannot
> > > > > augment
> > > > the
> > > > > route list returned by the SDK navigation route guidance API.
> > > > > They
> > > > > can
> > > > > augment the list of POIs returned by the POI API (https://wik
> i.
> > > > > ap
> > > > > er
> > > > ti
> > > > > s.
> > > > > org/Points_of_interest).
> > > > > Andre: see above, I do mean things like that
> > > > > -  a Weather App may consumes Intermediate Destination
> > > > > Information
> > > > > from Route List to show entries on top of the user stored
> > > > > locations
> > > > > in its UI to inform the User about weather at this places
> > > > > - a gasoline station app adds a refueling stop into the route
> > > > > list
> > > > > for a location to be reached at a time where the car runs low
> > > > > on
> > > > fuel
> > > > > - a restaurant app may uses information of gasoline stations
> in
> > > > > the
> > > > > route list to add recommended cafeterias into the route list
> to
> > > > align
> > > > > the breaks for the driver
> > > > > - a restaurant app may decides to add restaurant POIs as
> > > > > recommendations into the route list for a location to be
> > > > > reached
> > > > > at
> > > > a
> > > > > time where a break would be wise
> > > > > - a installed “coupon” app may add available discounts
> > > > > available
> > > > > at
> > > > a
> > > > > POI location available in route list.
> > > > >  
> > > > > > Based on that scope, I am asking for the additional
> > > > > > functionality
> > > > > to
> > > > > > add Metadata/Content from Apps directly to it, especially
> > > > > > POIs.
> > > > Its
> > > > > > neither a first priority nor will it dramatically change
> the
> > > > > design.
> > > > > > Its simple an add-on. We can even decide to implement it
> > > > > > later.
> > > > > For clarity, which API do you mean by ‘it’?
> > > > > Andre: I do mean the capability for Apps to augment POIs into
> > > > > the
> > > > > Route-List
> > > > > > Similar stuff is valid for the guidance & assist window
> > > > discussion.
> > > > > > The APIs for the “guidance”  (which is “just another
> > > > > > notification
> > > > > > style API for a dedicated purpose”) as also the assist
> window
> > > > > (which
> > > > > > is just another system chrome application where for example
> > > > > > the
> > > > > data
> > > > > > exposed via the guidance notification style SDK-API lands
> in)
> > > > > > are
> > > > > > optional and don’t have side effects to other SDK-APIs. So
> we
> > > > > > can
> > > > > > implementation wise realize it in a later step, its not of
> > > > > > first
> > > > > > priority. However, I like to have a common understanding
> > > > > > about
> > > > the
> > > > > > overall scope early.
> > > > > > If we provide capabilities to add metadata into an
> available
> > > > route-
> > > > > > list to Apps, other Apps (than the navi app) can add
> > > > > > additional
> > > > > > content/ additional metadata to available content, for
> > > > > > example
> > > > POIs
> > > > > > into a currently shared route list. Since we have already
> > > > > > libchamplain and also the Point_of_interest and sharing
> > > > mechanisms
> > > > > > design, My focus is on just one more method for that route-
> > > > > > list.
> > > > I
> > > > > am
> > > > > > _not_ talking about any big thing, especially not about a
> > > > > > central
> > > > > POI
> > > > > > service.
> > > > > > I would like to propose we serialize the discussion. How
> > > > > > about
> > > > > first
> > > > > > finalizing the solution for the route list, including POIs
> > > > > > into
> > > > it
> > > > > > from Apps via an SDK API.
> > > > > > Then reflect, for what a central POI service could be
> > > > > > beneficial
> > > > ?
> > > > > > I have embedded some comments below in green.
> > > > > I’ve put a few replies below too.
> > > > > > -----Ursprüngliche Nachricht-----
> > > > > > Von: Philip Withnall [mailto:philip.withnall at collabora.co.u
> k]
> > > > > > Gesendet: Mittwoch, 20. Januar 2016 16:57
> > > > > > An: Barkowski Andre (CM-CI1/PRM1) <Andre.Barkowski at de.bosch
> .c
> > > > > > om
> > > > > > > ;
> > > > > dev
> > > > > > el at lists.apertis.org
> > > > > > Betreff: Re: AW: AW: AW: [Devel] Updated geolocation and
> > > > navigation
> > > > > > design document
> > > > > >
> > > > > > > Please keep also in mind, that the navigation app itself
> is
> > > > > somehow
> > > > > > > special in regard to their output. Beside provides some
> UI
> > > > > > > to
> > > > > > control
> > > > > > > its functions like all the other apps (e.g. media
> player),
> > > > > > > the
> > > > > > “route
> > > > > > > guidance” information is very special. In addition to a
> > > > > > > black
> > > > box
> > > > > > > build-in solution for the route guidance - like all the
> > > > > smartphone
> > > > > > > Smartphone solutions realizing today – (on prompt the
> > > > > > > guidance
> > > > is
> > > > > > > only acoustic or an app-change transition to the
> navigation
> > > > > > > app
> > > > > > > appears) we will go a step forward for this driver
> related
> > > > > > > information. The guidance will be presented to the user
> > > > > independent
> > > > > > > of the current App in use in foreground. So you can
> “leave”
> > > > > > > the
> > > > > > navi-
> > > > > > > app but the guidance shall continue. In fact we influence
> > > > > > > the
> > > > > > > internal design by requesting an agent to be provided by
> > > > > > > the
> > > > app-
> > > > > > > developer to deliver these data. And that’s not only an
> > > > > acoustical
> > > > > > > prompt, its also data which gets finally a visual
> > > > representation
> > > > > > > (turn icons, lane information, etc). In this approach via
> > > > > > > an
> > > > SDK-
> > > > > > API
> > > > > > > the rendering gets done by some system service. Its more
> > > > > > > like
> > > > > > > a
> > > > > > > “notification”/“dialog-box”/“status framework” stuff
> > > > > > > (please
> > > > have
> > > > > a
> > > > > > > look to the running status framework and the relation to
> > > > > > > assist
> > > > > > > framework too). So the navigation App provides its data
> as
> > > > output
> > > > > > to
> > > > > > > some SDK-API. In fact part of this is the route list,
> which
> > > > > finally
> > > > > > > land in that guidance dialog. Lets call it assistance
> > > > > > > window
> > > > > > > –
> > > > > > driver
> > > > > > > related information.
> > > > > > I see. The way I would recommend doing this in the design
> is
> > > > > > to
> > > > > > implement the guidance UI separately from the navigation
> UI.
> > > > > > It
> > > > > could
> > > > > > potentially be part of the same application bundle, or part
> > > > > > of
> > > > > > a
> > > > > > different one, or even implemented as part of the system
> > > > > > chrome.
> > > > > > Andre: to be honest, this all is optional. A navi app
> > > > > > developer
> > > > can
> > > > > > decide to implement the guidance in its local app-bundle
> > > > > > scope.
> > > > > Then
> > > > > > the UI appears within its own App Screen Area.
> > > > > > However, since it is beneficial (independent from the POI
> or
> > > > Assist
> > > > > > Window Discussion) that the guidance portion is separated
> > > > > > from
> > > > the
> > > > > > rest of the full-fledge App (because it enables us to
> handle
> > > > > > a
> > > > > > separated executable with its own lifecycle, which means we
> > > > > > can
> > > > > keep
> > > > > > only that part running in background instead of the Full
> App)
> > > > > > we
> > > > > > should ask for an Agent for it. The App developer can
> decide
> > > > > > to
> > > > do
> > > > > so
> > > > > > or not. So the requirement for isolating the Guidance into
> an
> > > > Agent
> > > > > > is already valid w/o all the discussion about POIs and/or
> > > > > > Assist
> > > > > > Window.
> > > > > > On top of that we like to also support an assist window
> > > > > > solution
> > > > as
> > > > > > part of our system. Therefore we will provide a
> notification
> > > > style
> > > > > > similar API for driver related information. Guidance data
> > > > > > will
> > > > > > be
> > > > > > covered by it, and if a Navi App developer decided to use
> > > > > > this
> > > > SDK-
> > > > > > API, the guidance information will land there (but also
> > > > information
> > > > > > from route list will land in such an assist window).
> Similar
> > > > > > like
> > > > > > mentioned above, we like to ask the developer to provide an
> > > > > > agent
> > > > > for
> > > > > > the guidance data. However, the assist window (the UI for
> the
> > > > > > guidance) is finally a system chrome element and not
> deployed
> > > > with
> > > > > > the App bundle. It belongs to the OS and gets distributed
> > > > > > with
> > > > it.
> > > > > OK, we would have to add a separate SDK API for handling
> > > > > guidance
> > > > > notifications, similar to the existing
> > > > org.freedesktop.Notifications
> > > > > API for handling other notifications from applications. I
> will
> > > > > include
> > > > > a recommendation for that in the next update to the document.
> > > > > Andre: agreed
> > > > > > The guidance UI would take data from the SDK points of
> > > > > > interest
> > > > > API,
> > > > > > and from the SDK navigation route guidance API (§7.6). This
> > > > > > would
> > > > > > allow
> > > > > > it to render the route (from the guidance API), and points
> of
> > > > > > interest
> > > > > > along the way (from the PoI API).
> > > > > > The navigation UI (where the driver chooses their
> destination
> > > > > > and
> > > > > > plans
> > > > > > the route) may retrieve points of interest from the SDK, or
> > > > > > may
> > > > > > choose
> > > > > > not to if the developer thinks they will be distracting.
> > > > > > i.e. The SDK API you are suggesting for the data from the
> > > > guidance
> > > > > UI
> > > > > > is effectively the points of interest API plus the
> navigation
> > > > route
> > > > > > guidance API.
> > > > > > Andre: like said, its not the “points_of_interest” API, its
> > > > > > from
> > > > > the
> > > > > > route-list API.
> > > > > > > To this route list, other apps can directly add further
> > > > > > > data.
> > > > > This
> > > > > > is
> > > > > > > _not_ forwarded to the navi-app, it does not modify the
> > > > > > > route
> > > > > list
> > > > > > > nor does it gets stored by the navi-app. The navi app
> don’t
> > > > > > > has
> > > > > any
> > > > > > > interest in getting and managing it. This data, gets
> > > > > > > provided
> > > > by
> > > > > > the
> > > > > > > source app to the rout–list and with that finally
> rendered
> > > > > > > to
> > > > the
> > > > > > > user by some system service (assist window). On the other
> > > > > > > hand,
> > > > > > other
> > > > > > > apps can consume this enriched route list again for their
> > > > build-
> > > > > in
> > > > > > > functions and policies. Its all outside the navigation,
> the
> > > > navi
> > > > > > only
> > > > > > > provides the initial foundation.
> > > > > > That’s possible due to the split between the navigation UI
> > > > > > and
> > > > the
> > > > > > guidance UI. The navigation UI can choose to not query for
> > > > > > points
> > > > > of
> > > > > > interest, or can heavily filter the PoI requests it makes.
> > > > > > Conversely,
> > > > > > the guidance UI can query for lots of PoIs.
> > > > > > If other applications want to display something similar to
> > > > > > the
> > > > > > guidance
> > > > > > UI, they must make the same navigation route guidance API
> and
> > > > > > PoI
> > > > > API
> > > > > > queries as made by the guidance UI. This should be simple
> to
> > > > > > do,
> > > > > and
> > > > > > allows each application to further customise the points of
> > > > interest
> > > > > > they display.
> > > > > > Andre:
> > > > > > to be honest, the use-cases behind that stuff is _not_ that
> > > > another
> > > > > > app will do something similar like the guidance UI.
> > > > > Sorry, when I said “if other applications want to display
> > > > > something
> > > > > similar to the guidance UI” I meant something more like “if
> > > > > other
> > > > > applications want to display the current route, or the
> current
> > > > route
> > > > > plus nearby POIs”.
> > > > > Andre:  I would expect this is build-in behind the scene into
> > > > > libchamplain. So by using libchamplain, Apps get this
> > > > > information
> > > > > already embedded. Similar like they get the current vehicle
> > > > position
> > > > > (from geoclue) already well embedded into libchamplain. The
> > > > usecases
> > > > > for Apps to use route list information is the stuff mentioned
> > > > above.
> > > > > Let me repeat to prevent misunderstanding:
> > > > > -  a Weather App may consumes Intermediate Destination
> > > > > Information
> > > > > from Route List to show entries on top of the user stored
> > > > > locations
> > > > > in its UI to inform the User about weather at this places
> > > > > - a gasoline station app adds a refueling stop into the route
> > > > > list
> > > > > for a location to be reached at a time where the car runs low
> > > > > on
> > > > fuel
> > > > > - a restaurant app may uses information of gasoline stations
> in
> > > > > the
> > > > > route list to add recommended cafeterias into the route list
> to
> > > > align
> > > > > the breaks for the driver
> > > > > - a restaurant app may decides to add restaurant POIs as
> > > > > recommendations into the route list for a location to be
> > > > > reached
> > > > > at
> > > > a
> > > > > time where a break would be wise
> > > > > - a installed “coupon” app may add available discounts
> > > > > available
> > > > > at
> > > > a
> > > > > POI location available in route list.
> > > > > > Other Apps uses information form that API for their
> essential
> > > > > > service, e.g. if an App of a weather service does know
> > > > intermediate
> > > > > > destinations from the route list, it may decides to show
> > > > > > entries
> > > > on
> > > > > > top of the stored locations for current destination and
> > > > > intermediate
> > > > > > destinations (in todays list you have the current positon
> for
> > > > > example
> > > > > > as a default, this app could extend that approach depending
> > > > > > on
> > > > > stuff
> > > > > > from the route list).
> > > > > > Or if a gasoline station app adds a refueling stop into the
> > > > > > route
> > > > > > list for a location to be reached at a time where the car
> > > > > > runs
> > > > low
> > > > > on
> > > > > > fuel, a restaurant app may uses this information to add
> > > > recommended
> > > > > > cafeterias into the route list to align the breaks for the
> > > > driver.
> > > > > > Or if a restaurant app decides to add restaurant POIs as
> > > > > > recommendations into the route list for a location to be
> > > > > > reached
> > > > at
> > > > > a
> > > > > > time where a break would be wise, a installed “coupon” app
> > > > > > may
> > > > add
> > > > > > available discounts available at this location.
> > > > > > etc.
> > > > > I don’t think I can fully understand these points without
> > > > > agreeing
> > > > on
> > > > > the terminology at the top of the e-mail.
> > > > > Andre:  ok, hope my comments given where helpful in that
> > > > > regard.
> > > > > In the current version of the design, these use cases are
> > > > > handled
> > > > by:
> > > > >  • The gasoline station application exposes gasoline stations
> > > > > as
> > > > > points
> > > > > of interest via the POI API (https://wiki.apertis.org/Points_
> of
> > > > > _i
> > > > > nt
> > > > er
> > > > > es
> > > > > t).
> > > > >  • The restaurant application exposes restaurants as points
> of
> > > > > interest
> > > > > via the POI API (https://wiki.apertis.org/Points_of_interest)
> .
> > > > >  • The navigation application contains the logic to:
> > > > >   - Detect where in the route the vehicle is likely to need
> > > > > refuelling,
> > > > > query the POI API (https://wiki.apertis.org/Points_of_interes
> t)
> > > > > for
> > > > > gasoline stations, and add them to the route.
> > > > >   - Detect when in the route the driver is likely to need
> food,
> > > > query
> > > > > the POI API (https://wiki.apertis.org/Points_of_interest) for
> > > > > restaurants, and add them to the route.
> > > > > I can’t think of a sensible way of handling coupons at the
> > > > > moment.
> > > > > They
> > > > > don’t really fit into any of the existing APIs.
> > > > > The design is this way round, rather than allowing the
> > > > > restaurant
> > > > and
> > > > > gasoline applications to ‘insert’ recommendations into the
> > > > > route
> > > > list
> > > > > because it leaves the navigation application in charge of
> which
> > > > > restaurants (for example) are shown. It means the code for
> > > > > determining
> > > > > when is ‘a good time to stop for food’ is in one place (the
> > > > > navigation
> > > > > application) rather than many (each restaurant application),
> > > > > each
> > > > of
> > > > > which could end up using different definitions of when is ‘a
> > > > > good
> > > > > time
> > > > > to stop for food’ in order to gain competitive advantage.
> > > > > Andre: like said above, the design philosophy is an app-
> centric
> > > > > solution is, to bundle the policy / logic within the provider
> > > > > app.
> > > > So
> > > > > its not one central intelligence, orchestrating all others,
> its
> > > > vice
> > > > > versa all the others are providing things accordant to their
> > > > > implemented logic. Apps can compete in providing the same
> > > > > service
> > > > > with another policy or using another service with a similar
> > > > > policy.
> > > > > The user decides by choosing the App which fits best his
> needs.
> > > > > And
> > > > > he can do in the smallest granularity, per App . So he is
> able
> > > > > to
> > > > > adopt the overall solution by making dedicated decisions per
> > > > > source
> > > > > (App).
> > > > > (Above, I am using ‘navigation application’ to mean the
> entire
> > > > > navigation application bundle, including any UIs, agents, or
> > > > services
> > > > > which it provides.)
> > > > > Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 213 bytes
Desc: This is a digitally signed message part
URL: <http://lists.apertis.org/pipermail/devel/attachments/20160215/aa4caf29/attachment-0001.sig>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5445 bytes
Desc: not available
URL: <http://lists.apertis.org/pipermail/devel/attachments/20160215/aa4caf29/attachment-0001.bin>