2006/11/28, Jos van den Oever <<a href="mailto:jvdoever@gmail.com">jvdoever@gmail.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;"> 2006/11/28, Joe Shaw <<a href="mailto:joeshaw@novell.com">joeshaw@novell.com</a>>: > On Tue, 2006-11-28 at 19:11 +0100, Mikkel Kamstrup Erlandsen wrote: > > 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. > > This is somewhat contrary to the idea behind D-Bus, however.  The entire > idea behind D-Bus is that the low-level libdbus APIs are used by > bindings to integrate with the higher level platform.  Application > developers operate in their language/environment of their choice.  The > API design should keep this principle in mind. Agreed. > > 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). > > I'm not so concerned about the overhead in doing the queries themselves, > although it could become somewhat prohibitive if you're querying massive > amounts of data.  What I'm more worried about is that this is a remote > procedure call to another application.  There's no guarantee that the > server will ever return, let alone in a timely matter.  Your application > might be doing the right thing with paging, but another application may > be hammering or even DoSing the search service. Simple method calls in DBus are not synchronous at all, even though we call them that. A method in DBus simply means that you may expect one reply. The GUI should always deal with a lag in a DBus call and keep the application responsive. Even if the application never returns a result from a DBus method call, this should not handicap the application in any way. If it does, it's a badly/too quickly written application.</blockquote> <div> Let me gauge the current vibes to try an focus on where we are heading. ?1) There is general consensus on forgetting about org.freedesktop.search.simple as it stands and focus on an interface with toolkit bindings only/mainly? ?2) The query as passed over dbus will be XML. ?3) We don't know about any known XML Query language suitable for text index queries. ?4) Any management service/library (and related specs) can (and will) be punted for now. </div> ?5) Given ?1, the api/framework should be easily extensible to accommodate a metadata service  framework. I would also like to use this opportunity to link to the only two search frameworks that I know have native bindings:  Beagle: <a href="http://kubasik.net/beagledocs/libbeagle/">http://kubasik.net/beagledocs/libbeagle/</a>  Spotlight: <a href="http://developer.apple.com/documentation/Carbon/Conceptual/SpotlightQuery/index.html"> http://developer.apple.com/documentation/Carbon/Conceptual/SpotlightQuery/index.html</a> Cheers, Mikkel </div>