<span class="gmail_quote">2006/11/20, Jos van den Oever <<a href="mailto:firstname.lastname@example.org">email@example.com</a>>:</span><br><div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
> > > org.freedesktop.search.simple.query ( in s query, in i<br>> > > offset, in i limit , out as hits ):<br>> > > What is the general consumer of this method? I don't see many. Only<br>> stuff
<br>> > > like deskbar-applet or a general search tool would use it. Maybe adding<br>> a<br>> > > parameter to specify a list of groups the hits should match (or maybe<br>> > > specifying mimetypes). This argument could be "*" or something to get
<br>> all<br>> > > kinds of results. I suggest changing the signature to:<br>> > > query ( in s query, in as groups, in i offset, in i limit , out as hits<br>> )<br>> > Interesting suggestion. It does make things quite a bit more
<br>> > complicated. Because you'd need to define the groups. We've not talked<br>> > about the query language yet ( we need to, but i'm assuming we're<br>> > going to use something similar to what Beagle and Strigi already use,
<br>> > which is almost the same), but you also just expand the query like<br>> > this: "holiday" -> "holiday mimetype:video/*" before sending it to the<br>> > search-engine. That seems much better defined than a list of vaguely
<br>> > termed groups. I do not object to having such names for the user to<br>> > see though.<br>><br>><br>> Yeah, there are a few decisions to make here. How much to put in the query<br>> language and how much to put in the api. I think and expressive query
<br>> language is a good idea. However your example above doesn't fir all cases<br>> well. What If I want to search for all "Documents" containing the word<br>> "parser". The Documents group could fx. be files of mime types:
<br>><br>> application/msword<br>> application/pdf<br>> application/postscript<br>> application/vnd.ms-excel<br>> application/vnd.oasis.opendocument.text<br>> application/vnd.sun.xml.writer<br>> text/plain
<br>> text/html<br>><br>> calling "parser mimetype:application/*" would probably not yield the desired<br>> results. Maybe also having an option to search like "parser group:documents"<br>> would be good? The Spotlight API has the notion of groups like this for
<br>> example.<br>This notion of groups is very valuable for a nice user interface. It<br>is however not relevant for the simplest form of search engine. The<br>group designation of a file is usually not stored directly in the
<br>database, but inferred over the mimetype. For complex groups the query<br>might look something like (application/msword OR application/pdf OR<br>...). Making such a list part of a search API makes it hard to agree<br>
on the mimetypes. I do not oppose a wrapper API the knows about the<br>groups and expands a group-enabled-query, but I dont think we should<br>put this in the simple API. The group(s) to which a file belongs is<br>just another type of (inferred) metadata and i dont think we should
<br>treat is specially.</blockquote><div><br>Given that it would be part of the search language it cannot be ruled out of the simple api, unless we restrict the simple api to only support a subset of the query language (which I don't think is a good idea).
<br><br>It could be introspectable which switches was supported in the language, such as a GetSupportedQuerySwitches(out as), but that doesn't seem to fit in a "simple" api.<br><br>Also what about items that don't have a mimetype as such, conversations, emails, attachment, contacts, etc. How would an application search my Contacts for "Jos"? If this called for an advanced api, that seems strage..?
<br><br>My concern is that we limit the simple api too much to be of any real value.<br><br>Cheers,<br>Mikkel<br></div><br><br></div>