[Xesam] Xesam 1.0 vs Xesam 2.0

[Urho Konttori]

Hi Mikkel, thanks for the long mail.

> 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.
>   
Fair enough

> 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).
>   
Ok. Let's leave then everything that will suffer ontology change out of 
the 1.0, like messaging, contacts and calendar.

> 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.
>   
Sure. Makes sense.
> 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.
>   
Agreed.

<snip>
>
> 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.
>   
I'd like to minimize the confusion. Switching to the Nepomuk ontology 
for the PIM side in 2.0 is so big change that it would be good to leave 
that side completely out of 1.0.

> 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.
>   
I agree on dropping the live queries for now. How about just adding a 
common signal fw: signal when changes have taken place. Applications can 
then decide whether they need to refresh or not. Message could be 
supplemented with array of categories that have changed. This allows for 
a 'poor mans' live query as if application is listing only images, and a 
new audio has arrived, no refresh needs to be done. Signal should be 
such that it won't be sent for each individual change, but for a series 
of changes if the changes are rapid (as in, importing a lot of stuff, 
e.g. uzipping a big file).

But, for 1.0, I could live even without that. It would just be a very 
simple solution to implement and it would let the applications to be 
aware of any changes happening in the system (and not poll around).

Kind regards,
Urho