Wasabi Draft 2
This page is obsolete and not meant for public evaluation, please refer to WasabiAbout.
This is the second draft in the Wasabi project. The first one can be found at WasabiDraft.
The purpose of this draft is to layout some loose guidelines for what needs to be agreed on. Please keep the discussion in overall lines instead of technical details.
Search Language
Some XML based query language. To have something to call it for now let's call it WQXML, Wasabi Query XML. Preferably this should be some known standard. The catch here is that this query language should be suitable for both text querying and metadata querying.
MikkelKamstrupErlandsen: Does any body have some ideas? My only idea is RDF Query, which I'm not particularly fond of. Also it doesn't seems to cover text querying much (term boosting, fuzzy and distance based searches). I think Beagle also uses some internal XML format to handle queries, but I think it is undocumented. Anyone knows anything about this?
FrejSoya: OpenSearch. Origin is rss+web search engines(think amazon,google,yahoo).
MikkelKamstrupErlandsen : Does Google use OpenSearch? At least I know they don't use the auto-discovery part of it. Anyway opensearch is url-encodes all queries and does not specify a query language as such, so it's not really suited for our specific use.
FrejSoya: SRU/SRW. Origin is the world of libraries. SRU/SRW is a redesign of an old search standard z39.50(only used in libraries, based on ASN.1). SRU is the simple way of doing it, SRW the big bloated soap way.
MikkelKamstrupErlandsen: There was a strong consensus on the mailinglist that we needed an xml query language. CQL being a part of SRU/SRW as I understand but seems to sit soemwhere between an and-user language and a more structured language - far to complex for a real end-user language (for desktop use), so it's not good there either. SRW has an xml structure for specifying a request though, which encapsulates both what to match and what metadata to retrieve. Currently all Wasabi proposals have kept the actual-query-to-match and the metadata retrieval separated, but this has always seemed an implicit rule rather than an agreement, so it might be good to discuss this approach actually.
MikkelKamstrupErlandsen : Anyway FrejSoya, have you seen the WasabiQueryLanguage proposal?
Simple Search Language
In addition to the WQXML there is also a simple search language, call this WSQL for sake of the example. This language is tailored toward end users. Any query in WSQL is transformed to WQXML before it is send of to the search engine. All the search engines see is WQXML. There is some functionality in the Wasabi lib/daemon to help applications translate WSQL -> WQXML.
The purpose of the WSQL is to allow applications to utilize the search engines in a dead easy way. Just have a text entry somewhere and, translate the text into WQXML with one call, and dispatch the query with a second.
A music application could add a small tweak to the WSQL before translating to WQXML, fx. add a modifier to restrict searching to audio files.
MikkelKamstrupErlandsen: I would like to propose something like the language sketched out in WasabiDraft as the WSQL.
Search Manager
There is a simple platform independent library of methods for hooking up with the search engine, and an accompanying daemon providing a dbus api to a subset of the library. The methods below marked with DBUS are exported by the wasabi daemon.
DBUS: GetInterfaceProvider (in: s iface_name)
- Return the path for a dbus object implementing the requested dbus interface
[SebastianTrueg]: This is functionality provided by the NEPOMUK backbone library and registry. I would love to see the Wasabi manager be merged into Nepomuk, so the desktop search could become a Nepomuk service. At least we should use a consistent interface. In Nepomuk the call is discoverServiceByType(in: s typeUri)
MikkelKamstrupErlandsen: Cool. I can only embrace this. No matter what Gnomers might say to a C++ implementation (they might not have any problem at all) I think it is a win win situation if Nepomuk registers Wasabi compliant services. Or is Nepomuk really a specification that only happens to be implemented in C++?
DBUS: SimpleQuery (in: s simple_query, out: s query)
- Transform a search string in WSQL to WQXML.
QueryConstructionHelper1 (in: s query)
- Some method to help building WQXML queries
QueryConstructionHelper2 (in: s query)
- Some method to help building WQXML queries
QueryConstructionHelper3 (in: s query)
- Some method to help building WQXML queries
Implementing Wasabi Interfaces
There are two ways to hook up to Wasabi. An application can either implement a dbus interface like fx. org.freedesktop.search.simple defined below, and have wasabi know about it in yet-to-be-defined way.
The second option is to implement a real library with some also-yet-to-be-defined plugin api (yes a real lib - no dbus), and have Wasabi know about that. Request on Wasabi to fx. GetInterfaceProvider ("org.freedesktop.search.simple") would return the object path to the Wasabi daemon and the Wasabi daemon would proxy the dbus calls for the lib.
[SebastianTrueg]: Again, NEPOMUK already provides service registration and discovering. We also have a client library (for now only QT/C++) which provides easy access to the services without any DBUS knowledge.
org.freedesktop.search.simple
There should be a dead simple dbus api for easy application adoption. This api is targeted towards applications where searching is not the primary feature, or search applications having mainly one single entry where the user types a search string in. This api could resemble that found in WasabiDraft.
org.freedesktop.search.full
Full blown search api.
org.freedesktop.metadata.*
MikkelKamstrupErlandsen: This is just to warn people that I think we should define interfaces for metadata handling as well at some point in the future. This does not necessarily have anything to do with desktop indexers.