add a registry for Dataprovider

Bug #462894 reported by Markus Korn
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Zeitgeist Framework
Fix Released
Low
Siegfried Gevatter

Bug Description

It should be possible to
 * enable/disable some dataprovider (esp. useful for testing while developing and debugging)
 * define which dataprovider sends events for which application (right now it is possible to have multiple DP per application, eg. are shipping a firefox logger and on the other hand there is an external FF extension which sends events. This can end in a race between both logger, and logging the same data twice is also not useful)

The preferences should be stored in a user readable format (ini like text file) but also be accessible over DBus.
Maybe this fits into a more general Configuration Interface I started some time ago.

Related branches

Revision history for this message
Seif Lotfy (seif) wrote :

Again redundant since our dataproviders will reside within applications

Changed in zeitgeist:
status: New → Invalid
Revision history for this message
Siegfried Gevatter (rainct) wrote :

Afaik the idea was that there should be a central place where any logger can be disabled. In any case, we still need this for stuff in the datahub (which may do logging from online services in the future, etc).

Changed in zeitgeist:
importance: Undecided → Low
status: Invalid → Confirmed
Revision history for this message
Seif Lotfy (seif) wrote : Re: [Bug 462894] Re: add a registry for Dataprovider

I think this should be done with the blacklist feature i discussed in the
other bug

2009/11/25 Siegfried Gevatter <email address hidden>

> Afaik the idea was that there should be a central place where any logger
> can be disabled. In any case, we still need this for stuff in the
> datahub (which may do logging from online services in the future, etc).
>
> --
> add a registry for Dataprovider
> https://bugs.launchpad.net/bugs/462894
> You received this bug notification because you are subscribed to The
> Zeitgeist Project.
>
> Status in Zeitgeist Framework: Confirmed
>
> Bug description:
> It should be possible to
> * enable/disable some dataprovider (esp. useful for testing while
> developing and debugging)
> * define which dataprovider sends events for which application (right now
> it is possible to have multiple DP per application, eg. are shipping a
> firefox logger and on the other hand there is an external FF extension which
> sends events. This can end in a race between both logger, and logging the
> same data twice is also not useful)
>
> The preferences should be stored in a user readable format (ini like text
> file) but also be accessible over DBus.
> Maybe this fits into a more general Configuration Interface I started some
> time ago.
>
>

Revision history for this message
Markus Korn (thekorn) wrote :

No, this is not related to a blacklist mechanism discussed in bug 447417.
A blacklist system is on a per event basis whereas this bugreport asks for a more global solution to manage dataprovider in general. This is esp. needed when we have a gio dataprovider.

Markus Korn (thekorn)
Changed in zeitgeist:
assignee: nobody → Markus Korn (thekorn)
Markus Korn (thekorn)
Changed in zeitgeist:
status: Confirmed → In Progress
Revision history for this message
Markus Korn (thekorn) wrote :

After discussing this with Mikkel yesterday on IRC I came to the conclusion that this bug is not an urgent one to fix, so I removed myself as assignee.

Changed in zeitgeist:
assignee: Markus Korn (thekorn) → nobody
Seif Lotfy (seif)
Changed in zeitgeist:
assignee: nobody → Laszlo Pandy (laszlok)
Revision history for this message
Siegfried Gevatter (rainct) wrote :

I am working on a datasource_registry.py plugin which will implement this and fix the problem with the GtkRecentlyUsed datasource.

Changed in zeitgeist:
assignee: Laszlo Pandy (laszlok) → Siegfried Gevatter (rainct)
Changed in zeitgeist:
milestone: none → 0.3.3
Changed in zeitgeist:
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.