Jamie McCracken (jamiemcc) wrote,
Jamie McCracken

Semantic desktop - piece of a jigsaw

Benjamin makes some interesting comments here which I would like to address

The semantic desktop, as implemented by tracker, cannot glean all useful semantic information by indexing alone. This is why there is a separate storage daemon (trackler-store) which apps can use to supply additional semantic info. However even that is not enough to realise its full potential.

So what is needed?

For me, a service orientated architecture (SOA) is needed for objects like contacts, music, images etc. This would span all local objects - eg your locally set up contacts, objects on remote machines (EG contacts on corporate address books like an LDAP server) and of course web service contacts (myspace, facebook etc). An SOA would require a federated database and the obvious candidate for that is tracker

I would also suggest that SOA implemetations be freedesktop based so all desktops can use them and allow KDE/GNOME to replace EDS and Akonadi for a common contact SOA

SOAs would also provide methods for importing/exporting contacts to various services as well as unifying all contacts under one umbrella.

SOAs can go a long way to eliminating duplicated code between desktops and competing applications. In one rosy future, all applications will end up being thin clients with their bulk of their function in SOAa and their data in tracker. Apps could then be created which use any platform (QT/GTK/NBTK/PYGTK/GTK#) with minimal of code. Dont like the UI or the toolkit? No problem, just rewrite it in super quick time

The biggest problem of course is not coding it but getting everyone to tango - it would require a monumental freedesktop effort that would need to overcome all the politics and factions. That sadly means it might not ever happen however...

One of the reasons Im more excited by a desktop variant of Moblin than say Gnome 3 stuff, is that I will be able to implement a tracker based SOA for it as it already comntains SOA stuff like mojito. I do envy the mobile folks as they have the power to forge their own mini desktop environment but who knows. One day soon you may well see a moblin desktop variant where semantic desktops and SOAs will power it.

  • Post a new comment


    default userpic

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.



July 23 2009, 22:26:26 UTC 12 years ago

But this is already happening - albeit still locally - with more and more stuff beeing exposed through dbus right?
When you say "allow KDE/GNOME to replace EDS and Akonadi for a common contact SOA", it appears that you see Akonadi as "KDE's version of EDS", whereas it's been designed from day one for cross desktop use. Allow me to explain that.

In envisioning a "rosy future", you describe today's implementation the Akonadi design. A small, type independent cache service surrounded by agents providing access to the files and online services needed. Standard protocols accessed by toolkit specific client libraries. Shared, higher level model/view components using those to build applications out of.

At KDE, all our mail, contact, calendar, feed APIs are being ported to use it, and adding other item types is trivial. For GNOME to join the fun, we just need a glib client library.

You're right in recognising the major obstacle is politics and NIH. The Akonadi team has had difficulty in getting the freedesktop.org admins to provide hosting, making it easy to mistake Akonadi for a KDE only project. We hope that the recent recognition that fd.o needs to change will improve future interaction.

Ideally there would be a single daemon that does all that and use tracker as storage (at least as an option as tracker is freedesktop too and not gnome specific)

It will indeed be worth looking at.
We discussed exactly this Akonadi+Tracker tandem configuration at Akademy - it's a configuration which could make a lot of sense on platforms where you want to minimise the total number of processes, and one that can easily be expanded with eg remote resources for sync as needed.

Storing as in "instead of using files like .vcf", shouldn't be a problem, basically either an Akonadi Resource talking to Tracker or Tracker acting as one.

Storing as in "transiently cache data stored remotely", might be a bit more difficult, depending on what facilities are available to store large quantities of data and/or having different locations for storing small and large "parts".

For Nepomuk we are currently "forwarding" respective data passing through Akonadi to allow it being used in queries.
IIRC there have been ideas about directly sharing the storage layer, but I can't remember any details
Less abstract debates, more code!

And what about People project?