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, Mikkel Kamstrup Erlandsen <<a href="mailto:mikkel.kamstrup@gmail.com">mikkel.kamstrup@gmail.com</a>>: > 2006/11/27, Joe Shaw <<a href="mailto:joeshaw@novell.com">joeshaw@novell.com</a>>: > > 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.) > > 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 > > 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. You dont have to define the object in the API. Also having an object is independent of the language. It simply means you have something with a name on the receiving end. E.g. org.freedesktop.search.livequeries/query1. You just define the interface methods. I'll give it a quick shot, but agree with you that the async API should not go into the simple interface. > Do you have any specific idea for a dbus interface? In the search API: method query(in s query, out s queryid) In the livequery API:   signal moreHits(in hit a(sa(sas)))   signal finished()   method closeQuery() (basically what Joe proposed)</blockquote><div> So you think we should use this instead of the current search.simple api? What about applications spawning many searches? Think search-as-you-type, context aware desktop, runtime information clusters... Spawning a dbus object for each query could become a huge task. I must admit I have _no_ idea on how well dbus scales on multiple private connections... I fear the answer is "Untested, and expected to be bad". Anyone? Cheers, Mikkel </div></div>