zeitgeist team mailing list archive

[Mikkel Kamstrup Erlandsen <mikkel.kamstrup@xxxxxxxxx>]

2009/10/8 Seif Lotfy <seif@xxxxxxxxx>:
> SNIP
> ... Let us start with current open blueprints for a 0.3 release:
>
> How we describe events (separating events and items): I think we are dealing
> here with the the biggest issue. The separation was our best decision yet
> allowing more new flexibility. However the current split put us in front of
> the annotation implementation issue. Markus and Mikkel had the best 2
> proposals so far. Mikkel's being more powerful but duplicative while
> Markus's being more straight forward. Once this issue is done we can
> actually move forward better. Since we will be working on a new simple API I
> think we should just go with the more powerful. After this is done we are
> still facing a migration script :(.

I updated my proposal on
http://live.gnome.org/GnomeZeitgeist/EngineAPIRevamp#Annotations to be
more in line with Markus' proposal. The prime change over Markus'
proposal is that I've harmonized the returned collections to all be
dicts keyed by URI.

> Revamped DBus API: This is a very important point. Our current API is really
> flexible and powerful but very very complex. However right now, Teamgeist,
> Docky, Shell and stuff me and Markus hack have to deal with this complexity.
> We all agreed on providing a more flexible API as well as a new simple one
> for little purposes. Where things like annotations are left out until
> requested, etc...

As I also mentioned in a private chat with Seif, my take on this is
that a simple DBus API should not be our core concern. We should
strive to design an API that is flexible and designed for optimum
performance. It is my experience on designing the Xesam API a while
back that striving for a simple DBus API only leads to trouble (that
said; coherency of the API is still paramount). We should expect
wrapper libs to provide a clean and nice API for app developers. Once
the API has settled I'll start writing a GObject client lib in C.

> Aggregating document focus over window focus: I think the this
> implementation is almost complete in a branch as a separate Dataprovider. I
> am just standing infront of the decision to either to push those focus
> events in a new table, or DB, or just push them into the normal events
> table. This feature will allow us to determine how long a document was
> focused providing features such as "Most active documents" as well help out
> later with the data relevancy graphs.

Reading http://wiki.zeitgeist-project.com/Teamgeist#Database I see
that you are not the only one wanting to split out a "private"
database. This hints to me that there is a general need for a way to
split out databases/logs based on the origin/type of the logger. I
will try and think something up on this - having both TeamGeist and
the focus-tracker maintain private or custom dbs inside (or outside)
Zeitgeist just seems like a bad idea architecture wise. Disparate DBs
also feeds the proliferation of "application private data silos" which
we have been fighting for years now. My feeling is that we should have
an API for creating new custom logs, much like you can easily create
new databases in CouchDB.

> Symbollic Access of the Data Model: This feature is not a big deal and I
> could finish tomorrow or so. It is pretty straight forward and I will rely
> on the Nepomuk ontology for it. It will allow us to have a unified
> communication with other projects such as Tracker. It will keep our DB clean
> and not full of random crapola.
>
> Events RDF Ontology: This is the least of my concerns and I think it could
> be done within a week of devotion. Mikkel should take the lead on that :)

The two points above are tightly coupled. I would love to help out
here. This whole deal also ties heavily into the API and event data
structuring.

-- 
Cheers,
Mikkel