| Summary: | python bindings should make fallback paths easy | ||
|---|---|---|---|
| Product: | dbus | Reporter: | Dan Williams <dcbw> |
| Component: | python | Assignee: | Simon McVittie <smcv> |
| Status: | RESOLVED FIXED | QA Contact: | Robert McQueen <robert> |
| Severity: | normal | ||
| Priority: | high | CC: | hp, smcv |
| Version: | unspecified | ||
| Hardware: | x86 (IA32) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
There are plans for this though a bit more integrated. Basically you will be able to register an object which handles trees of objects. For example you can register an object which handles all objects under /org/laptop/objectmanager. You would also be able to insert actual objects into that tree and they will take precedence. I haven't figured out how we are going to present this yet but as soon as 0.80 which is in pre release gets running on OLPC I want to start working on this. From my point of view this is more likely post 0.80, perhaps version 0.81: we need 0.80 out soon since it's the first that works with Python 2.5, so we I think should postpone new features like this. Patch sent for review, will be in 0.82.0. Fixed in 0.82.0. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
In doing some stuff for OLPC, I found I wanted to easily use a fallback path with the python bindings. It's not easy. We've got this "data store", which just is a bunch of objects. The store itself has a few methods, 'get', 'find', 'delete', and 'create'. For example, get(uid) will return the object path of the object with the UID 'uid'. In the service for this (written in python), I don't want to have to make a new instance of the dbus.service.Object method for _every_ object that's in the data store, since many of them would never end up getting requested. Therefore, I'd like to use a fallback path, but with the same ease-of-use as a dbus.service.Object. My solution was to subclass dbus.service.Object, and: 1) Change __init__ as such: def __init__(self, bus_name, fallback_object_path): self._object_path = object_path self._name = bus_name self._bus = bus_name.get_bus() self._connection = self._bus.get_connection() self._connection.register_fallback(fallback_object_path, self._unregister_cb, self._message_cb) 2) Override _message_cb and insert the following before the call to "candidate_method": if parent_method._dbus_pass_message: keywords["dbus_message"] = message Essentially, I want to push the dispatching of the message to my handler functions, since they can figure out what the object UID should be from the object path and do the appropriate thing. Then, I can create my Fallback handler for a whole class of objects like so: class ObjectDBusHelper(dbus_helpers.FallbackObject): def __init__(self, parent, bus_name): self._parent = parent self._bus_name = bus_name dbus_helpers.FallbackObject.__init__(self, bus_name, _DS_OBJECT_OBJECT_PATH) @dbus.service.explicitly_pass_message() @dbus.service.method(_DS_OBJECT_DBUS_INTERFACE, in_signature="a{sv}", out_signature="i") def set(self, prop_dict, dbus_message=None): if not dbus_message: raise RuntimeError("Need the dbus message.") uid = _get_uid_from_op(dbus_message.get_path()) self._parent.set(uid, prop_dict) return 0 I use the explicitly_pass_message() decorator that's meant for the signal handler stuff here too. Note that I'm not entirely sure this all works since I haven't exercised the code completely yet, but the basic idea that dbus.service.Object._message_cb() could also explicitly pass the message would make things a _lot_ easier. Then, I wouldn't have to override it, I would just have to override __init__.