[Wasabi] FOSDEM conclusions - finalizing the search spec

[Mikkel Kamstrup Erlandsen]

2007/3/2, Jos van den Oever <jvdoever at gmail.com>:
>
> 2007/2/28, Mikkel Kamstrup Erlandsen <mikkel.kamstrup at gmail.com>:
> > Calling all desktop search gurus of the known web,
> >
> >
> > We are nearing deadline for the search spec (see
> > http://wiki.freedesktop.org/wiki/WasabiRoadMap),
> > and I have collected a few highlights of my discussions at FOSDEM.
> >
> >  - Generally there where interest in better introspection capabilities
> to
> > have dynamic UIs that adapt to the features of the search engine.
> >
> >  - The ShowSearchTool method in the UI interface was greatly criticized.
> > Should we - or should we not, have it? As a deskbar dev I would like it,
> > since not everybody likes live results, but if deskbar would be the only
> > consumer then I think I could accept life without it :-)
> >
> >  - We need some command line tools to test and help developing the
> backends.
> > I (Mikkel Kamstrup) volunteered to do some in python/glib.
> >
> >  - There was desire to add a way to introspect all indexed field names
> (not
> > all indexers might support the entire metadata spec when it is ready)
> >
> >  - In the end user search spec
> > (http://wiki.freedesktop.org/wiki/WasabiUserSearchLanguage)
> > it should be clarified that you can use words or phrases (with
> modifiers) as
> > values in Selectors. As the spec stands now it is actually there if you
> read
> > carefully, but it can be visualized via the structure drawing as well
> (see
> > the wiki page for new+old version).
> >
> >  - How should we cater for remote search services or searches on remote
> > machines (it is not necessarily the same)?
> >
> >
> > Proposed "diff" to the current API:
> > ----------------------------------------------
> >
> >  - Add a session parameter to the GetQueryExtensions method, so that the
> > signature becomes GetQueryExtensions (in s session, out as extensions)
> since
> > there might be some future query extensions where their availability
> > actually depends on the session state.
> >
> >  - Add a session property that holds the supported Wasabi spec version
> of
> > the backend
> >
> >  - Rename the session properties sort.property.{primary,secondary} to
> > sort.{primary,secondary}.
> >
> >  - Method to inspect the state of the indexer, something like
> GetState(out
> > as state_info), where state_info is an array of two strings - a
> key-value
> > pair. Keys could be IDLE, UPDATING, and FULL_INDEX. The IDLE value
> should be
> > ignored. The value of UPDATING is either the empty string or a string
> > formatted integer denoting how many % the update is done (at 100% you
> should
> > change state to IDLE). The value of FULL_INDEX is the same as UPDATING.
> > IDLE, and UPDATING, should be self explanatory, FULL_INDEX is used when
> the
> > indexer is generating a new index from scratch.
> >
> >  - Add a StateChanged signal with signature StateChanged (in as
> state_info)
> > - see item just above for description of argument.
> >
> >  - Add a GetFieldNames(in s session, out as field_names) method to
> inspect
> > the names of all indexed fields. This is useful for runtime cluster
> > extraction and advanced UIs.
> >
> >
> > Undecided
> > --------------
> >
> >   - Can we control remote searches and other search scoping entirely via
> > session properties? I think we can... I think the Beagle devs are the
> only
> > ones with real experience here though. If we can we can delay the exact
> > specification of those properties a bit.
> >
> >  - Add a method to introspect all supported session properties? In the
> light
> > of the item just above this might make sense.
> >
> I was at the discussions and agree with the above.
>
> Cheers,
> Jos



Unless, someone shouts out, I'll add the above mentioned changes to the spec
tomorrow.

More proposed diffs
--------------------------------
 - Rename the method "NewSession" to just "Session"

 - Define dbus app name, object name, and interface names to be
    - app name: org.freedesktop.wasabi.searcher
    - object name: /org/freedesktop/wasabi/searcher/main
    - interface: org.freedesktop.wasabi.search

Why those names then? I like to call the app/object "searcher", because it's
kinda closer to the Lucene IndexSearcher object naming, and that it has more
of an application feel to it (instead of just ".search").

I add /main to the object path for future extensibility.

interface name - since the wasabi spec compliance level is stored in a
session property we don't need version hinting in the interface name.

Coding
-----------
I'm writing my python based tools (for searching + dummy server), and things
are progressing nicely. My hopes is that they can be used as a toolkit
binding proposal too (api wise).

Code will be up in this week.

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