More comments inline. On Sun, 2010-03-28 at 10:54 -0400, Alex Launi wrote: > 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. Mostly right. We can actually just figure out what interfaces an Item supports from its introspection data, so unless that turns out to be significant performance problem I'd say we'd just do that.
> 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. We still want Universe searching to be pretty much instantaneous, so I was thinking that Core would still maintain a Universe of all the items/actions it knows about with enough information to do the input-based searching and (non-dynamic) filtering. The dynamic SupportsItem call will still have to be... dynamic, but we can do a lot of filtering in core. > > 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: I think on my first read-through of this mail I got this bit wrong, so I'll put down what I think you mean more explicitly. Actions have an explicit SupportedItemTypes method/property (probably a property, really), which core queries on register and stores. > > 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. Exactly. We can easily work out from the introspection data what interfaces an Item supports. > > 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 gnome-do > [email protected]. > For more options, visit this group at > http://groups.google.com/group/gnome-do?hl=en.
signature.asc
Description: This is a digitally signed message part
