I just wanna toss this idea out in the wild.<br><br>I want to make it easy to have multiple services expose a xesam search interface. We would still have the standard desktop search engine with the dbus path and name as specified, but other implementations of the search interface could be useful too. Consider fx if Gnome's Mugshot applet (
<a href="http://mugshot.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://mugshot.org</a>) exposed a xesam search service that could search in mugshot groups, feeds, and persons. This would not be suitable as an integrated part of the main desktop search service. Another example could be a xesam wrapper for the Yahoo REST api.
<br><br>This way we could (at some point in the future) have a small "swarm" of xesam search services (likely with the desktop one as the most prominent), and applications like deskbar could aggregate these in a a nice search-everything-you-can-dream-of-and-then-some applications.
<br><br>We can achieve this with almost no changes to the current search proposal. What we basically need is some way to introspect what ontologies the search engine is capable of using, and we probably need that anyway.<br>
<br>What I actually propose is this: Add a session property vendor.ontologies that has value type aas, an array of ontology definitions which are triplets [unique_name,version,path]. So fx hooking up to the Yahoo service and calling GetProperty(session, "
vendor.ontologies") returns [["yahoo", "1.0", "/usr/share/ontologies/yahoo-1.0"]].<br><br>If the main xesam desktop search service had a 3rd party onto installed it might return [["xesam", "
1.0", "/usr/share/ontologies/xesam-1.0], ["my-app", "0.3.4", "/usr/share/ontologies/my-app-0.3.4]].<br><br>What do you guys say? Cheers,<br>Mikkel<br><br>