2006/12/19, Jean-Francois Dockes <<a href="mailto:jean-francois.dockes@wanadoo.fr">jean-francois.dockes@wanadoo.fr</a>>:<div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> By the way, I had a go at implementing the simple api, just to get myself better acquainted with dbus. I still think that a trivial interface may be useful. The current one makes things unnecessarily complicated in my opinion. </blockquote><div> Agreed. Most places where you fire of a query an expect to more or less done with it probably wants the simple api. Apps that use a more smart-folder like functionality want the live api.  </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Especially, returning the initial result as a sequence of uris (presumably ordered by relevance), and then using them as keys to retrieve properties is very awkward on the server side (forces maintaining a map from uris to result entries). I think it would be much simpler to have a single call like: Query (in s query, in i offset, in i limit, in as properties, out aa{ss} hits) where 'properties' is the list of requested properties, and 'hits' is an array of property (name,value) maps, one for each result entry.</blockquote><div> I think you are quite right. Except that maybe the output parameter of simple.Query should be a{sa{sas}} - a map mapping uris to maps of property-valuelist pairs. The trick is that metadata fields can have several values (like the simple.GetProperties method). If I request the Email.CC and Email.To fields for example I'd get something like {   "email://mail_indetifier1" : {     "Mail.CC" : [<a href="mailto:foo@bar.xyz">foo@bar.xyz</a>, <a href="mailto:emfle@birnan.xyz">emfle@birnan.xyz</a>],     "Mail.To" : ["<a href="mailto:linus.torvalds@microsoft.com">linus.torvalds@microsoft.com</a>"]   }   "email://mail_indetifier2" : {     "Mail.CC" : [<a href="mailto:foo@bar.xyz">foo@bar.xyz</a>],     "Mail.To" : ["<a href="mailto:bill@osdl.org">bill@osdl.org</a>"]   } }    </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Uri and snippet are just two properties among others. I can't see any point in having separate GetProperties() and GetSnippets(), and the list of uris that the current Query() currently returns is mostly useless. The current GetProperties() and GetSnippets() calls can be emulated by separate Query() calls requesting adequate property lists if someone really likes them. I think that this approach is simpler both on the server and application sides.</blockquote><div> The GetSnippet method must have a query string to match up against - GetProperties do only need an uri and a list of requested props. Arguable they could both be merged into Query, but I feel it might be overkill issuing a separate query to retrieve given metadata fields on a given uri - that is more like a lookup in my mind (and also is for some engines). You can't merge GetSnippet into you main query it is a relatively slow operation on most engines, so you have to do that after you got the actual hit. These was the reasons why I split the methods like I did and I still think they hold... Cheers, Mikkel PS: Given the latest update to <a href="http://wiki.freedesktop.org/wiki/WasabiSearchLive">http://wiki.freedesktop.org/wiki/WasabiSearchLive</a> it might be better to rename simple.GetProperties to simple.GetMetadata to be consistent. the live interface has getters and setters for properties on the actual Session and Query objects. </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Mikkel Kamstrup Erlandsen writes: > I just updated the Live api draft at > <a href="http://wiki.freedesktop.org/wiki/WasabiSearchLive">http://wiki.freedesktop.org/wiki/WasabiSearchLive</a>. Please have a look and > comment here or on the wiki. > > About libbeagle "compatibility": > I think that the suggested api is equivalent with libbeagle (in the sense > that they can implement each other). Atleast regarding the searching aspects > of the operations - the libbeagle api seems tailored towards communicating > with the beagle daemon (which makes perfect sense), but many of the > abstractions does not make sense as such in dbus centered search api... > > Cheers, > Mikkel </blockquote></div>