2006/11/24, Fabrice Colin <<a href="mailto:fabrice.colin@gmail.com">fabrice.colin@gmail.com</a>>:<div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> On 11/24/06, Mikkel Kamstrup Erlandsen <<a href="mailto:mikkel.kamstrup@gmail.com">mikkel.kamstrup@gmail.com</a>> wrote: > 2006/11/23, Fabrice Colin <<a href="mailto:fabrice.colin@gmail.com">fabrice.colin@gmail.com </a>>: > > What Magnus suggests may be useful for document 'sources' or 'groups' (for > > lack of a better name), eg "Documents", "Applications", "Contacts", > > "Conversations" etc... -as offered by some existing personal search > systems- > > which may or may not map to individual indexes (that mapping being > irrelevant). > > That was exactly what I meant to cover with the "group" switch. Fx. the > query "fabrice group:contacts" would return you. Searching without a > specified group would return matches from all groups. Perhaps the wiki is a > bit unclear here... > The Wiki is clear enough. It's just that it may be useful to provide the consumer application with a list of supported groups... unless we dictate which groups should be supported by all engines.</blockquote><div> Well, my idea was to come up with a spec at some point in the mid-term future (after the simple api is complete). On top of that the spec should of course be extensible so that backends can have custom groups - which implies the need for a method to do runtime introspection. I just don't think the belongs in a simple search api.  </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> > Well, AFAIK, dbus allows complex structures like arrays or dictionaries. > > Yeah, but that really only accounts as collections of simple data types in > my book. What I meant was just that you can't have Query object, like fx > Lucene does, and pass that over the wire. Not in a desktop neutral way at > least - or please correct me if I'm wrong! :-) > Hmmm it depends on. As the dbus specification says, you can have "array of array of array of ... struct of struct of struct of ...", which is probably flexible enough to pass all the data held by a Query object.</blockquote><div> Yeah, we can hold the data of a query object, but you can't assign any methods to it (unless you export it over dbus (which I don't think is a good idea)). Methods to construct a query programmatically would have to reside in a toolkit-dependent lib I think.  </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> Right you are. I was a bit wasted last night when I  answered Magnus (sorry) > - I just thought her deserved an answer sooner rather than later. > No worries ;-) > The question is then if this info should be stored in  the manager daemon or > the search engine. As I consider it more or less a design goal that the > daemon (or lib or what ever we end up with), should be expendable, I don't > think such info should lie with the managing object. Also if this info would > reside with the managing object that would also mean each query should go > through the managing interface, and I don't think I'm totally hooked on that > idea. > > To avoid code duplication we could develop a small lib or other dbus service > to *optionally* handle these issues. I'm reluctant to impose any dependency > on the implementing engines. > We could have an optional prefix (a switch-type, according to the draft) for language, so that this information is carried by the query string. A braindead example : if the engine supports "language", "the moose language:english" is interpreted as a query for "moose", while "the moose language:swedish" is a query for moose tea :-)</blockquote><div> I think that is a good idea. Default to having the backend deal with all this and have a switch to override the runtime stemming. Cheers, Mikkel </div> </div>