<div dir="ltr">2008/10/7 Urho Konttori <span dir="ltr"><<a href="mailto:urho.konttori@nokia.com">urho.konttori@nokia.com</a>></span><br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <br> <div class="Ih2E3d"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> So what remains to be done for a 1.0 release? I propose that we keep<br> it absolutely minimal and only "patch" or work around any problems we<br> can't live with. People uninterested in 1.0 can simply skip on and<br> start the work for 2.0. Here is my list of things that I believe needs<br> a decision for 1.0:<br> <br>  - Live searches. We simply can not fix these without breaking a whole<br> lot of stuff (I believe tracker can handle the current API, but as<br> discussed Lucene based implementations does not have a feasible way to<br> implement this). So the question is - can we do something to make them<br> work minimally or should we scrap live queries from 1.0 altogether? I<br> have some ideas for "patches", but they are better of in another<br> thread.<br>  <br> </blockquote></div> 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).<br> </blockquote><div><br>Glad you proposed this because it was in fact exactly what I had in mind :-)<br><br>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:<br> <br> * SearchChanged(in s search_handle)<br><br>or:<br><br> * SearchChanged(in s search_handle, in as content_categories, in as source_categories)<br> <br></div><div>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.<br> <br>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.<br> <br>Ben? Jos? ((is Ben even subscribed to this list?))<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> 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).</blockquote><div> <br>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. <br></div></div><br> -- <br>Cheers,<br>Mikkel<br> </div>