2006/11/27, Joe Shaw <<a href="mailto:joeshaw@novell.com">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;"> Hi, On Mon, 2006-11-27 at 12:12 +0100, Jos van den Oever wrote: > > > Exactly. And having live queries is similar to this. > > > > > > I'm not the best person to propose an asynchronous language because > > > Strigi has only synchronous queries at the moment. If there's a good > > > API, i might change that according to that API. > > > > Exposing the API over DBUS makes your queries async for free (only those > > requested over dbus ofcourse :-) ).  Any dbus call has an async and a > > blocking version, so clients can do what ever they want. > > Yes, my point was defining a request that returns the results in > packets instead of only one reply. This has the advantage the the gui > can show results pretty quickly even if the query is slow. In Beagle, all searches are inherently asynchronous.  The client sends a query request, and a variety of signals are sent back.  HitsAdded, HitsSubtracted, and Finished are the main ones.  As long as the connection to the daemon stays open, events can keep being sent to the client.  Hence, live queries. I would suggest a similar setup using unique D-Bus object paths for a standardized API.  (A synchronous API will be pretty darn slow for large queries, I'm afraid.)</blockquote><div> 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.  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 </div> The plan was that when we had a simple interface we would move on and define a more advanced one for people with the need for this. 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. 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. Do you have any specific idea for a dbus interface? Cheers, Mikkel </div>