Comments inline... On Sun, Mar 28, 2010 at 6:12 AM, Christopher James Halse Rogers < [email protected]> wrote:
> 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. > Just to expand on this for anyone on this list who's not part of the day-to-day do loop.. The most excellent part of this is implicit desktop integration, instead of having an explicit twitter plugin, applications like Gwibber[0] could build in Do integration and supply us with a "Microblog" action, or even a series of actions for each service supported like "Post to Twitter", "Post to Facebook", "Post to Identi.ca", etc. This means a much more tightly integrated Do, because plugin developers don't need to update their plugins for application updates, applications handle it! That said we will keep the idea of stand-alone plugins, so someone who doesn't use/have gwibber installed would still be able to use the Twitter plugin for Do+Twitter. 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. > Chris had mentioned just getting rid of some plugins. I think it might be good to have a plugin review day where we move some of the unloved and unmaintained plugins into an orphanage where they can wait for someone to come and love 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. > So let me make sure I understand what you're saying.. We ask an ItemSource what interfaces the items it contains supports, and core saves this list. Then when we're filtering items for actions we know what itemsources we need to search through, and can skip the ones that don't contain any items of the supported type. Do you see this being done explicitly with a SupportedItemTypes method, or do you think we can do this implicitly with introspection data? It would be very nice if this could be done implicitly with introspection data in the following way: When an ItemSource calls Register we run through its list of items and query each one to find out what interfaces it implements. We build a list in the internal representation, and when an ItemAdded or ItemRemoved signal comes in, we check its implemented interfaces and possibly update our internal list. > 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. > I like it! I think the asyncronous nature of d-bus will make the speed issue moot, if we can call SupportsItem with a callback rather than blocking we can just keep firing it and taking the callbacks as they come in. SInce we're updating the interface anyway we can make the list nicer for a asyncronous results- but that's another discussion. If no one has any issues with this, then let's get to work! There's a long road ahead but the end results will be a really compelling Do 2. [0] http://www.launchpad.net/gwibber -- --Alex Launi -- You received this message because you are subscribed to the Google Groups "GNOME Do" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/gnome-do?hl=en.
