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>:
> >
> >
> > 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?
>
> Considering the complexity and inter-relatedness of everything (as
> well as this semantic event logging being vastly unexplored territory)
> our only option is to do small iterative improvements to the API and
> see what works. I whole heartedly think that we spend out time best by
> sketching mockup APIs and then try to implement it when we agree - but
> we should accept that we wont get it right in the first few attempts.
>
> Gnome has too many badly designed APIs, we shouldn't let Zeitgeist
> become another one of those - even if there is a lot of time pressure
> on us.
>
> --
> Cheers,
> Mikkel
>
> Ok all this is fine for me. I think the time pressure is on us from the
fact that we got a Zeitgeist hackfest sponsored by GNOME and they do want to
see results. I think it is a better idea to discuss until we settle on a
implementation for each point in the blueprints. However it would be also
good to set a deadline for us to settle for something just to keep the flow
going. It is ok to improve the API bit by bit however I am concerned about:
*How much it is going to get broken? Do we need migration scripts? *All I
know there should not be any DB changes except for removing the unused
column "end" in the event table.
Also I would like to know Jason and Youness's opinion on the DB issue as in
having the teamgeist database behind the Zeitgeist one. I for one see the
plus side iin it but i think we coudl do that in another iteration not in
0.3 so -1 for me.

After looking at your proposal for the Annotations I am very convinced, yet
I wonder how would and "insert" look like. If this is also solved I see no
problem for me and Siegfried to finish the implementation of the feature,
unless API concerning this issue (event/item/annotation) should be
rediscussed. This would allow Markus to repair the Dataproviders and we are
off and a blue print is settled.

I think for the 0.3 release we can just cram the focus events in a new table
since we are the only ones allowing access to it over an API. So if you all
agree on that then we just need some API specs on how to use it in the data
relevancy and I will also have to clean it up.

Let us focus on those 2 points now if possible.
Cheers
Seif