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.). > 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, Adam _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
