zeitgeist team mailing list archive

[Seif Lotfy <seif@xxxxxxxxx>]

2009/10/8 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.
>

Will take a look at it as soon as i get my ass out of bed.


>
> > 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.
>

This means we will focus on providing a fully flexible API without giving
much though to complexity. Later write wrappers around the API to provide
simpler Interfaces. +1


>
> > 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.
>
>
I do understand why we should keep Teamgeist as a seperate DB. Makes alot of
sense to me and pulling it into our main DB could lead to a big mess. I
really think it should be kept outside our DB but this is just my opinion.
Currently the focus just pushes into the normal DB which is good enough for
me now but it could make the DB huge. I prefer the solution of a seperate
table. Thus the option of generating Application based event tables over the
API should be considerd.


> > 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.
>

Which means we should get it the current API up on running first?


>
> --
> Cheers,
> Mikkel
>
>