2007/2/7, Adam Schreiber <[EMAIL PROTECTED]>:
On 2/6/07, Mikkel Kamstrup Erlandsen <[EMAIL PROTECTED]> 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?
This would be pushing data into the metadata storage. Much like the Metadata API of Tracker http://svn.gnome.org/viewcvs/tracker/trunk/data/tracker-introspect.xml?view=markup Cheers, Mikkel
_______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
