Re: Announcing Wasabi - Unifying Desktop Search - feedback needed
- From: "Mikkel Kamstrup Erlandsen" <mikkel kamstrup gmail com>
- To: "Adam Schreiber" <sadam clemson edu>
- Cc: desktop-devel-list gnome org
- Subject: Re: Announcing Wasabi - Unifying Desktop Search - feedback needed
- Date: Wed, 7 Feb 2007 00:39:07 +0100
2007/2/7, Adam Schreiber <
sadam clemson edu>:
On 2/6/07, Mikkel Kamstrup Erlandsen <mikkel kamstrup gmail com> wrote:
> 1) You want your keys (and metadata) *indexed*. This is not a part of the
> Wasabi search spec (currently). I honestly don't know how feasible it is to
> have shared filters/extractors between engines - because that is what you
> would really need to avoid having to code up against the favored service du
> jour. I can only say that from an app developers point of view it would be
> really cool to only have to write on way to index the data.
I think this approach would be my preferred way to implement it.
There would be some kind of standard Wasabi source directory where
different projects could place a .desktop style file (similar to DBus
service publication) that points to their widget that implements the
data source API and indicates what kind of data it provides including
whether or not it should be further aggregated with First Class
Objects(tm) like contacts, music or listed with other documents.
There should probably be a way to install/specify new First Class
Objects(tm) (fields, icon, etc.).
I know for a fact that some people have been talking about .desktop-like files for filters/extractors, but not in a Wasabi context (until now :-D).
I think we should still keep the primary goal of the search spec on how to *do* searches, and not how to get the data there in the first place.
Preferably there wouldn't be any API as such to tell the search engine "index this", but just some .desktop files and libs installed in the proper place.
> 2) You actually want to *store* the keys right inside the service. This can
> fx be done with Tracker right now actually. In a Wasabi scope this would
> rely on the next-on-slate metadata spec+api. In the metadata api you would
> have methods to store metadata on arbitrary "objects".
Would this be a push or pull method of loading data into an indexer?
How easy would it be to tell the indexer there's an updated portion of
data and which set it is?
Cheers,
Mikkel
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]