Comment 24 for bug 612344

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.