zeitgeist team mailing list archive

[Mikkel Kamstrup Erlandsen <mikkel.kamstrup@xxxxxxxxx>]

Blueprint changed by Mikkel Kamstrup Erlandsen:

Whiteboard changed:
  -----------------------------------------------------------------------------------
  thekorn:
  I don't get why we are talking about this over and over again. When we think we came to a conclusion it is always a matter of time before somebody brings this up *again*. However, IMO this is nothing we should discuss in a blueprint, if the current situation is a problem for user it is a bug, so we should discuss it in a bugreport, and there is already bug 462894 which deals with this problem.
  And if we still think this is an issue, we should try to solve it for all time.
  If we would like to solve it (Mikkel convinced me some time ago that we should go with the current situation) then I see only one valid and possible solution: let certain clients claim exclusive communication (insert and/or query) with the zeitgeist daemon. This exclusive communication is defined by a set of templates and it is not the clients who check if they are allowed to do any kind of communication, it is the engine who does all the management. I started implementing this idea at lp:~thekorn/zeitgeist/exclusive_clients but did not finish it, because I don't think we need it.
  -----------------------------------------------------------------------------------
  Seif: @thekorn
  If we wanna go like that then i would prefer to manually hardcoding blocking our recentlyused manager for the dataproviders which we wrote plugins for.  And creating a dataprovider installer :)
  Cheers
  Seif
+ ----------------------------
+ kamstrup: Going to an exclusive API sounds, excuse me being blunt, completely bonkers. Then we might as well run everything inside the same process and have no dbus API what so ever. Exclusive access to the API defeats the entire purpose of dbus.
+ 
+ There are two ways to solve this. 1) By magical deduplication inside the
+ engine, or 2) by defining this to be purely a configuration issue.
+ 
+ I claim that 1) is utterly impossible to do "right". By inserting some
+ hacks in our current code we might get something that works right *for
+ our very limited use so far*, but solving this problem in general will
+ be a daunting task. Who says that duplicate events from a particularly
+ slow source can't be ½s or even 2s apart?
+ 
+ And I actually think that 2) is not just the only choice, but also the
+ right choice. It is up to the distros to package Zeitgeist in a way so
+ that events are logged consistently. If distros to decide to ship some
+ bad set up there is no amount f magical dupe detection that can save us.
+ 
+ So the question is: How do we solve this 100% inside the dataproviders
+ package? The asiest thing is probably to not emit open/save eevents from
+ the Gedit plugin., Just close.

-- 
Howto handle dataproviders per default.
https://blueprints.edge.launchpad.net/zeitgeist/+spec/handling-dataproviders