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@lists.apertis.org] Im Auftrag von Simon McVittie Gesendet: Donnerstag, 11. Februar 2016 16:47 An: devel@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.