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

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.

  Blacklist API sucks

Status in NULL Project:
Status in Unity Files Place:
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...

Mailing list:
Post to     :
Unsubscribe :
More help   :

Reply via email to