[Devel] Updated geolocation and navigation design document

Wed Feb 3 15:18:03 GMT 2016

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.com>;
> 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.apertis
> .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://wiki.aper
> 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.uk]
> > > Gesendet: Mittwoch, 20. Januar 2016 16:57
> > > An: Barkowski Andre (CM-CI1/PRM1) <Andre.Barkowski at de.bosch.com>;
> > 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_int
> 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_interest) 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: geolocation-and-navigation-sketch_2016-02-03.pdf
Type: application/pdf
Size: 186067 bytes
Desc: not available
URL: <http://lists.apertis.org/pipermail/devel/attachments/20160203/431996b4/attachment-0001.pdf>
-------------- 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/20160203/431996b4/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/20160203/431996b4/attachment-0001.bin>