[Xesam] Xesam 1.0 vs Xesam 2.0

[Mikkel Kamstrup Erlandsen]

Hi all,

I've been pondering the Xesam situation after the hackfest quite a
lot. If you haven't I suggest that you do that before you reply to
this mail because we need to move carefully towards the future.

Since I came home from the hackfest it has become apparent to me that
there are more Xesam 1.0 consumers than I had initially expected. I
don't think it is fair nor good publicity to simply let them down.

The upshot of the below is this: Let's roll 1.0 very (very) soon, with
absolute minimal breaks (or maybe none at all) and then steam on
towards the things discussed at the hackfest for 2.0 as soon as 1.0 is
out the door (or people uninterested in 1.0 can take a head start on
2.0 if they feel inclined).

So here's the reasoning for the above.

Consumers. Besides the major stake holders gathered at the hackfest
there are in fact scattered consumers here and there. From smallish
metadata extractors utilizing only the ontology to Banshee using the
USL and XML query languages. The Recoll author also inquired me
because he had started on Xesam 1.0 support. And quite likely there
are many smaller projects out there utilizing the standard (or more
likely, parts of it) in a way that has just never been announced
anywhere and will never come to our attention.

Time frame. Judging by the recent lack of activity (partly my own
fault) on this list I can not reasonably expect the new spec to be
ready any time soon. At the very minimum I expect half a year to
prepare it and another half year before the software catches up to
feature parity with the current implementations. This is a long time
when we could release 1.0 in a few weeks if we wanted to.

1.0 fulfills its original target which was _desktop_ search. On the
hackfest we talked a lot about embedded devices and protocols for
remote searching.  It is very clear that Xesam <= 1.0 is far from
optimal for these contexts, it is however a workable solution for
workstations, laptops, and netbooks that want a simple search API.

Please do not misunderstand that I *do* believe that what we discussed
at the hackfest is the right way to go, and indeed where Xesam should
be headed in near the future.

Compatibility and lock-in. Some of you have aired concerns that the
world will settle on Xesam 1.0 even if we release it with the promise
of a soon-to-come, incompatible,  2.0. I don't believe that to be
true. There are several reasons for this. The primary being that Xesam
2.0 will simply be *so* much better that people will really want to go
there. Second being that libraries like xesam-glib or xesam-qt can in
fact utilize 2.0 underneath staying API compatible if they plan their
architecture carefully (at least xesam-glib will be able to do this).
This of course requires that Xesam 2.0 is shaping up in a predictable
way before the client libraries finalize their APIs.

So what remains to be done for a 1.0 release? I propose that we keep
it absolutely minimal and only "patch" or work around any problems we
can't live with. People uninterested in 1.0 can simply skip on and
start the work for 2.0. Here is my list of things that I believe needs
a decision for 1.0:

 - Live searches. We simply can not fix these without breaking a whole
lot of stuff (I believe tracker can handle the current API, but as
discussed Lucene based implementations does not have a feasible way to
implement this). So the question is - can we do something to make them
work minimally or should we scrap live queries from 1.0 altogether? I
have some ideas for "patches", but they are better of in another
thread.

 - Paged searching. Do we need this for 1.0? (please don't answer the
question in this thread)

Thanks for hanging in! Let the flames commence :-)

-- 
Cheers,
Mikkel