zeitgeist team mailing list archive

[Markus Korn <thekorn@xxxxxx>]

Please let me explain how I see the whole 'identifier' story:
I don't think we need a identifier which tells us which client set an certain blacklist, simply because the client which sets a blacklist might not be related to the actual purpose of this blacklist, let me give you an example:

A calendar daemon is setting a blacklist for media files played by
MyMusicPlayer every workday's morning. So in the app-naming proposal the
name would look like "calendar-daemon" (and maybe some addiotions of any
kind). IMHO it makes more sense to use the purpose as a first class
object for description, so something like
"MyMusicPlayer.DuringWorkHours".

Also, blacklists are not owned by a certain client (e.g. there is no
client which has exclusive add/removal rights for a special kind of
blacklist). So names which bind a blacklist to the "blacklister"-client
might lead people on the wrong track.

@Seif, this is an interresting usecase, which was never raised so far.
But honstly I'm not a big fan of this idea, basically because it is hard
to do it right. One thing which will always fail is: let's say you have
a blacklist which is *somehow* active for the next 5 minutes. Can this
blacklist be removed once it gets deactivated? What if a client adds an
event with a timestamp in this period later on (e.g. from a history)? -
So potentially we will always get users complaining: "hey I didn't want
zg to log events during XYZ, but there are still events in my log from
during this timeperiod." And we have to tell this user: "well, this
event was inserted afterwards" - So for the sake simplisity we should
move thi kind of blacklisting to the client side.

-- 
You received this bug notification because you are a member of Zeitgeist
Framework Team, which is subscribed to Zeitgeist Framework.
https://bugs.launchpad.net/bugs/612344

Title:
  Blacklist API sucks

Status in NULL Project:
  Triaged
Status in Unity Files Place:
  Triaged
Status in Zeitgeist Framework:
  In Progress

Bug description:
  Guys, GetBlacklist and SetBlacklist (without any signals) for an asynchrounous-by-nature API? Come on!

How about changing it to Get, Add, Remove and a changed signal? That way it'd be actually usable...