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