news 28 Posted December 1, 2009 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. _______________________________________________ Share this post Link to post
