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

[Mikkel Kamstrup Erlandsen]

2006/11/19, Jos van den Oever <jvdoever at gmail.com>:
>
> 2006/11/19, Mikkel Kamstrup Erlandsen <mikkel.kamstrup at gmail.com>:
>
> > org.freedesktop.search.simple.countHits ( in s query , out
> > i count ):
> >  Why is this necesary. Is it to accomodate use cases such as suggestion
> > popups like below[1], and reduce the dbus wire traffic for multiple
> calls?
> Not just that, it is also required for paging ( page 1, page 2, etc)
> and lines like 'Found X hits.'


Ah, ofcourse :-)

> Type text in entry: net
> > Get a popup with:
> >             net   (7801)
> >             network (6578)
> >             netto (17)
> No, this is another case. Here you see numbers for each keyword, but
> where do you get the keywords from? For something like that you'd need
> a call like:
> expandWord(in s word, out a(si) wordlist)


Well, it could be based on an expandQuery() method, but applications could
also list old searches with hit counts. Ie. in the above example I would
have searched for net, network and netto at some point in the past. There
are numerous ways to obtain suggestions...

> org.freedesktop.search.simple.query ( in s query, in i
> > offset, in i limit , out as hits ):
> >  What is the general consumer of this method? I don't see many. Only
> stuff
> > like deskbar-applet or a general search tool would use it. Maybe adding
> a
> > parameter to specify a list of groups the hits should match (or maybe
> > specifying mimetypes). This argument could be "*" or something to get
> all
> > kinds of results. I suggest changing the signature to:
> > query ( in s query, in as groups, in i offset, in i limit , out as hits
> )
> Interesting suggestion. It does make things quite a bit more
> complicated. Because you'd need to define the groups. We've not talked
> about the query language yet ( we need to, but i'm assuming we're
> going to use something similar to what Beagle and Strigi already use,
> which is almost the same), but you also just expand the query like
> this: "holiday" -> "holiday mimetype:video/*" before sending it to the
> search-engine. That seems much better defined than a list of vaguely
> termed groups. I do not object to having such names for the user to
> see though.


Yeah,  there are a few decisions to make here.  How much to put in the query
language and how much to put in the api. I think and expressive query
language is a good idea. However your example above doesn't fir all cases
well. What If I want to search for all "Documents" containing the word
"parser". The Documents group could fx. be files of mime types:

application/msword
application/pdf
application/postscript
application/vnd.ms-excel
application/vnd.oasis.opendocument.text
application/vnd.sun.xml.writer
text/plain
text/html

calling "parser mimetype:application/*" would probably not yield the desired
results. Maybe also having an option to search like "parser group:documents"
would be good? The Spotlight API has the notion of groups like this for
example.

> How about live queries? Maybe that should be supported in another
> interface
> > than the simple one.
> Yes it should. Maybe we should try to get this running first. Live
> queries are rather tricky.


Yeah, simple queries a definitely to priority right now. It is important
that we don't forget the bigger picture when designing the interface though,
so we need to take future work into consideration.

> org.freedesktop.search.simple.getProperties ( in as
> > files,in a(sa(sas)) properties ):
> >  This seems good. It is a bit toward a metadata interface, but I think
> it is
> > good here to so apps don't need tons interfaces to work with. At some
> point
> > it there should be a specification on how to name and format these
> > properties/metadata.
> Small correction, it should be:
> org.freedesktop.search.simple.getProperties ( in as files,in a(sa{sas}) )
> where one can argue about whether or not to send back the filename
> again. It's not needed, but also does not take much bandwidth.


Agreed.


Cheers,
Mikkel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/xdg/attachments/20061120/80424871/attachment.htm