simple search api (was Re: mimetype standardisation by testsets)

[Mikkel Kamstrup Erlandsen]

2006/12/19, Jean-Francois Dockes <jean-francois.dockes at wanadoo.fr>:
>
>
> 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.



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.


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.



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" : [foo at bar.xyz, emfle at birnan.xyz],
    "Mail.To" : ["linus.torvalds at microsoft.com"]
  }
  "email://mail_indetifier2" : {
    "Mail.CC" : [foo at bar.xyz],
    "Mail.To" : ["bill at osdl.org"]
  }
}



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.



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
http://wiki.freedesktop.org/wiki/WasabiSearchLive 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.


Mikkel Kamstrup Erlandsen writes:
> > I just updated the Live api draft at
> > http://wiki.freedesktop.org/wiki/WasabiSearchLive. 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/xdg/attachments/20061220/e4e1eb46/attachment.htm