There are several ways of tackling this issue:
1) Either not log events from specific apps (which is solved now) by disabling
the plugins in the applications
2) Have a little profiler as in a blacklist for home and another for work.
Those could be either actors or subjects. According to the activ
Only the "Tim" usecase in the description of this bugreport can be solved by a
blacklist system.
For the "Tina" usecase we need to find a way to apply filter on already
existing entries in the database to delete them
--
Zeitgeist should have any kind of system to protect users privacy
https://b
Markus - we already have a DeleteEvents() method taking an array of ids.
Just do FindEventIds(templates) and pass them to DeleteEvents. This
makes it easy to do highly advanced event deletion schemes.
As for blacklisting this is really an issue in apps pushing events to
Zeitgeist I think.
--
Zei
@Mikkel, right. So maybe it is just about putting this into an usable
UI. But this is unrelated to this bugreport.
--
Zeitgeist should have any kind of system to protect users privacy
https://bugs.launchpad.net/bugs/447417
You received this bug notification because you are a member of
Zeitgeist-E
I think that Siegfried has an important point. Since we like to relay
events around the system the Zeitgeist core will need a blacklisting
mechanism. There are several steps in such a solution as I see it...
We need a matches_template(event_templ) method on the Event class. This
will be mighty han
>> templates they want to listen for. And then we only notify apps that
>> have registered matching templates.
>
>Is this even possible at all with D-Bus?
Yes. The direct solution is to have clients register some callback
interface. The more elegant approach would be to send directed signals.
Then
See also bug #491646
** Tags added: privacy
--
Zeitgeist should have any kind of system to protect users privacy
https://bugs.launchpad.net/bugs/447417
You received this bug notification because you are a member of
Zeitgeist-Engine, which is the registrant for Zeitgeist Framework.
Status in Zei
Assigning myself to this bug as the blacklisting impl. is very close to
what we already do with the notifications.
My plan is to simply pickle a collection of blacklisting Event-templates
and then filter events on those, almost exactly the same way we notify
monitors.
The plus side here is that w
No the Tina use case can be used also with an external blacklist system. In
whiche she quereis for everything that is "!foo"
2009/11/25 Markus Korn
> @Mikkel, right. So maybe it is just about putting this into an usable
> UI. But this is unrelated to this bugreport.
>
> --
> Zeitgeist should hav
Removing events after their insertion is not the answer, they should
never be inserted at all if they are blacklisted. If they get inserted
they are broadcasted to all listening programs (possibly including
stuff like Teamgeist) so it's too late to delete them.
I'd like to have filtersets defined
There are 2 balcklists.
blacklists that dont allow insertion ito the DB in the first place.
blacklists that dont allow exposure of the events over dbus per default.
The first is no issue and could be implemented instantly, while the second
is a matter of definition. Should the profiling be done on
2009/11/25 Seif Lotfy :
> The first is no issue and could be implemented instantly, while the second
> is a matter of definition. Should the profiling be done on the client side
> or should that be in zeitgeist?
I'd say thats a per-application thing, but I'm not sure I get the use
case for it righ
2009/11/25 Mikkel Kamstrup Erlandsen :
> Then we we should IMHO not just broadcast any old event over the bus. We
> should do some kind of subscription service where apps register event
> templates they want to listen for. And then we only notify apps that
> have registered matching templates.
Is
13 matches
Mail list logo
