
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">

<HTML>

<HEAD>

<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=utf-8">

<META NAME="Generator" CONTENT="MS Exchange Server version rmj.rmm.rup.rpr">

<TITLE>AW: AW: AW: AW: AW: AW: AW: AW: AW: [Devel] Updated geolocation and navigation design document</TITLE>

</HEAD>

<BODY>

<!-- Converted from text/rtf format -->


<P DIR=LTR><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">Hi Philip,</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">ok, again a step closer to each other.</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">The discussion</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">how is something realized (as library or with a dbus api), is of second  level detail for me.</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">I still try to clarify the first</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">level interest</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">s, which is functional deployment & related</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">responsibility of code</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">, and if you say</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">something like</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">"Apps are merging POIs with the route list", then I</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">understand </FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">that this is part of their code-responsibility.</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial"> But know you clarified, that you intended to provide a library for them, so you are more looking from process point of view. That</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">is a</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">different</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">level compared</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">to my point of view, so we</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">talk past each other a little. All that aspects,</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">process boundaries,</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">implementation decision</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">s</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial"> (library vs messaging) etc, are out of my focus</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">at this point in time. Please try to keep that in mind in our future discussion.</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> </SPAN></P>


<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">So</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">independent if</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">based on a library or dbus</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial"> (lets discuss that later)</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">,</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">there is a prepared</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">central</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">solution</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">exposed via</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">an</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">SDK-API</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">which applications can use to</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial"></FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">access aggregate</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">d data (POI merged into</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">route list</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">)</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">.</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">In your current thinking,</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">the</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">solution</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">would be a library and internally</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">call the SDK route list API and peer to</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial"></FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">peer POI APIs</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial"></FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> </SPAN></P>


<P DIR=LTR><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">At this point</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">the remaining thing of interest for me is, if</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">based on this 2 API types (route list & POI) all</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">functionality</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial"></FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">to be provided can be covered.</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> </SPAN></P>


<P DIR=LTR><SPAN LANG="de"></SPAN><SPAN LANG="en-us"></SPAN></P>


<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">Then to prevent misunderstanding</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">:</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial"></FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> </SPAN></P>


<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">></FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">> - we can push the aggregation capabilities of the central service w/o</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial"></FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">impact to app-code / responsibilities</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">></FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">> - we can optionally tune the aggregation policies / algorithms</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial"></FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">accordant to OEM requirements per product</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">></FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">These are things which I thought we were explicitly avoiding? As I</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">></FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">understand it, you want the //providers// of POIs to be in control of</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">></FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">which of their POIs are added to the route or sent to other</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">></FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">applications.</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"></SPAN></P>


<P DIR=LTR><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">>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.</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"></SPAN></P>


<P DIR=LTR><SPAN LANG="de"></SPAN><SPAN LANG="en-us"></SPAN></P>


<P DIR=LTR><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">Yes, but please distinguish between both parts: its like 2 steps, first the Providing App decides with its build in policy what to</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">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</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">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.</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">Since the aggregation takes place in this central component,</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">this implementation decides who to deal with duplicates</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">, etc so with the final result. This implementation can be tuned, in regard to capabilities as also</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">OEM specific</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">policy.</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial"></FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial"></FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">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</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">about the</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">final</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">result.</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"></SPAN></P>


<P DIR=LTR><SPAN LANG="de"></SPAN><SPAN LANG="en-us"></SPAN></P>


<P DIR=LTR><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">And to follow up with the next topic: yes, we</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial"> want the ability to display the routelist (but no POIs) as an overlay on a libchamplain map</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">. That’s unchanged and thx that you keep an eye on it.</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> </SPAN></P>


<P DIR=LTR><SPAN LANG="de"></SPAN><SPAN LANG="en-us"></SPAN></P>


<P DIR=LTR><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">I have also enclosed some feedback</FONT></SPAN><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">in</FONT></SPAN></B><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial"></FONT></SPAN><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">green</FONT></SPAN></B><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial"> below.</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"></SPAN></P>


<P DIR=LTR><SPAN LANG="de"></SPAN><SPAN LANG="en-us"></SPAN></P>


<P DIR=LTR><SPAN LANG="de"></SPAN><SPAN LANG="en-us"></SPAN></P>


<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">From my point of view, we</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">now have a common understanding for the (high level) scope which I was looking at.</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> </SPAN></P>


<P DIR=LTR><SPAN LANG="de"></SPAN><SPAN LANG="en-us"></SPAN></P>


<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">So the remaining discussion</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">now gets reduced to the implementation detail</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">of the</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">“horizon component” - which aggregates the low level data (route list and POIs) -</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">if it should be a library or a dbus-service.</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"></SPAN></P>


<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">One</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">additional</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial"></FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">remark: where ever we have higher level APIs, we recommend to use them instead of the low-level ones, because it provides more functionality</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">as also grants</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">consistency</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial"> in an easier way for app-developers. So once the API</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">is introduced, the expectation is its used</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">by the majority of Apps.</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"></SPAN></P>


<P DIR=LTR><SPAN LANG="de"></SPAN><SPAN LANG="en-us"></SPAN></P>


<P DIR=LTR><SPAN LANG="de"></SPAN><SPAN LANG="en-us"></SPAN></P>


<P DIR=LTR><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">></FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">So we have two possible designs:</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">></FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial"> 1. Centralised (one horizon API for applications)</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">></FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial"> 2. Decentralised (separate route list and POI APIs for applications)</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"></SPAN><SPAN LANG="en-us"></SPAN></P>


<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">I would like to move this to another comparison, because like said for me both is “centralized”,</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">its only on another level. There is one</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">horizon</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">API, which consumes route-list and POIs,</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">aggregates it and</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">exposes</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">the combined data at its API. This API gets</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial"></FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">used by Apps and with that its part of the SDK-API.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">We have the following implementation possibilities</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"></SPAN></P>


<P DIR=LTR><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">1.</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">dbus</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> </SPAN></P>


<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">2.</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">library</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> </SPAN></P>


<P DIR=LTR><SPAN LANG="de"></SPAN><SPAN LANG="en-us"></SPAN></P>


<P DIR=LTR><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">F</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">unctionally</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial"> wise</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">these are identical</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">.</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial"></FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">Build in</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">algorithms for</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">aggregation</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">are same.</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> </SPAN></P>


<P DIR=LTR><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">#1 adds some more complexity in regard be</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">ing</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">an entire d-bus service</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"></SPAN><SPAN LANG="en-us"></SPAN></P>


<P DIR=LTR><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">#1 would have less peer-to-peer traffic than</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial"></FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">#2 and so would perform better on systems where a lot of</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial"> apps</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">are providing and consuming POI data</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"></SPAN></P>


<P DIR=LTR><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">on systems where</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial"></FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">this isn’t the case, design #2 would have lower overheads.</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"></SPAN></P>


<P DIR=LTR><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">We can also distinguish between having a library as frontend for</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">easy usage by</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">Apps and a dbus service behind the scene – somehow similar like libfolks. </FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">Overall its somehow similar to other database functionalities</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial"> (media, contacts, etc)</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">, having some services running asynchronously in background for data organization and frontends</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">providing</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">access to it.</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial"></FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">In that scope we may can also reflect</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">security /</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">access rights, because we had this discussion also in past that dbus access can be restricted more easy than library.</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">We may would like to restrict Access</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">for Apps how don’t need it (privacy).</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"></SPAN></P>


<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">My feeling is that we have lots of LBS Apps in our system</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial"> (that this is in fact one of the major App categories in a car)</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">,</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">which all</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">(really each one)</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">will use the horizon as it primary purpose</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">and</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">together with the</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">combined enrichment into a joint horizon</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">this</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">does not fit well to a library solution, with all its redundancy per app and</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">with that all the</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">(redundant)</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">load</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">on CPU and memory. Buts that less a discussion about library or not, its more about the process space, and</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">I</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial"></FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">feel the data handling/preprocessing/storage should run in its own process and only once for all Apps. The frontend to Apps, and the interface between both parts is not so mission critical from my point of view.</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"></SPAN></P>


<P DIR=LTR><SPAN LANG="de"></SPAN><SPAN LANG="en-us"></SPAN></P>


<P DIR=LTR><SPAN LANG="de"></SPAN><SPAN LANG="en-us"></SPAN></P>


<P DIR=LTR><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">I like to ask you to reflect</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">and discuss the various aspects</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">of both approaches again</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">and to</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">follow up afterwards.</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"></SPAN></P>


<P DIR=LTR><SPAN LANG="de"></SPAN><SPAN LANG="en-us"></SPAN></P>


<P DIR=LTR><SPAN LANG="de"></SPAN><SPAN LANG="en-us"></SPAN></P>


<P DIR=LTR><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">An one minor remark,</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">only to take care</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">we are on the</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">same</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">page in that too - </FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">like</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">in</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">all other</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">app-centric</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">concepts</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial"></FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">the User</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">has the final control about</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">interaction</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial"></FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">between Apps. It starts for sure with</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">his personal s</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">el</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">e</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">ction of Apps from store</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial"> – and with that with the candidates who are installed in the system - but it continues with the detailed selection out of the</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">installed</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial"></FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">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</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">a switch if it is allowed to access it (similar like with access to other databases, like contact, photos, etc). </FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">And this data provider role of an app should also</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">“</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">run</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">” 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</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">with some</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">appropriate</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial"> scheduling and small</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">resource</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial"></FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">needs.</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> </SPAN></P>


<P DIR=LTR><SPAN LANG="de"></SPAN><SPAN LANG="en-us"></SPAN></P>


<P DIR=LTR><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">But that is nothing special for this use-case, this is</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Arial">a general pattern for apps interacting with OS services. </FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"></SPAN><SPAN LANG="en-us"></SPAN></P>


<P DIR=LTR><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">Rgds</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">Andre</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"></SPAN></P>


<P DIR=LTR><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial"></FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-us"> </SPAN></P>


<P DIR=LTR><SPAN LANG="de"></SPAN><SPAN LANG="de-de"></SPAN></P>


<P DIR=LTR><SPAN LANG="de"></SPAN><SPAN LANG="en-us"></SPAN></P>


<P DIR=LTR><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">-----Urs</FONT></SPAN><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">prüngliche Nachricht-----<BR>

Von: Philip Withnall [<A HREF="mailto:philip.withnall@collabora.co.uk">mailto:philip.withnall@collabora.co.uk</A>]<BR>

Gesendet: Dienstag, 9. Februar 2016 15:50<BR>

An: Barkowski Andre (CM-CI1/PRM1) <Andre.Barkowski@de.bosch.com>; devel@lists.apertis.org<BR>

Betreff: Re: AW: AW: AW: AW: AW: AW: AW: AW: [Devel] Updated geolocation and navigation design document</FONT></SPAN><SPAN LANG="de"></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">Hi Andre,</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">On Mon, 2016-02-08 at 13:28 +0000, Barkowski Andre (CM-CI1/PRM1) wrote:</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> thx for your answers. Seems that my concern in regard to</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> responsibility split has been clarified with that. </FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> So there is a "service" belonging and deployed with the Apertis OS,</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> who creates an output to Apps based on input received from Apps.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">I’m glad we got that sorted out!</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> Now lets focus on a feature scope of that service:</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> </FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> "..."</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> In the design as I see it, there is no ‘combined data set’: the SDK</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> route list API service maintains the route list which has been set by</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> one of its backends (with the backend chosen by the user; typically a</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> navigation application bundle), but it does not combine different</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> routes. It could provide multiple alternative routes from the</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> different</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> backends, although, I suppose.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> </FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> The ‘combined data set’ of POIs is formed at each application where</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> it</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> receives POIs from other applications — in the diagram, this is where</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> all the red arrow heads meet. The application may combine these POIs</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> in</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> a database, or do whatever else it likes with them. Typically, it</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> would</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> combine them with the planned navigation route, which it has received</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> from the SDK route list API (via the yellow arrows in the diagram).</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> "..."</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> </FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> </FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> I am exactly asking for a service doing this task _centrally_ for all</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> Consuming Apps.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> On a the one hand, this does not restrict apps doing whatever they</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> like based on some low level APIs - because the way you explain is</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> still possible anyhow. But since we are talking about which</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> functionality we like to build into our OS, it does not matter what</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> Apps can do by themselves. </FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">My plan was to provide a client library which applications can use to</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">access and aggregate the SDK route list API and the POI API.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">Applications which use this library are easier to implement and get</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">consistent behaviour with all other applications which use the library.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial">Andre:</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">this clarifies</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">a</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial"> misunderstanding</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial">.</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> </SPAN></B></P>


<P DIR=LTR><SPAN LANG="de"></SPAN><SPAN LANG="en-us"></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">Internally, the library would call the SDK route list API and peer to</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">peer POI APIs as described in my previous e-mail.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"></SPAN></P>


<P DIR=LTR><SPAN LANG="de"></SPAN></P>


<P DIR=LTR><SPAN LANG="de"></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> There are various benefits of providing a central service for this </FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> - it eases the app-development for Apps interested in the aggregated</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> data, because it frees them to do the pain by themselves </FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> - it grants consistency, because all apps using this data are using</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> the same foundation instead of app-specific differences </FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">These are possible by using a client library or a centralised service.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><B></B></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><B><FONT COLOR="#538135" SIZE=2 FACE="Arial">Andre:</FONT></B></SPAN><SPAN LANG="de"><B> <FONT COLOR="#538135" SIZE=2 FACE="Arial">agree</FONT></B></SPAN><SPAN LANG="de"><B><FONT COLOR="#538135" SIZE=2 FACE="Arial">d</FONT></B></SPAN><SPAN LANG="de"><B><FONT COLOR="#538135" SIZE=2 FACE="Arial">.</FONT></B></SPAN><SPAN LANG="de"><B></B></SPAN></P>


<P DIR=LTR><SPAN LANG="de"></SPAN><SPAN LANG="en-us"></SPAN></P>


<P DIR=LTR><SPAN LANG="de"></SPAN><SPAN LANG="en-us"></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> - we can push the aggregation capabilities of the central service w/o</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> impact to app-code / responsibilities</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> - we can optionally tune the aggregation policies / algorithms</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> accordant to OEM requirements per product</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">These are things which I thought we were explicitly avoiding? As I</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">understand it, you want the //providers// of POIs to be in control of</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">which of their POIs are added to the route or sent to other</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">applications.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">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.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial">Andre:</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">we have</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">the producer and the consumer, and everyone takes care about its own duty. See above, hope this misunderstanding is clarified</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"></SPAN></B></P>


<P DIR=LTR><SPAN LANG="de"></SPAN><SPAN LANG="en-us"></SPAN></P>


<P DIR=LTR><SPAN LANG="de"></SPAN><SPAN LANG="en-us"></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> - we can process the aggregated information by further system</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> applications, e.g. by optional system chrome applications (ala</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> notification center), or automotive domain services</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> - etc</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">That can be handled already, by having those system components consume</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">the same information, using the same APIs as applications.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><B><FONT COLOR="#538135" SIZE=2 FACE="Arial">Andre</FONT></B></SPAN><SPAN LANG="de"><B><FONT COLOR="#538135" SIZE=2 FACE="Arial">:</FONT></B></SPAN><SPAN LANG="de"><B> <FONT COLOR="#538135" SIZE=2 FACE="Arial">agreed.</FONT></B></SPAN><SPAN LANG="de"><B></B></SPAN></P>


<P DIR=LTR><SPAN LANG="de"></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> So we are discussing here a more powerful service. </FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> With that the design proposed based on some low level mechanisms does</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> fit to the intention.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> Please forget in the first hand</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> - the pipe based mechanism to transfer POI data </FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> - the route-list data</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> </FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> We are _not_ asking for an API tailored (or limited) for the special</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> case of sharing a route-list.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> Its more like a "focal point", the route-list information is included</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> but its not limited to. </FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> What we intend to create is a "service" exposing a "horizon". The</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> horizon exposes "data ahead of the vehicle". A navigation app can</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> provide its route-list to it. </FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> But in general, its neither limited to the route-list nor to the</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> navigation app. The service aggregates data from various sources</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> (Apps). </FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">I see what you mean. My thinking behind providing the route list and</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">POIs separately are because other parts of the geolocation design</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">require them separately — you wanted the ability to display the route</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">list (but no POIs) as an overlay on a libchamplain map in an</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">application, for example. So a route list API has to exist; and if that</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">exists, and the peer-to-peer POI API already exists, why not use the</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">two to provide the horizon to applications?</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial">Andre:</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">yes, that needs to be supported</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial"></FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> </SPAN></B></P>


<P DIR=LTR><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial">In general I see this like higher level APIs of same kind,</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">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</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">also raw entities to aggregated ones.</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">So looks like we are on the same page for that.</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"></SPAN></B></P>


<P DIR=LTR><SPAN LANG="de"></SPAN><SPAN LANG="en-us"></SPAN></P>


<P DIR=LTR><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">> And I am not only talking about combining routes from various</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> Sources(Apps). That’s only an example to point out challenges. So</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> don't forget the more common case to add additional objects like POIs</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> to a given Route, as also to add attributes (metadata) to already</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> available objects.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> </FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> Once this service is available, we do _not_ need any public route-</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> list API exposed to other Apps anymore, because the route-list data</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> is included in the horizon. So if Apps like to get route-list</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> information, they will find them in the horizon data. </FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">I think we’re coming at this from opposite directions: as I said above,</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">I’m thinking about providing APIs A and B separately, and allowing</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">applications to use either or both. You’re thinking about providing API</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">C (which is a combination of A and B), and applications can use that</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">and filter out what they don’t want.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial">Andre</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial">: my understanding from your explanations above is, that you also provide the library to create C (the combination of A and B)</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial">.</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">That’s what I call</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">centralized.</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">S</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial">o</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">finally,</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">its simple all supported</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">by prepared SDK-APIs. That’s fine for me. </FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> </SPAN></B></P>


<P DIR=LTR><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial">In gene</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial">r</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial">al I like to enable Apps also to</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">not using</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">prepared high level APIs, and to create their own implementation based on more low level</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">APIs</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial">. So exposing both</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">levels</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">is welcome in</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">that regard.</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> </SPAN></B></P>


<P DIR=LTR><SPAN LANG="de"></SPAN><SPAN LANG="en-us"></SPAN></P>


<P DIR=LTR><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">So we have two possible designs:</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial"> 1. Centralised (one horizon API for applications)</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial"> 2. Decentralised (separate route list and P</FONT></SPAN><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">OI APIs for applications)</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">Functionally, these are identical and I can’t see any significant</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">reasons for preferring one over the other.</FONT></SPAN><SPAN LANG="de"> </SPAN></P>


<P DIR=LTR><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial">Andre</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial">:</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial"> agreed.</FONT></SPAN></B><SPAN LANG="de"></SPAN></P>


<P DIR=LTR><SPAN LANG="de"></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">Design #1 requires a more</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">complex aggregation service to be written;</FONT></SPAN><SPAN LANG="de"> </SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">design #2 moves that</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">complexity into a library which is used by each application (although</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">it would end up being less complex, as it doesn’t have to be an entire</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">D-Bus service).</FONT></SPAN><SPAN LANG="de"> </SPAN></P>


<P DIR=LTR><SPAN LANG="de"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">Design #1 would have less peer-to-peer traffic than</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">design #2 and so would perform better on systems where a lot of</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">applications are providing and consuming POI data; on systems where</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">this isn’t the case, design #2 would have lower overheads.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial">Andre</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial">:</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial"></FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">since it looks now we are on the same page in regard to function partitioning and code responsibility, we can now start the</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">pros/cons discussion about the implementation detail</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">"library vs</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">dbus</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial">"</FONT></SPAN></B><SPAN LANG="de"></SPAN><SPAN LANG="en-us"></SPAN></P>


<P DIR=LTR><SPAN LANG="de"></SPAN><SPAN LANG="en-us"></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> However, even though the route list information is distributed via</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> the horizon service to arbitrary Apps, the route-list data itself is</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> delivered by participating navigation Apps. With that the route-list</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> data is provided at a more dedicated API (more private between</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> horizon service and navi app), only relevant for navigation Apps and</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> only if they like to participate as a horizon provider. </FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">So does this mean that I have misunderstood the need for a libchamplain</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">map layer which applications can use to display //just// the route list</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">on top of a map (with no POIs or other horizon data)? Or do you want</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">that to be implemented by consuming the horizon API and filtering out</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">the POIs to just leave the route list data?</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial">Andre</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial">:</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial"> no, you did not misunderstood it.</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">The functionality is needed.</FONT></SPAN></B></P>


<P DIR=LTR><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial">My focus is on the SDK-API</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial">, things which gets used by the Apps. A</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial">pps use libchamplain,</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">so that the SDK-API in this regard. H</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial">ow data lands in libchamplain is out of scope of the SDK-API.</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial"> So we can add the route-data (only, w/o POIs) into libchamplain, and nevertheless discuss SDK-API for horizon.</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial"> So we can talk about different lines of APIs.</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> </SPAN></B></P>


<P DIR=LTR><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial">The libchamplain</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">integration</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">is</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">behind the scene. Its part of the OS, behind the SDK-API.</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">Not</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">in the scope which I look to right now.</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> </SPAN></B></P>


<P DIR=LTR><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial">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</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial"> -</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial"></FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">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.</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">But like I said already above, I also like to provide APIs over various "levels", so from more native to more</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">aggregating</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"><FONT COLOR="#538135" SIZE=2 FACE="Arial"></FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> <FONT COLOR="#538135" SIZE=2 FACE="Arial">ones, I also support to have the native APIs available at SDK-API.</FONT></SPAN></B><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="en-us"> </SPAN></B></P>


<P DIR=LTR><SPAN LANG="de"></SPAN><SPAN LANG="en-us"></SPAN></P>


<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">Philip</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">> In addition we can even discuss the implementation steps/roadmap. So</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">> once we have agreed on the complete scope of t</FONT></SPAN><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">his service, we can</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> discuss when to introduce which (aggregation) functionality. And in</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> this point of view, the first implementation step could even be</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> limited to provide a route-list only capability, but we would have</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> awareness about what will come up next and with that we could take</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> care about future proofness of introduces APIs. </FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> </FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> </FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> Rgds</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> Andre</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> </FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> </FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> </FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> -----Ursprüngliche Nachricht-----</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> Von: Philip Withnall [</FONT></SPAN><SPAN LANG="de"></SPAN><A HREF="mailto:philip.withnall@collabora.co.uk"><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">mailto:philip.withnall@collabora.co.uk</FONT></SPAN><SPAN LANG="de"></SPAN></A><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">] </FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> Gesendet: Freitag, 5. Februar 2016 15:34</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> An: Barkowski Andre (CM-CI1/PRM1) <</FONT></SPAN><SPAN LANG="de"></SPAN><A HREF="mailto:Andre.Barkowski@de.bosch.com"><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">Andre.Barkowski@de.bosch.com</FONT></SPAN><SPAN LANG="de"></SPAN></A><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">>; dev</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">></FONT></SPAN><SPAN LANG="de"> </SPAN><A HREF="mailto:el@lists.apertis.org"><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">el@lists.apertis.org</FONT></SPAN><SPAN LANG="de"></SPAN></A><SPAN LANG="de"></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> Betreff: Re: AW: AW: AW: AW: AW: AW: AW: [Devel] Updated geolocation</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> and navigation design document</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> </FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> Hi Andre,</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> </FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> On Thu, 2016-02-04 at 09:56 +0000, Barkowski Andre (CM-CI1/PRM1)</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> wrote:</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > since I still do not know where the blocking factor is let me give</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > some range of feedback, maybe one hits the point</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > - Apps do not change the system scope, they do not install stuff</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > (e.g. backends) into the system. They may ship a backend, but all</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > that belongs and gets installed to its black box environment.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > However, they may exposes data to some already available system</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > service via some SDK-API.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> </FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> We agree on this. The backends for the SDK route list API in my</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> diagram</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> are provided by application bundles.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> </FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > - App UI (like "Fuel Station application UI" or "Navigation</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > UI")  belongs the "application bundle"</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> </FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> We agree on this. I did not show that in the diagram in order to keep</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> it legible.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> </FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > - So the Navi is completely handled as a App-Bundle covering the</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > "Backend" (including route planning) as also the "UI" in its own</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > black box. </FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> </FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> We agree on this. Again, I did not show that in the diagram in order</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> to</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> keep it legible.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> </FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > - since the "navigation UI" belongs the nav app-bundle, it is</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > directly connected to its backend  The Navi UI can use whatever</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > black-box internal ways to interact with its backend to create its</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > UI. Same like for each other App-Bundle. The Navi is just another</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > App. However, in addition its proprietary backend may exposes some</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > data to a SDK-API service (route-list "horizon"), and the backend</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > may</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > also consumes aggregated data form (this) SDK-API service. </FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> </FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> OK, I have noted the potential for an arbitrary connection between</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> the</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> navigation backend and navigation UI.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> </FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> We agree on the rest: in the diagram, the ‘backend provided by</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> navigation application bundle’ exposes data to the SDK route list API</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> (which is actually a service/process — it’s a box in the diagram). It</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> can also consume data from that API, although that’s not shown in the</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> diagram. There is nothing to prevent that.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> </FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > - its not like discussed for libchamplain or tts or other topics,</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > where the "backends" reside in the OS scope (functionality embedded</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > in the OS). In these areas the backend of choice gest decided by</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > the</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > system integrator at point in time of product definition (it cannot</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > be changed by the User). In contrast to that, for navi we enable</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > flexibility during runtime. Installing an app changes the "backend</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > used". So the Navi App Bundle ships the backend and its UI, but</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > does</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > not change installations in the OS. The App bundle exposes data to</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > the SDK.Route List (Horizon) APIs to other Apps. So we shift the</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > responsibility by keeping the app-centric approach - from the</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > integrator to the user and from OS-scope to App-scope.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> </FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> We agree on this.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> </FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > - With that flexibility, the User has the option to decides for the</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > Navi of his choice.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> </FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> We agree on this.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> </FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > - if the backend is located in automotive domain, then this is</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > coupled/bundled with one (maybe build in) "Navi App". </FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> </FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> We agree on this.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> </FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > - The rout-list "horizon" API, is not primary used to create a</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > User-</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > Interface for a "Navigation" Application, neither from other Apps</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > nor</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > from the App bundle who provides the "backend". The primary purpose</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > for the route-list API "horizon" is _not_ to serve for the</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > navigation</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > build-in functionality. Its for location based services/Apps.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> </FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> OK, I had been assuming it could be used for the navigation UI, but</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> if</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> the navigation UI and backend want to use an arbitrary connection to</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> communicate routes, that’s fine (as agreed a few points above).</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> </FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> We agree on the fact that the SDK route list API (which you call</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> ‘route-list API "horizon"’) is used for location-based services and</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> applications.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> </FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > - POIs transferred via the pipe mechanism lands in the App specific</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > local "database" (not directly at the UI), the App takes over the</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > data responsibility/management, its like an import. The App decides</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > about if and how to persistently store it, when to delete etc.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > These</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > data runs like all the other local app data though its app-specific</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > business logic / functionality. Its even possible that these data</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > gets only consumed by some algorithms and never lands natively at</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > the</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > UI. </FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> </FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> We agree on this, although I have not discussed the possibility of</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> applications storing points of interest in an internal database. What</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> applications do with points of interest once they have received them</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> is</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> up to the application developer — they can store the POIs in a</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> database, display them directly in the UI without storage, or process</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> them without ever putting them in a UI, as you say. That’s why I</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> haven’t mentioned databases.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> </FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > - think about a setup w/o any navigation installed. Then there is</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > no</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > navi backend installed. Nevertheless, the is a route-list "horizon"</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > API where Apps can consume data from and expose data to (accordant</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > to</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > their app internal functional scope). </FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> </FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> We agree on this: the SDK route list API still exists even if no</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> navigation applications are installed. As I said: it’s a service</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> provided by the SDK (and hence is represented as a box in the diagram</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> I</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> sent). It can be running and providing the SDK route list API to</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> applications and services even if no backends are available from</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> navigation application bundles (or other bundles).</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> </FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > - It could even be the case that some Apps who are not being a</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > "navigation App" provide some most probable path information to the</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > horizon. Its not a route -since no destination is set and even no</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > navigation installed), but guessing about  the way ahead. It could</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > be</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > limited in length (e.g. only until next intersection, or a little</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > ahead of this with even multiple pathes from each intersection,</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > etc).</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > And this can also be added in case a route is given, adding more</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > information about alternative links at intersection could be</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > benefitail for some other Apps to know. So finally its not only</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > POI. </FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> </FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> We agree on this: such applications could provide a backend for the</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> SDK</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> route list API just like navigation application bundles can.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> </FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > so some questions:</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > - which "component" represents the glue (the framework) between the</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > LBS-Apps (like Navi, Restaurants, Sightseeing, etc), to receive</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > dedicated data from individual producers (LBS Apps), creates and</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > maintains a combined data set, and deliver the data exposed as</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > route-</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > list "horizon" API to consumers (its not the "backend" located in</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > the</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > App Bundle if a a Navi App, this backend is itself a producer only)</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > ? </FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> </FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> This is a combination of the SDK route list API (and the service</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> which</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> provides it, which is part of the SDK and provided by Apertis), and</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> the</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> POI API with its peer-to-peer connections from any other application</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> which provides a points of interest interface.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> </FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> In the design as I see it, there is no ‘combined data set’: the SDK</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> route list API service maintains the route list which has been set by</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> one of its backends (with the backend chosen by the user; typically a</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> navigation application bundle), but it does not combine different</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> routes. It could provide multiple alternative routes from the</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> different</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> backends, although, I suppose.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> </FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> The ‘combined data set’ of POIs is formed at each application where</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> it</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> receives POIs from other applications — in the diagram, this is where</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> all the red arrow heads meet. The application may combine these POIs</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> in</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> a database, or do whatever else it likes with them. Typically, it</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> would</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> combine them with the planned navigation route, which it has received</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> from the SDK route list API (via the yellow arrows in the diagram).</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> </FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > (Btw, a Navi Backend from a proprietary Supplier may do not has at</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > all any of the capabilities needed to aggregate POI data from</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > various</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > sources into a combined set. )</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> </FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> In the design there is no need for the navigation backend to</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> aggregate</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> POI data — that is done by the applications which are consuming the</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> POI</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> data (the heads of the red arrows in the diagram).</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> </FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > - in which format/way gets this data forwarded to this component ?</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > It</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > does not need to be the pipe based POI mechanism only because we</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > have</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > it. Geoclue also deals with coordinates and nevertheless uses</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > another</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > kind of API to exchange information with its backends. On top its</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > not</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > only POIs, ist also links(streets) etc to be provided to the</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > "horizon" framework. </FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> </FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> The design recommends (in §7.6 of version 0.3.1 of the design) a D-</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> Bus</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> interface for the SDK route list API which exposes each possible</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> route</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> as an array of (latitude, longitude) coordinates.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> </FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> Are the areas in the diagram where I’ve highlighted components which</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> have responsibility for making decisions correct, in your</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> understanding? These are the blue circles in the diagram.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> </FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> Philip</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> </FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > -----Ursprüngliche Nachricht-----</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > Von: Philip Withnall [</FONT></SPAN><SPAN LANG="de"></SPAN><A HREF="mailto:philip.withnall@collabora.co.uk"><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">mailto:philip.withnall@collabora.co.uk</FONT></SPAN><SPAN LANG="de"></SPAN></A><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">] </FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > Gesendet: Mittwoch, 3. Februar 2016 16:18</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > An: Barkowski Andre (CM-CI1/PRM1) <</FONT></SPAN><SPAN LANG="de"></SPAN><A HREF="mailto:Andre.Barkowski@de.bosch.com"><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">Andre.Barkowski@de.bosch.com</FONT></SPAN><SPAN LANG="de"></SPAN></A><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">>;</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > dev</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> ></FONT></SPAN><SPAN LANG="de"> </SPAN><A HREF="mailto:el@lists.apertis.org"><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">el@lists.apertis.org</FONT></SPAN><SPAN LANG="de"></SPAN></A><SPAN LANG="de"></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > Betreff: Re: AW: AW: AW: AW: AW: AW: [Devel] Updated geolocation</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > and</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > navigation design document</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > </FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > Hi Andre,</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > </FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > As far as I can tell, the design I suggested in my previous e-mail</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > does</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > match your requirements for which components have responsibility</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > for</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > different decisions or pieces of information:</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> >  • Applications choose which POIs to advertise, and the navigation</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > UI</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > displays them unconditionally (subject to rate limiting)</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> >  • The route list API is provided by the SDK, in the system, and</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > supports multiple backends — the backend might be provided by the</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > navigation application bundle, but might instead be in the</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > automotive</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > domain, or something else</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> >  • The navigation UI is just another application, and has no</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > special</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > powers or functionality</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> >  • Applications choose which waypoints to send to the route list</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > API</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > to</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > be added into the route — this might result in the user being</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > prompted</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > ‘do you want to add this waypoint into your route’, or they might</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > be</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > added unconditionally</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > </FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > I have attached a diagram of the system as I described it in my</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > previous e-mail, and have attempted to highlight all the data flows</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > and</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > the decisions which drive them. (Apologies for the crudeness of the</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > drawing; I did it rapidly.)</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > </FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > Please could you take a look and see where our understandings</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > differ,</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > and highlight specifically what the differences are.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > </FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > Thanks,</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > Philip</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > </FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > On Wed, 2016-02-03 at 14:16 +0000, Barkowski Andre (CM-CI1/PRM1)</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > wrote:</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > Hi Philip,</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > Thanks for your answer, but we are still not on the same page. We</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > talking about different things.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > There are other parts beside feature requirements which influence</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > the</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > decomposition. Its seems for me that you are focusing on features</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > and</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > if the design/decomposition proposed is able to realize it. My</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > focus</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > is alignment with app-centric design, so responsibilities &</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > dependencies (I only use features to make things more clear). So</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > if</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > you are saying the design can provide the feature, then that’s</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > not</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > what I am talking about. I am talking about the design does not</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > fit</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > to the non-function requirements (app-centric solution). Parts of</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > the</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > functionality belongs to the wrong responsibility or we even do</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > need</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > to split an entity into parts to deploy the responsibility to</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > different parties.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > Since we are iterating in cycles a little bit and I start to gets</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > doubts about the efficiency of this kind of mail threads, let us</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > limit the iterations. If within a few next ones we do not</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > conclude,</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > then lets have a call about it. But for now let me try to explain</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > my</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > intention again via email:</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > So yes, one can technically pass everything through the</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > navigation</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > App, delivering all POIs to the App as also requesting a</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > consolidated</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > data from it. That’s possible. </FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > And the design is done in that way. And that’s not the way how it</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > shall be. So its not the question if the current design can also</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > realize the mentioned features.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > The POI mechanism defined already was motivation by the update of</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > the</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > navi-database with data needed for route calculation. Only for</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > that</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > purpose. So for now, please forget the POI mechanism defined</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > already.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > Now we are talking about the “route list”. Maybe the naming is</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > not</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > beneficial, internally we typically use the term “horizon”. Its</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > dedicated scope is to carry information related to the (expected)</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > vehicle position, starting from the current location up to</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > expected</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > future positons. This is where the term route-list comes into the</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > game. The goal now is to provide a framework, where all apps can</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > consume data from for their internal processing as also provide</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > data</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > to this framework (to enrich it).</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > This all is also valid w/o any route available. In that case the</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > data</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > focus more around the current vehicle position. It is even valid,</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > if</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > there is no navigation app installed at all. There is</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > nevertheless</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > the current geo position available (e.g. from geoclue, and maybe</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > even</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > only on WLAN based positioning so without any GPS solution, that</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > doesn’t matter). The navigation App is just another App,</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > optionally</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > producing data to that framework and/or consuming data from it</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > (e.g.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > the information about the current route, including its</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > intermediate</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > destinations etc). And it could even be that multiple Apps,</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > dealing</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > with most probable pathes exposes information to this horizon</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > (not</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > only the Navi App currently maintaining the active route). The</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > framework is completely independent of the developer of a</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > particular</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > Navigation App, this solutions is completely out of the</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > scope/responsibility of the navigation provider. It belongs to</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > the</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > system, the OS.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > And yes, intermediate destinations are provided and handled by a </FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > navigation app, again via another mechanism (the scheme</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > mechanisms,</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > not the POI one). And if a new intermediate destination has been</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > defined via this way, and the route has been updated, then the</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > navi</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > app can expose it to the said horizon framework. And another App</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > can</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > consume this new information about an intermediate destination</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > for</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > their scope and may also add new data to this framework</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > accordingly.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > So what I am asking for is, to keep the POI mechanism as a way of</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > choice for database updates, and to add an additional framework –</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > which we can call “horizon” or something else - where Apps can</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > produce data to as also consume data from it. The Navi App shall</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > be</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > able to provide its route list information to it and update it.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > Rgds</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > Andre</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > -----Ursprüngliche Nachricht-----</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > Von: Philip Withnall [</FONT></SPAN><SPAN LANG="de"></SPAN><A HREF="mailto:philip.withnall@collabora.co.uk"><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">mailto:philip.withnall@collabora.co.uk</FONT></SPAN><SPAN LANG="de"></SPAN></A><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">]</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > Gesendet: Dienstag, 2. Februar 2016 18:27</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > An: Barkowski Andre (CM-CI1/PRM1) <</FONT></SPAN><SPAN LANG="de"></SPAN><A HREF="mailto:Andre.Barkowski@de.bosch.com"><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">Andre.Barkowski@de.bosch.com</FONT></SPAN><SPAN LANG="de"></SPAN></A><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">>;</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > dev</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > ></FONT></SPAN><SPAN LANG="de"> </SPAN><A HREF="mailto:el@lists.apertis.org"><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">el@lists.apertis.org</FONT></SPAN><SPAN LANG="de"></SPAN></A><SPAN LANG="de"></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > Betreff: Re: AW: AW: AW: AW: AW: [Devel] Updated geolocation and</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > navigation design document</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > Hi Andre,</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > Replies inline. I’ve trimmed a few of the parts of the e-mail</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > which</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > we</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > agree on.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > On Tue, 2016-01-26 at 13:03 +0000, Barkowski Andre (CM-CI1/PRM1)</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > wrote:</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > However, my understanding of</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > ></FONT></SPAN><SPAN LANG="de"> </SPAN><A HREF="https://wiki.apertis.org/Points_of_interest"><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">https://wiki.apertis.org/Points_of_interest</FONT></SPAN><SPAN LANG="de"></SPAN></A><SPAN LANG="de"><FONT SIZE=2 FACE="Arial"> design is, that</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > only</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > the</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > control flow runs via a central SDK service, but if allowed it</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > establishes a private point-to-point channel (pipe) between</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > producer</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > App and consumer App (w/o any SDK service inbetween anymore).</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > With</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > that, the content itself (the POIs) are untouched form the so</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > called</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > "central POI service", the POIs are neither stored/cached, nor</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > distributed by them. With that, the "SDK-Service" (central POI</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > service) does _not_ return points of interest like restaurants,</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > filling stations and tourist attractions. As also there is no</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > capability to define filters in that request, since in an app-</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > centric</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > approach the policies are belonging to the Source/Producer App.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > The</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > SDK service itself only establishes private point to point</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > connections.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > That is correct. I guess when I’ve been saying ‘POI service’ or</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > ‘POI</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > system’ from the point of view of an application which is</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > consuming</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > POI</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > data (such as the navigation UI, or another application which</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > needs</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > to</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > display POIs), I would consider the ‘POI service/system’ to be</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > the</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > set</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > of all applications which are providing POIs over peer-to-peer</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > connections.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > • Route list: a list of objects which describe the route for a</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > navigation, i.e. the roads to take; this might include</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > alternative</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > routes; it _does_ include Point objects like intermediate</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > destinations on the route</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > so there are point type objects already included in that</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > structure</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > as</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > also attributes/metadata for each object for further details.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > Yes, although the metadata is limited to a description for the</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > location</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > and what type of point it is (start, waypoint, waypoint which is</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > for</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > routing only and isn’t a destination, final destination).</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > Please note, that the navigation "route-list" is something</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > different</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > than the navigation "guidance". The guidance focus on detailed</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > description of turns ahead, the route-list has a different</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > focus</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > -</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > it</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > describes the complete trip. So that’s 2 APIs and different</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > structures/objects. I would recommend to adopt the document</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > accordingly.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > Noted — I will include this in the next update to the document.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > And what I am talking about now is, that apps shall be able to</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > augment the route list returned by the SDK-API . The route list</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > exposed via the route-list SDK-API for sure gets provided (and</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > updated) by the navigation app (somehow similar like it can do</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > it</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > for</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > the geo-position to geo-clue), but Apps can augment data to it.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > The APIs realizing this capability have second priority for me,</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > but</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > nevertheless I like to cover it right from the beginning  from</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > conceptual point of view.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > With "create some functionality" I do mean the samples provided</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > to</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > explain use-cases where Apps consume and augment POIs to the</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > route</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > list:</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > -  a Weather App may consumes Intermediate Destination</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > Information</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > from Route List to show entries on top of the user stored</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > locations</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > in its UI to inform the User about weather at this places</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > - a gasoline station app adds a refueling stop into the route</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > list</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > for a location to be reached at a time where the car runs low</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > on</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > fuel</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > - a restaurant app may uses information of gasoline stations in</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > the</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > route list to add recommended cafeterias into the route list to</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > align</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > the breaks for the driver</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > - a restaurant app may decides to add restaurant POIs as</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > recommendations into the route list for a location to be</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > reached</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > at</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > a</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > time where a break would be wise</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > - a installed “coupon” app may add available discounts</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > available</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > at</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > a</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > POI location available in route list.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > The major thing is, in an app centric approach, the policies</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > are</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > coupled with the source of the data. Its _not_ the navigation</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > app</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > which orchestrates the other apps - like in a systemic client-</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > server</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > model, what to deliver. This limits the capabilities to fantasy</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > provided by the navigation app developer as also his</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > capabilities</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > and</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > development work. In an app-centric approach its completely</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > vice</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > versa, each app focus on its essential service, a navigation</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > calculates the route. That’s it. And a restaurant app deals the</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > POI,</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > and handles all policies and User Interaction to choose/handle</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > them,</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > even though they may finally gets used to set a new destination</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > or</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > they land in the route list.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > OK. I think this fits with my proposed design and the Points of</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > Interest design as they currently stand, although I should</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > clarify</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > things.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > The route list API continues to provide only the list of roads to</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > take</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > (i.e. the geometry of the route) as I described in my previous e-</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > mail.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > Applications which provide POIs query this API to find out the</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > current</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > route, as described in the fourth paragraph of</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > ></FONT></SPAN><SPAN LANG="de"> </SPAN><A HREF="https://wiki.apertis.org/Points_of_interest#Recommendations"><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">https://wiki.apertis.org/Points_of_interest#Recommendations</FONT></SPAN><SPAN LANG="de"></SPAN></A><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > The navigation UI uses interface discovery to find applications</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > which</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > provide POI data. It then queries them (via peer-to-peer</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > connections)</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > for general and specific POIs, as described in the POI design.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > Its shall not be the responsibility of the Navigation to requests</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > it/or not.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > Its done by the Providing Apps autonomously.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > It shall not depend on the code (responsibility) of the</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > navigation</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > App at all if this</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > The logic for working out what POIs to send to the navigation UI</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > lies</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > within each application. The navigation UI does no filtering</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > based</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > on</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > content (though for security reasons it might want to apply some</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > rate</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > limiting to prevent DoS attacks). It simply displays all the POIs</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > it</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > receives.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > It might be possible for an application to add metadata to a POI</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > it</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > sends to the navigation UI to say ‘please add this POI as a</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > waypoint’,</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > in which case the navigation UI could prompt the user about it</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > (or</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > add</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > the destination anyway, or ignore it — this policy is up to the</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > navigation UI developer). If the POI is added as a waypoint in</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > the</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > route, the SDK route list API would signal an update to the</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > route,</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > which would be received by the navigation UI and all applications</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > providing POIs to it. This would allow for the coupon use case —</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > if</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > a</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > restaurant gets added as a waypoint, the coupon application could</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > start</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > emitting a POI for using coupons there.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > If another application wants to display the same map view as the</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > navigation UI, showing the route and POIs on it, it has to make</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > the</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > same API calls as the navigation UI: a call to the SDK route list</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > API</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > to get the route; and interface discovery followed by peer-to-</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > peer</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > retrieval of POIs from other applications.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > So, in short, the ‘augmented route list’ is provided by a</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > combination</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > of the route list API and the POI system (i.e. retrieving POIs</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > from</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > other applications using peer-to-peer connections).</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > I hope that makes sense?</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > Philip</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > -----Ursprüngliche Nachricht-----</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > Von: Philip Withnall [</FONT></SPAN><SPAN LANG="de"></SPAN><A HREF="mailto:philip.withnall@collabora.co.uk"><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">mailto:philip.withnall@collabora.co.uk</FONT></SPAN><SPAN LANG="de"></SPAN></A><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">]</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > Gesendet: Montag, 25. Januar 2016 15:56</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > An: Barkowski Andre (CM-CI1/PRM1) <Andre.Barkowski@de.bosch.com</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > >;</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > dev</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > ></FONT></SPAN><SPAN LANG="de"> </SPAN><A HREF="mailto:el@lists.apertis.org"><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">el@lists.apertis.org</FONT></SPAN><SPAN LANG="de"></SPAN></A><SPAN LANG="de"></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > Betreff: Re: AW: AW: AW: AW: [Devel] Updated geolocation and</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > navigation design document</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > Hi Andre,</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > On Fri, 2016-01-22 at 17:16 +0000, Barkowski Andre (CM-</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > CI1/PRM1)</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > wrote:</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > Hi Philip,</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > I feel we are still not fully on the same page. We closed</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > some</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > gaps</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > lately (in regard to the assist-window), but it seems to me</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > that</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > we</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > still have a gap in regard to POI handling itself.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > So summarize, let me go one step back and start with</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > -       POI service is _not_ equal to route-list.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > I am talking about a route list, you are talking about a</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > central</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > poi</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > service.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > To check, what do you mean by the terms ‘POI service’ and</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > ‘route</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > list’?</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > I interpret them as:</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > >  • POI service: an SDK service which returns points of interest</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > like</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > restaurants, filling stations and tourist attractions</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > >  • Route list: a list of points which describe the plotted</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > route</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > for</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > a</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > navigation, i.e. the roads to take; this might include</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > alternative</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > routes; it does not include nearby POIs</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > Andre: hope this is answered above</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > Let me add:</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > -       we do _not_ need a central POI service, or vice versa</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > I</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > am</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > not aware about a related requirement.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > All suggestions I have made about POI handling in the context</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > of</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > the</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > Geolocation and Navigation document have been references to the</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > existing</FONT></SPAN><SPAN LANG="de"> </SPAN><A HREF="https://wiki.apertis.org/Points_of_interest"><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">https://wiki.apertis.org/Points_of_interest</FONT></SPAN><SPAN LANG="de"></SPAN></A><SPAN LANG="de"><FONT SIZE=2 FACE="Arial"> design. I</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > am</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > not</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > suggesting changes to that design, nor am I suggesting copying</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > parts</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > of</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > it into this design (or any of the navigation APIs).</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > Andre: I see.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > We do have the already mentioned 3 Use cases and the</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > mechanisms</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > discussed covers the use-cases already perfectly</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > 1) for in app UI browsing: libchamlain. We have it, fine.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > Yes.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > 2) for app import / handover: Pull mode for various types of</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > content</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > – also TPEG based POI data -</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > ></FONT></SPAN><SPAN LANG="de"> </SPAN><A HREF="https://wiki.apertis.org/Points_of_interest"><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">https://wiki.apertis.org/Points_of_interest</FONT></SPAN><SPAN LANG="de"></SPAN></A><SPAN LANG="de"></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > (For completion there is also a push mode for various types</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > of</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > content – so far no need for TPEG support -  </FONT></SPAN><SPAN LANG="de"></SPAN><A HREF="https://wiki.ape"><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">https://wiki.ape</FONT></SPAN><SPAN LANG="de"></SPAN></A><SPAN LANG="de"></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > rt</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > is</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > .o</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > rg</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > /Data_sharing )</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > again, we have it designed already.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > Yes.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > 3) now we add the route-list to the SDK-API, where I also ask</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > to</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > provide capabilities to add POIs to it (independent from the</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > navi-</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > app)</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > I think this is covered by the SDK navigation route guidance</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > API</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > (§7.6</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > of version 0.3.1 of the document), if we are using the same</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > meaning</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > for</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > ‘route list’ (see above).</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > Andre: see above, I think we do need 2 API scopes, one for</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > “route-</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > list” one for “guidance”</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > In any case we do need the route list, it has originally</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > nothing</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > to</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > do with the POI discussion. Apps shall be able to consume</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > information</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > about the current route and to create some functionality.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > That</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > the</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > purpose of the route list essentially.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > What do you mean by ‘create some functionality’?</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > In the design as it stands currently, applications cannot</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > augment</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > the</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > route list returned by the SDK navigation route guidance API.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > They</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > can</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > augment the list of POIs returned by the POI API (</FONT></SPAN><SPAN LANG="de"></SPAN><A HREF="https://wiki"><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">https://wiki</FONT></SPAN><SPAN LANG="de"></SPAN></A><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > ap</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > er</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > ti</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > s.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > org/Points_of_interest).</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > Andre: see above, I do mean things like that</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > -  a Weather App may consumes Intermediate Destination</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > Information</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > from Route List to show entries on top of the user stored</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > locations</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > in its UI to inform the User about weather at this places</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > - a gasoline station app adds a refueling stop into the route</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > list</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > for a location to be reached at a time where the car runs low</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > on</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > fuel</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > - a restaurant app may uses information of gasoline stations in</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > the</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > route list to add recommended cafeterias into the route list to</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > align</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > the breaks for the driver</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > - a restaurant app may decides to add restaurant POIs as</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > recommendations into the route list for a location to be</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > reached</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > at</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > a</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > time where a break would be wise</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > - a installed “coupon” app may add available discounts</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > available</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > at</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > a</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > POI location available in route list.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > >  </FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > Based on that scope, I am asking for the additional</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > functionality</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > to</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > add Metadata/Content from Apps directly to it, especially</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > POIs.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > Its</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > neither a first priority nor will it dramatically change the</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > design.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > Its simple an add-on. We can even decide to implement it</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > later.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > For clarity, which API do you mean by ‘it’?</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > Andre: I do mean the capability for Apps to augment POIs into</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > the</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > Route-List</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > Similar stuff is valid for the guidance & assist window</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > discussion.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > The APIs for the “guidance”  (which is “just another</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > notification</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > style API for a dedicated purpose”) as also the assist window</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > (which</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > is just another system chrome application where for example</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > the</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > data</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > exposed via the guidance notification style SDK-API lands in)</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > are</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > optional and don’t have side effects to other SDK-APIs. So we</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > can</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > implementation wise realize it in a later step, its not of</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > first</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > priority. However, I like to have a common understanding</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > about</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > the</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > overall scope early.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > If we provide capabilities to add metadata into an available</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > route-</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > list to Apps, other Apps (than the navi app) can add</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > additional</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > content/ additional metadata to available content, for</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > example</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > POIs</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > into a currently shared route list. Since we have already</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > libchamplain and also the Point_of_interest and sharing</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > mechanisms</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > design, My focus is on just one more method for that route-</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > list.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > I</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > am</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > _not_ talking about any big thing, especially not about a</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > central</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > POI</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > service.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > I would like to propose we serialize the discussion. How</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > about</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > first</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > finalizing the solution for the route list, including POIs</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > into</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > it</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > from Apps via an SDK API.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > Then reflect, for what a central POI service could be</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > beneficial</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > ?</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > I have embedded some comments below in green.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > I’ve put a few replies below too.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > -----Ursprüngliche Nachricht-----</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > Von: Philip Withnall [</FONT></SPAN><SPAN LANG="de"></SPAN><A HREF="mailto:philip.withnall@collabora.co.uk"><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">mailto:philip.withnall@collabora.co.uk</FONT></SPAN><SPAN LANG="de"></SPAN></A><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">]</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > Gesendet: Mittwoch, 20. Januar 2016 16:57</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > An: Barkowski Andre (CM-CI1/PRM1) <Andre.Barkowski@de.bosch.c</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > om</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > > ;</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > dev</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > ></FONT></SPAN><SPAN LANG="de"> </SPAN><A HREF="mailto:el@lists.apertis.org"><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">el@lists.apertis.org</FONT></SPAN><SPAN LANG="de"></SPAN></A><SPAN LANG="de"></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > Betreff: Re: AW: AW: AW: [Devel] Updated geolocation and</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > navigation</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > design document</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > </FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > > Please keep also in mind, that the navigation app itself is</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > somehow</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > > special in regard to their output. Beside provides some UI</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > > to</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > control</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > > its functions like all the other apps (e.g. media player),</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > > the</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > “route</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > > guidance” information is very special. In addition to a</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > > black</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > box</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > > build-in solution for the route guidance - like all the</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > smartphone</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > > Smartphone solutions realizing today – (on prompt the</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > > guidance</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > is</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > > only acoustic or an app-change transition to the navigation</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > > app</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > > appears) we will go a step forward for this driver related</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > > information. The guidance will be presented to the user</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > independent</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > > of the current App in use in foreground. So you can “leave”</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > > the</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > navi-</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > > app but the guidance shall continue. In fact we influence</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > > the</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > > internal design by requesting an agent to be provided by</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > > the</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > app-</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > > developer to deliver these data. And that’s not only an</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > acoustical</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > > prompt, its also data which gets finally a visual</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > representation</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > > (turn icons, lane information, etc). In this approach via</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > > an</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > SDK-</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > API</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > > the rendering gets done by some system service. Its more</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > > like</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > > a</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > > “notification”/“dialog-box”/“status framework” stuff</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > > (please</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > have</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > a</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > > look to the running status framework and the relation to</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > > assist</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > > framework too). So the navigation App provides its data as</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > output</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > to</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > > some SDK-API. In fact part of this is the route list, which</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > finally</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > > land in that guidance dialog. Lets call it assistance</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > > window</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > > –</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > driver</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > > related information.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > I see. The way I would recommend doing this in the design is</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > to</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > implement the guidance UI separately from the navigation UI.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > It</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > could</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > potentially be part of the same application bundle, or part</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > of</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > a</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > different one, or even implemented as part of the system</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > chrome.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > Andre: to be honest, this all is optional. A navi app</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > developer</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > can</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > decide to implement the guidance in its local app-bundle</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > scope.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > Then</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > the UI appears within its own App Screen Area.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > However, since it is beneficial (independent from the POI or</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > Assist</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > Window Discussion) that the guidance portion is separated</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > from</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > the</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > rest of the full-fledge App (because it enables us to handle</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > a</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > separated executable with its own lifecycle, which means we</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > can</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > keep</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > only that part running in background instead of the Full App)</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > we</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > should ask for an Agent for it. The App developer can decide</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > to</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > do</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > so</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > or not. So the requirement for isolating the Guidance into an</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > Agent</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > is already valid w/o all the discussion about POIs and/or</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > Assist</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > Window.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > On top of that we like to also support an assist window</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > solution</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > as</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > part of our system. Therefore we will provide a notification</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > style</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > similar API for driver related information. Guidance data</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > will</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > be</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > covered by it, and if a Navi App developer decided to use</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > this</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > SDK-</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > API, the guidance information will land there (but also</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > information</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > from route list will land in such an assist window). Similar</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > like</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > mentioned above, we like to ask the developer to provide an</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > agent</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > for</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > the guidance data. However, the assist window (the UI for the</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > guidance) is finally a system chrome element and not deployed</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > with</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > the App bundle. It belongs to the OS and gets distributed</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > with</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > it.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > OK, we would have to add a separate SDK API for handling</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > guidance</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > notifications, similar to the existing</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > org.freedesktop.Notifications</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > API for handling other notifications from applications. I will</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > include</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > a recommendation for that in the next update to the document.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > Andre: agreed</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > The guidance UI would take data from the SDK points of</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > interest</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > API,</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > and from the SDK navigation route guidance API (§7.6). This</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > would</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > allow</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > it to render the route (from the guidance API), and points of</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > interest</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > along the way (from the PoI API).</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > The navigation UI (where the driver chooses their destination</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > and</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > plans</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > the route) may retrieve points of interest from the SDK, or</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > may</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > choose</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > not to if the developer thinks they will be distracting.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > i.e. The SDK API you are suggesting for the data from the</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > guidance</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > UI</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > is effectively the points of interest API plus the navigation</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > route</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > guidance API.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > Andre: like said, its not the “points_of_interest” API, its</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > from</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > the</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > route-list API.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > > To this route list, other apps can directly add further</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > > data.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > This</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > is</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > > _not_ forwarded to the navi-app, it does not modify the</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > > route</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > list</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > > nor does it gets stored by the navi-app. The navi app don’t</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > > has</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > any</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > > interest in getting and managing it. This data, gets</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > > provided</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > by</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > the</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > > source app to the rout–list and with that finally rendered</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > > to</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > the</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > > user by some system service (assist window). On the other</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > > hand,</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > other</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > > apps can consume this enriched route list again for their</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > build-</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > in</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > > functions and policies. Its all outside the navigation, the</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > navi</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > only</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > > provides the initial foundation.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > That’s possible due to the split between the navigation UI</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > and</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > the</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > guidance UI. The navigation UI can choose to not query for</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > points</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > of</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > interest, or can heavily filter the PoI requests it makes.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > Conversely,</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > the guidance UI can query for lots of PoIs.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > If other applications want to display something similar to</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > the</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > guidance</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > UI, they must make the same navigation route guidance API and</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > PoI</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > API</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > queries as made by the guidance UI. This should be simple to</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > do,</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > and</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > allows each application to further customise the points of</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > interest</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > they display.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > Andre:</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > to be honest, the use-cases behind that stuff is _not_ that</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > another</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > app will do something similar like the guidance UI.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > Sorry, when I said “if other applications want to display</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > something</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > similar to the guidance UI” I meant something more like “if</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > other</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > applications want to display the current route, or the current</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > route</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > plus nearby POIs”.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > Andre:  I would expect this is build-in behind the scene into</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > libchamplain. So by using libchamplain, Apps get this</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > information</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > already embedded. Similar like they get the current vehicle</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > position</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > (from geoclue) already well embedded into libchamplain. The</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > usecases</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > for Apps to use route list information is the stuff mentioned</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > above.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > Let me repeat to prevent misunderstanding:</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > -  a Weather App may consumes Intermediate Destination</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > Information</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > from Route List to show entries on top of the user stored</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > locations</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > in its UI to inform the User about weather at this places</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > - a gasoline station app adds a refueling stop into the route</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > list</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > for a location to be reached at a time where the car runs low</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > on</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > fuel</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > - a restaurant app may uses information of gasoline stations in</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > the</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > route list to add recommended cafeterias into the route list to</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > align</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > the breaks for the driver</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > - a restaurant app may decides to add restaurant POIs as</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > recommendations into the route list for a location to be</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > reached</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > at</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > a</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > time where a break would be wise</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > - a installed “coupon” app may add available discounts</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > available</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > at</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > a</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > POI location available in route list.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > Other Apps uses information form that API for their essential</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > service, e.g. if an App of a weather service does know</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > intermediate</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > destinations from the route list, it may decides to show</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > entries</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > on</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > top of the stored locations for current destination and</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > intermediate</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > destinations (in todays list you have the current positon for</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > example</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > as a default, this app could extend that approach depending</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > on</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > stuff</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > from the route list).</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > Or if a gasoline station app adds a refueling stop into the</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > route</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > list for a location to be reached at a time where the car</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > runs</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > low</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > on</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > fuel, a restaurant app may uses this information to add</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > recommended</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > cafeterias into the route list to align the breaks for the</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > driver.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > Or if a restaurant app decides to add restaurant POIs as</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > recommendations into the route list for a location to be</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > reached</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > at</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > a</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > time where a break would be wise, a installed “coupon” app</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > may</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > add</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > available discounts available at this location.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > > etc.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > I don’t think I can fully understand these points without</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > agreeing</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > on</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > the terminology at the top of the e-mail.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > Andre:  ok, hope my comments given where helpful in that</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > regard.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > In the current version of the design, these use cases are</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > handled</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > by:</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > >  • The gasoline station application exposes gasoline stations</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > as</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > points</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > of interest via the POI API (<A HREF="https://wiki.apertis.org/Points_of">https://wiki.apertis.org/Points_of</A></FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > _i</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > nt</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > er</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > es</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > t).</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > >  • The restaurant application exposes restaurants as points of</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > interest</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > via the POI API (<A HREF="https://wiki.apertis.org/Points_of_interest">https://wiki.apertis.org/Points_of_interest</A>).</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > >  • The navigation application contains the logic to:</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > >   - Detect where in the route the vehicle is likely to need</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > refuelling,</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > query the POI API (<A HREF="https://wiki.apertis.org/Points_of_interest">https://wiki.apertis.org/Points_of_interest</A>)</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > for</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > gasoline stations, and add them to the route.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > >   - Detect when in the route the driver is likely to need food,</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > query</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > the POI API (<A HREF="https://wiki.apertis.org/Points_of_interest">https://wiki.apertis.org/Points_of_interest</A>) for</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > restaurants, and add them to the route.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > I can’t think of a sensible way of handling coupons at the</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > moment.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > They</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > don’t really fit into any of the existing APIs.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > The design is this way round, rather than allowing the</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > restaurant</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > and</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > gasoline applications to ‘insert’ recommendations into the</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > route</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > list</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > because it leaves the navigation application in charge of which</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > restaurants (for example) are shown. It means the code for</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > determining</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > when is ‘a good time to stop for food’ is in one place (the</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > navigation</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > application) rather than many (each restaurant application),</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > each</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > of</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > which could end up using different definitions of when is ‘a</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > good</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > time</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > to stop for food’ in order to gain competitive advantage.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > Andre: like said above, the design philosophy is an app-centric</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > solution is, to bundle the policy / logic within the provider</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > app.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > So</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > its not one central intelligence, orchestrating all others, its</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > vice</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > versa all the others are providing things accordant to their</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > implemented logic. Apps can compete in providing the same</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > service</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > with another policy or using another service with a similar</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > policy.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > The user decides by choosing the App which fits best his needs.</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > And</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > he can do in the smallest granularity, per App . So he is able</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > to</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > adopt the overall solution by making dedicated decisions per</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > source</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > (App).</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > (Above, I am using ‘navigation application’ to mean the entire</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > navigation application bundle, including any UIs, agents, or</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > services</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > which it provides.)</FONT></SPAN></P>


<P DIR=LTR><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">> > > > Philip</FONT></SPAN><SPAN LANG="de"></SPAN></P>


</BODY>

</HTML>