Blueprint changed by Mikkel Kamstrup Erlandsen:

Whiteboard changed:
  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 
  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 :)
+ ----------------------------
+ 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.

Mailing list:
Post to     :
Unsubscribe :
More help   :

Reply via email to