Inconsistency in FindEvents/CountEvents filter

[Siegfried Gevatter]

Some of our filters (eg., tags, source, content, etc) take an array of different possibilities, but uri does only take a single string; this should be made more consistent (probably making the uri take an array too). Maybe we could even consider accepting everywhere either a single value or an array.

[Siegfried Gevatter (rainct)]

To clarify that last sentence, I mean that both options would be supported (differentiating between them with a hasattr(..., "__iter__") or the like).

[Siegfried Gevatter (rainct)]

Opinions?

[Mikkel Kamstrup Erlandsen (kamstrup)]

My gut instinct says "Require arrays everywhere" in order to make the API more uniform and clear - so that the signature of a filter can be written a{sav} (instead of the weaker a{sv} as now).

[Siegfried Gevatter (rainct)]

Well, stuff like "bookmarked" won't be an array ever.

--
Siegfried-Angel Gevatter Pujals (RainCT)
Ubuntu Developer. Debian Contributor.

[Siegfried Gevatter (rainct)]

Seif wants to use the feature so we decided we will use my way in 0.2.1 (so that we make it available but remain compatible with 0.2) and in 0.3 we will drop the support for using anything other than a list in uri, text, etc.

[Mikkel Kamstrup Erlandsen (kamstrup)]

> Well, stuff like "bookmarked" won't be an array ever.

But wont that info be passed in the annotations in the new API?

[Siegfried Gevatter (rainct)]

> But wont that info be passed in the annotations in the new API?

No, the idea is that "bookmarked: True/False" would still be in the result of FindEvents because it's very basic information. I started describing the idea at http://live.gnome.org/GnomeZeitgeist/EngineAPIRevamp . WDYT?

[Siegfried Gevatter (rainct)]

Ah wait, I'm still sleeping :P:

You're talking about the filter, as in FindEvents([{"uri": [...], "text": [...], "annotations": {"UserTags": [...], "bookmarked": True/False} }])? Yeah that should work.

[Mikkel Kamstrup Erlandsen (kamstrup)]

Actually I am talking about both. I stand by what you describe in comment 8 and I myself in comment 3 and you realize in comment 8 :-).

But the question in comment 6 is about something else.

The bookmarked True/False is also a too weak description. It is not fx. not compatible with the standard hierarchical bookmarks of the Places menu in the Gnome panel. Where ones has folders of bookmarks...

[Siegfried Gevatter (rainct)]

We aren't supporting different types of bookmarks, and thinking about it I don't think we should. That's what tags are for.

[Mikkel Kamstrup Erlandsen (kamstrup)]

Ok, but then I am basically saying that the only possible consumer of the "bookmark" field is the dedicated Zeitgeist UI. This design concerns me a little...

[Siegfried Gevatter (rainct)]

> Ok, but then I am basically saying that the only possible consumer of the "bookmark" field is the dedicated Zeitgeist UI.

I don't agree. Bookmarks are used to mark that an user consider the importance of an item above average. This can then be considered together with frequency of use, associated tags, etc. to choose where and how to display the item.

[Siegfried Gevatter (rainct)]

Anyway, the bug (of not accepting a list for "uri" and "name") has been fixed now; I'm leaving a 0.3 task open so that I don't forget to remove the backwards compatibility in 0.3 (will do once the 0.2.1 tarball is out, so that merging isn't unnecessarily complicated more).

Some more changes we could do for 0.3 (unrelated to this):
 - Rename "name" to "text".
 - Currently tags have an AND condition. We could let the tags filter take a list of lists (instead of just a list) so that everything inside a list has an AND condition but the different lists have an OR condition between each other.

[Seif Lotfy (seif)]

For all i can see countevents is not there anymore. The issues with bookmarks etc is not relevant anymore.