[Xesam] Xesam 1.0 Live Searches. Was: "Xesam 1.0 vs Xesam 2.0"

[Mikkel Kamstrup Erlandsen]

2008/10/7 Urho Konttori <urho.konttori at nokia.com>

>
>  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).
>

Glad you proposed this because it was in fact exactly what I had in mind :-)

So concretely: Remove the signals HitsModified and HitsRemoved and add in
stead a signal. Also scrap the search.live property, but add a read only
vendor.search.live property defining whether or not the SearchChanged signal
will be used:

 * SearchChanged(in s search_handle)

or:

 * SearchChanged(in s search_handle, in as content_categories, in as
source_categories)

The SearchChanged signal may be emitted *any* time during the search and
means that search_handle is invalid from that point on (and reading hits
from it should return a dbus error). This way Lucene implementations does
not have to lock down their index reader for undefined lengths of time.

During heavy indexing a Lucene impl could buffer file changes for 0.2s (or
do more fancy intelligent bufferring) or so before emitting a SearchChanged
on all open handles. This should still leave the engine fairly usable by
clients.

Ben? Jos? ((is Ben even subscribed to this list?))

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).


If something along the lines of the above is feasible I think we should keep
it in. If it turns out to be too problematic I think we can scrap live
searches entirely to not drag the 1.0 release date.

-- 
Cheers,
Mikkel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/xesam/attachments/20081007/afc4439d/attachment.html