Desktop Search Hackfest

Contents

Event description

[COMPLETE]

Hackfest around the Desktop Search and Metadata handling topic. Currently there are many partial solutions to the problem, so a hackfest could help to share some code, define lines to the projects and steal the good points of other projects :P

Proposed dates

  • After maemo submit (September 18-19th + weekend)

Participants

  • Name (Project / Location)
  • Jos van den Oever (Strigi)
  • Jamie McCracken (Tracker)
  • Sebastian Trueg (Nepomuk) (Jos recomended - hasn't confirmed)
  • Kevin Ottens (KDE Plasma search) (Jos recomended - hasn't confirmed)
  • Martyn Russel (Tracker/UK)
  • Carlos Garnacho (Tracker/Spain)
  • Philip van Hoof (Tracker/Belgium)
  • Urho Konttori (Tracker/Finland)
  • Ivan Frade (Tracker/Finland)
  • Mikael Ottela (Tracker/Finland)
  • Mikkel Kamstrup (XESAM/Denmark?)

Proposed items to work

Concrete Coding Tasks

  • Xesam integration in file chooser and Nautilus. Possibly use xesam-glib
  • Create language bindings for xesam-glib (specifically Vala, C#, and Python) for xesam-glib and use these achieve
    • a deskbar module
    • a Gnome Do add-in
  • Create/draft a xesam-gtk library with widgets empowered by xesam-glib
  • Create a small server that exposes the Xesam search engine over Avahi (probably over http). This is correlated with the second point under BOFs.

BOF Sessions

  • There are several metadata-heavy technologies emerging. Soylent, People, Online Desktop/Desktop Data Model, Xesam, and others. Can we somehow work more together? They all appear to take slightly different approaches.
  • Xesam over alternative protocols. Keywords: http/REST, Avahi, Bluetooth, XMLRPC, Soap, Plain ol' socket.
  • How can we integrate pervasive searching capabilities in the current Gnome desktop (ie. without changing the desktop interaction model)
  • How can we create a whole new user interface based on metadata and instant searches. Ie possibly breaking totally with the standard interaction model of the desktop. One possible starting point:
    • I've been sketching a "do-what-I-think-desktop" a while back. The basic premise is "the user should not need to even touch the computer. It should just do the expected/desired in all circumstances without user interaction". Then see how far we can go with statistical analysis of historic user actions and rich metadata - and then accept that we can not achieve the end goal, but still get as close as possible.
  • A shared way to harvest metadata and register metadata extractors or sources. This is also relevant for Xesam.
  • Discuss the Xesam Metadata Storage spec. It is slated to be included in the post 1.0 release of Xesam, but there is very little concrete written down or agreed upon. This can seriously use a lot of discussion. It has ramifications into Soylent and desktop-data-model as well, probably others too.
  • Gnome and Nepomuk? Hitherto Gnome and Nepomuk has not really been related at all. Even though Xesam and Nepomuk has its disagreements we are also trying to collaborate. Should Gnome do more, what steps would be necessary to utilize Nepomuk technologies in Gnome?
  • Semantic Gnome?
  • Dashboard? Why has the idea that everybody loved never landed on consumer desktops? How can we make it real. What technical solutions do we need in place?
  • While it is pretty hype to talk about desktop search and even write lots of code for it, why is it not more integrated in the desktop than it is? A big reason is of course the quality of the search engine. I can think of a lot of other reasons though (feel the teaser!).

Meta

  • It would be great to have RC3 of the Xesam Search spec ready at least a week or two ahead of this. It is likely to contain some (minor) API-breaks. Probably an updated xesam-glib to go with it too.
  • Given an updated Xesam spec it would be great to have all servers updated to the latest spec and have easy-to-set-up trunks or branches. The point is that a hack fest should not be spent with everybody trying to set up a privately circulated branch of MyGreatSearchEngine.