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 _______________________________________________ Xesam mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xesam
