simple search api (was Re: mimetype standardisation by testsets)
Jos van den Oever
jvdoever at gmail.com
Mon Nov 27 21:39:15 EET 2006
2006/11/27, Joe Shaw <joeshaw at novell.com>:
> Sorry, I am just now catching up on this thread, I'm a little behind.
I'm glad you're joining. The users are getting the upper hand and
saying things like:
>> Again, some backends will have native caching capabilities, others
won't. I think we should focus on keeping the interface easy to use
for application developers, and leave the headaches to the search
engine devs... Sorry guys :-)
> On Sun, 2006-11-19 at 12:19 +0100, Jos van den Oever wrote:
> > method countHits ( in s query , out i count )
> > Count the number of instances of a file that match a particular query.
> > Input:
> > query
> > The query being performed.
> > Output:
> > count
> > The number of documents that match the query.
> Throughout this you use the term "file". I presume that you mean more
> than just files (like emails, for instance). Can the spec be updated to
> reflect this?
I certainly main URI, yes.
> > method getProperties ( in as files,in a(sa(sas)) properties )
> > Get properties for the given files.
> > Input:
> > files
> > A list of files for which properties should be returned.
> > properties
> > The properties belonging to each file. Each property is a name
> > associated with a list of string values. The index of each property
> > map in the list corresponds to the index of the filename in the list
> > of files.
> This method will be pretty inefficient in Beagle, as each file will
> require a query to the index. We could maybe cache these, but it seems
> to be that it would be more useful to instead have two query methods:
> one which returned only a list of URIs and one which returned URIs and
> document properties.
I'm fine with an additional query function. I avoided this in the
first place because the return message would become rather big. How
method queryDetailed ( in s query, in i offset, in i limit , out
a(sa(sas)) hits )
Perform a query and return a list of URIs that match the query.
The query being performed.
The offset in the result list for the first returned result.
The maximum number of results that should be returned.
A list if URIs with properties that are the result of the query.
How about adding the matching text fragment? This should also be a
a(sas) because the hits may occur in different fields.
More information about the xdg