2006/11/28, Joe Shaw <<a href="mailto:joeshaw@novell.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">joeshaw@novell.com</a>>:<div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> On Tue, 2006-11-28 at 07:15 +0100, Mikkel Kamstrup Erlandsen wrote: > I think everybody wants that (atleast I do). However the idea about > org.freedesktop.search.simple was to have a *simple* interface. Here > the simple only applies to the end user-app developers. Yeah, I can certainly appreciate that. >  1) Targetted at apps where searching is not the main functionality, > fx. a music browser, or filemanager. >  2) There should be no query building on the application end. Just > pass the string as entered by the user to quuery method. >  3) Should be dead easy to drop in your app with only a few lines of > code I agree in principle, but I disagree with point number #2 here.  One reason is that it's generally not a good idea to programmatically build a string query.  They can be error prone but more importantly they're just slow. Take a look at the Beagle backend in Nautilus:         <a href="http://cvs.gnome.org/viewcvs/nautilus/libnautilus-private/nautilus-search-engine-beagle.c?annotate=1.2.2.1" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"> http://cvs.gnome.org/viewcvs/nautilus/libnautilus-private/nautilus-search-engine-beagle.c?annotate=1.2.2.1 </a> (roughly around line 180) The API is still very simple, but we set some important details on the query to limit its scope:         * We only want files; no emails, IM logs, addressbook contacts,         etc.         * We want a maximum of 1000 hits.         * Optionally, we may only want a set of certain MIME types. And we also obviously set the string the user typed in, which is actually a query language string, so they can add more advanced properties, like 'author:"Charles Dickens"'.</blockquote><div> I think I see where the disagreement comes from. Currently the premise for the simple search api has been that it didn't need any language bindings. Applications would certainly wrap the interface in a native object allowing for mainloop integration, but it didn't need any code from the Wasabi project to work.  </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> > The problem is that 2) warrents a simple search language to be defined > to make much sense... 3) is a bit against the nature of your > suggestion. I think the simplicity of the Beagle API belies your assertion on point 3.  Moreover, not making it asynchronous is going to drastically reduce the usefulness in GUI apps.  There are dozens of examples in GNOME alone that show this. </blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Writing responsive GUI apps is Just Hard.  The Beagle API has tried to make this as simple as possible.  You can implement a fully working asynchronous Beagle client that fits in with the GLib main loop in about 100 lines:         <a href="http://cvs.gnome.org/viewcvs/beagle/libbeagle/examples/beagle-search.c?annotate=1.4" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://cvs.gnome.org/viewcvs/beagle/libbeagle/examples/beagle-search.c?annotate=1.4 </a> We could add a synchronous API to this -- which wouldn't have the benefits of Live Queries -- but to still have it work correctly in a GUI app you would have to do all of your searches in a thread.  At least in C, that's definitely harder to do than integrating with the main loop. </blockquote><div> Again such an api needs bindings for the toolkit being used. I'm not against this - actually on the contrary, I just think that we should also have an api that is easy to use even though you don't use the bindings for your platform. I still think it is possible to write a responsive ui with with the paging queries instead of the fully async ones. An application need not request 1000 hits at a time it could send 10 queries requesting the hit ranges n*100 to (n+1)*100 for n=0..9. An example of this is the Tracker search tool and the Tracker deskbar plugin (actually they only perform one query, but still). </div> Another concern I have (that might be based in ignorance) is that a dbus api with lots of temporary objects (queries) might be a lot of work for search engines not having something close to this already. Maybe it is not that hard to keep track of the objects, I really don't have much experience here... <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> A signal driven query response is dead easy to work with when you > Query object is a gobject, but when it is a dbus object matters get (a > little) more tricky. I'm not totally against this idea (signal driven > query response), but I can't see how we could KIS. Recall that the low-level D-Bus APIs are not for application authors, though.  Although most of the bindings aren't quite there yet, app authors should be targetting GLib, QT, Python, Mono, etc. bindings.  And that would map D-Bus signals onto callbacks in the native platform.  I don't think it's a good idea to intentionally cripple an API to work around a (temporary) deficiency in the platform. > Do you have any specific idea for a dbus interface? I don't have anything concrete in mind, but mapping something like the Beagle query APIs onto a D-Bus interface seems like a decent first step.</blockquote><div>  </div>Yeah, I think the libbeagle api is nice to work with I give you that. The ideal situation for me would be a "lowlevel" dbus api that could be used directly or through some bindings for your platform. My intuition however tells me that it might be better with a simple API resembling the currrent proposal and another api to implement platform specific objects on. </div>Cheers, Mikkel