Hi, On 11/2/07, Denis Washington <[EMAIL PROTECTED]> wrote: > Why not use the xesam spec? We could just have one generic GNOME search > tool that sends xesam queries and presents the search results, > regardless of which search engine gave them us. This would require a > xesam interface for basic file search, but that shouldn't be much of a > problem.
I don't think anyone is in disagreement, but this is easier said than done. Beagle, for instance, doesn't use D-Bus for its standard IPC, so it's not just a matter of implementing an additional D-Bus interface. There are some largely historical and now irrelevant reasons for this, but it's not a trivial endeavour. Also, I think there is a warranted apprehension among the desktop search developers as to whether implementing a largely untested spec is a good idea. It's not really any different than the situation that comes up whenever anyone wants to add API to GTK+. That is, people won't use the API until it's in GTK, but you don't want to add (and freeze) an API in GTK if it's essentially unused and untested. For GTK, libegg has been a reasonable solution to this problem. For Beagle, that was the idea behind first implementing Xesam as an adaptor rather than entirely ripping out our existing IPC mechanism. Part of the problem is that we need more manpower. We need someone (or more than one person) to implement a Xesam-based client application that is not designed with any one search system in mind. Porting the existing abstracted backends in GTK+ and Nautilus would also be a worthwhile task. Only with those clients in combination with the various search services that implement Xesam will we really know how well it works in practice. So get to work. ;) [1] Joe [1] FOCUS you BABOON! [2] [2] http://mail.gnome.org/archives/gnome-list/1998-November/msg00294.html _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list