zeitgeist team mailing list archive

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

2009/11/19 Jason Smith <jason.smith@xxxxxxxxxxxxx>:
> Zeitgeist Developers,
>
> There is an amazing amount of activity surrounding the happenings of
> Zeitgeist. Lots of excitement going on and obviously Zeitgeist will
> continue to be an important part of the linux experience in the coming
> years. Zeitgeist has not been without issues, there have been two major
> ones I can think of.
>
> - The API is too complex
> - The information quality is fairly low without lots of item providers
>
> The API issue has been largely addressed with the 0.3 release and I hope
> the API can be stabilized almost completely at this point. The
> information quality issue has also received considerable attention,
> however I believe more can be done.

I think you are right about this, and it is basically also what we
agreed on in the hackfest.

About the Zeitgeist API I actually think the new API is pretty sound
(at least InsertEvent, GetEvent, and FindEventIds - we have not worked
a lot on the last parts of the API). Just yesterday we landed a branch
of mine adding a client lib (in Python for now) on top of the DBus
interface. I think that it makes it pretty much as easy as it gets
(modulo the fact that there are no sync methods in the API, only
async; synchronous methods are made of evil).

When we have some more experience with the client API in Python I'll
start on a client lib in C/GObject. It is my hope that I can line it
up with the inclusion of GVariant+GDBus in GLib, but I don't intend to
block on it if the inclusion drags out.

> In short I believe the problem with Zeitgeist is it works largely at the
> application level. Getting individual applications to provide
> information to Zeitgeist, or watching applications through wnck.
> Instead, I believe a lot more can be achieved at the toolkit level with
> a relatively small patch (or perhaps set of patches) to GIO and
> libgnome-desktop.

Indeed! I am glad you bring this up. I have been wanting to go down
that route myself for a while - like hooking into GtkRecentManager
etc. I have not looked much into it because we have been busy
finalizing the API though.

> By patching these parts of the toolkit, we can be notified easily of
> every file the user intentionally opens, every applications they launch,
> every process they use, quickly and efficiently with very little code. I
> have attached a GIO patch that adds a new extension point into GIO that
> allows a loadable GIO Module to track all launches of .desktop files.
> This patch is early and should be considered beta quality, however it
> provides the needed interface to begin writing a GIO module that will be
> extremely useful to Zeitgeist. I have also included a skeleton (and very
> quickly written) GIO module that essentially does nothing using this
> extension point.
>
> I believe there to be good reason to look into getting this patch
> upstreamed, and I believe it can be done in a reasonable time frame. The
> benefit to Zeitgeist really could be amazing.

I had a quick look at the patch and it looks pretty solid. I have not
found the time to take it for a test spin though.

I think it could be a good idea to write down a list of things we want
to hook into in the lower levels to find out just how much hacking we
need done to get to Zeitgeist nirvana. Off the top of my head I can't
come up with anything more than app launching and GtkRecentManager,
but it needs some more thought[1]. Then there are application level
plugins off course, we track those on
https://blueprints.launchpad.net/zeitgeist/+spec/zeitgeist-external-dataproviders.

-- 
Cheers,
Mikkel

[1]: I am wary of hooking directly into GIO to track all IO ops  as we
might get too much "noise" here, although it would be wicked to track
all file operations that was done through Nautilus (and any other GIO
based file manager for that matter).