[Devel] Updated geolocation and navigation design document

Barkowski Andre (CM-CI1/PRM1) Andre.Barkowski at de.bosch.com
Thu Feb 11 15:57:45 GMT 2016


Hi Simon,
thx for the details, and fully agree with your comments. Looking forward to your conclusion / recommendation, which design to use

Rgds
Andre


-----Ursprüngliche Nachricht-----
Von: Devel [mailto:devel-bounces at lists.apertis.org] Im Auftrag von Simon McVittie
Gesendet: Donnerstag, 11. Februar 2016 16:47
An: devel at lists.apertis.org
Betreff: Re: [Devel] Updated geolocation and navigation design document

On 11/02/16 15:09, Barkowski Andre (CM-CI1/PRM1) wrote:
> We have the following implementation possibilities
> 
> 1.dbus
> 2.library
> 
> Functionallywisethese are identical.Build inalgorithms foraggregationare
> same.
> 
> #1 adds some more complexity in regard beingan entire d-bus service
> 
> #1 would have less peer-to-peer traffic than#2 and so would perform
> better on systems where a lot ofappsare providing and consuming POI data
> 
> on systems wherethis isn’t the case, design #2 would have lower overheads.

I don't think this is necessarily true: if we're sending a very large
number of PoI, putting them over an out-of-band peer-to-peer connection
is likely to be "cheaper" than sending them over D-Bus, so which one is
lower-overhead depends on how the number of consumers compares with the
overhead of using D-Bus.

If we aren't sending a large number of PoI, then the performance isn't
very relevant in any case.

> We can also distinguish between having a library as frontend foreasy
> usage byApps and a dbus service behind the scene – somehow similar like
> libfolks.

Tracker is an example of the design you're thinking of here, but
libfolks isn't. Tracker looks something like this:

           | D-Bus  |             | D-Bus |
provider 1 ---->--\ |             |       | (client
provider 2 ---->--+--> aggregator --->----- library) -->-- consumer
provider 3 ---->--/ |             |       |
           |        |             |       |

but libfolks is just a library: if a provider is in a different process
(like evolution-data-server or BlueZ), then the process that uses
libfolks is communicating directly with each provider:

         D-Bus or similar
provider 1 | -->--\    |
provider 2 | -->--+--> | (library) -->-- consumer
provider 3 | -->--/    |

(Vertical lines indicate a boundary between processes, i.e. somewhere
that we can put security restrictions).

> we
> had this discussion also in past that dbus access can be restricted more
> easy than library. We may would like to restrict Accessfor Apps how don’t
> need it (privacy).

In a library-only design (like libfolks), we'd apply the restriction at
the boundary between provider processes and the consumer process.

In a design with an aggregator (like Tracker), we can apply the
restriction at the boundary between the aggregator and the consumer. If
we wanted different consumers to be restricted differently, that would
have to be done by code in the aggregator.

-- 
Simon McVittie
Collabora Ltd. <http://www.collabora.com/>

_______________________________________________
Devel mailing list
Devel at lists.apertis.org
https://lists.apertis.org/listinfo/devel


More information about the Devel mailing list