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

[Mikkel Kamstrup Erlandsen]

2006/11/24, Fabrice Colin <fabrice.colin at gmail.com>:
>
> On 11/24/06, Mikkel Kamstrup Erlandsen <mikkel.kamstrup at gmail.com> wrote:
> > 2006/11/23, Fabrice Colin <fabrice.colin at gmail.com>:
> > > 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.



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.


> > 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.



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.


> 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 :-)



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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/xdg/attachments/20061124/9635aa9e/attachment.htm