So, Alex & I have been discussing how to provide Do items & actions over DBus. This is useful because (a) it means other applications can feed us items & actions without needing to also write a Do plugin, and (b) we can move plugins out of the main Do process, which helps with some of the spring cleaning we need to do there.
The main design goal of these proposals is to be able to support the full, current plugin API over dbus. Two non-goals are to clean up the API (although this shouldn't make it harder) or to expose the existing API directly. I expect we'd iteratively migrate plugins from the current Do process into a separate, helper process that allows all existing plugins to continue to work. *Then* we can start API breaking changes, if we need them. :) So, here's an idea for a DBus interface for plugins. The core of the idea is that (a) we can export Items over dbus wholesale and (b) we don't *really* need to call lots of methods on Items. The basic idea is that all Items are found on the bus - each Item (and this includes Actions) is a separate DBus object, with a unique object-path. This gives us a couple of things: 1) We can mandate introspection data, so it's easy to query what interfaces the object supports. 2) It's easy to pass around Items - we can just pass their object paths. 3) It's easy to expose an object on dbus Do's core provides a Register DBus method, which takes the object path of an ItemSource and then grabs the list of object paths of the Items it provides. I'm registering the ItemSource, rather than just having the app call Register on all the Items so that we can easily provide Added and Removed signals for event-driven Universe updates. All Items implement the org.wereawesome.Item interface, which has all the properties we currently have in IItem. When Do core gets a Register message, the core grabs the object path, Name, and Icon properties and constructs its internal representation for searching & relevance & icon caching. Core also grabs a list of the (other) interfaces it supports, so we can filter Actions. When we're looking for acceptable Actions, we've got the list of interfaces they support acting on. For those that support the Item we've got, we send the object path to their SupportsItem method. This should support all the current API. There are some concerns here, though - we'll be pushing a *lot* of objects to dbus and doing a bunch of time-sensitive calls. I'm not entirely sure how much of a performance problem this will be. I don't think it will be. Queries? Comments? Quandries? A little discussion should help flesh things out.
signature.asc
Description: This is a digitally signed message part
