ANNOUNCE: Zeitgeist 0.3.0

[Mikkel Kamstrup Erlandsen <mikkel kamstrup gmail com>]

Hi,

On behalf of the Zeitgeist team I am proud to announce our first
development release, Zeitgeist 0.3.0, leading up to what will be our
stable series which will be 0.4. It is our intent to aim for a 1.0
release as soon as we feel good about the stable series, but that is
still a bit in the future. Now that we've crossed the initial hurdle
in the rewrite we expect the release cycle to be much shorter than
this one, although we have not settled on something strict yet.

As many of you know the bulk work on this release was done in the
Zeitgeist hackfest in Bolzano. Since we came back we've been busy little
bees polishing it up and fixing bugs - trying not to flame each others
too much when discussing the designs :-) Working face to face in
Bolzano gave us a unique chance to really discuss things through and
get to the bottom of the details. This will also affect other
developers a bit since...

We were bad boys and decided to change both our internal database
structures as well as our public DBus API. Sorry - but after long
discussions we all agreed that this was for the best. The new design
is leaps and bounds better than the old one. This means that you both
have to give up on your old log database, and accept that there are no
GUI written for the new API just yet. This is being worked on as you
read this though!

Something that might come as a shock to some other developers is that
we decided not to store annotations and bookmarks within Zeitgeist.
This should be done in Tracker or some other semantic metadata
storage[1]. Zeitgeist answers only when and how data was accessed, but
stores no information about the current state of the metadata. We will
be working very closely with Tracker from now on since 0.7 is a
blessed dependency for GNOME 2.30. Congrats to the Tracker Devs.

You can download the release from: https://launchpad.net/zeitgeist/+download

The NEWS entry reads:

First development release leading up to the stable 0.4 series. This
release features:

 - Complete rework of engine and DBus API. Read: apps written against 0.2.*
  will most certainly need an update (see fx.
  http://mail.gnome.org/archives/desktop-devel-list/2009-November/msg00019.html)
 - Public Python client API defined in zeitgeist.datamodel and
  zeitgeist.client modules
 - Documented public API with Sphinx (we'll have an URL for you shortly)
 - Changed Ontology from XESAM to Nepomuk.
 - Removed the Storm backend (obsoleted in 0.2.1).
 - Removed the Querymancer backend.
 - Support for event payloads (binary attachments to events)
 - An extension API for the core engine, allowing extensions direct
access to the DB
  There are already a handful extensions things in the works here,
you will hear
  more about this later

There are a few DISCLAIMERS that needs to be attached to this:

 - The event notification/signals are not yet ready in the new DBus API.
  We expect to have that ready for 0.3.1.
 - We plan to support querying only for available items (eg. filtering out
  deleted files, not listing files on detached USB storage, etc.). However this
  feature is not fully supported yet, even though it is exposed in the API.
 - While we are pretty satisfied with the database layout, there may still be
  changes in the ontologies or concrete data extraction methods. This might
  require that users delete their log databases in order to rebuild them
  with the new definitions. Of course this will no longer happen when we
  go stable
 - Much related to the point above our event ontologies are not yet
set in stone,
  and minor changes are expected
 - We have only one logger enabled for now. Namely the one monitoring your
  recent files. In coming releases this logger may well be deprecated in favour
  of application specific plugins.
 - And finally. Please note that this is a *development release*. We can not
  guarantee stability of services nor APIs, although we strive hard to keep
  things stable.


Cheers,

Mikkel


[1]: There have been talk about defining (and implementing) a very
simple DBus API for storing semantic annotations (bookmarks, tags,
comments, ratings, etc). In our internal speak such a service is
called a Repository. Tracker or Soprano would expose this API in most
cases, but on platforms where they are not available the simple
Repository implementation would be most handy. This being said, it is
currently not a high priority to implement a Repository, there are
alternatives ready in Tracker and Soprano.