Method interface, is it not complete, how to put async callback?

[funky12]

Hi

Browsing to the code, it looks like Method interface is not complete. In ur code u have implemented
Method('exampleMethod', arguments='s', returns='s' )
So it takes arguments and returns only...
But the original package is

http://dbus.freedesktop.org/doc/dbus-python/api/dbus.decorators-module.html

We have decorators which takes many additional param.
For example I need async_callback to be added and I would implement what would happen if the remote call lead to error.
In normal python package, I do

<
@method(MY_INTFACE, in_signature='', out_signature='', async_callbacks=('async_cb', 'async_eb'))
def DoSomething(self, async_cb, async_eb):
"""Do Something"""
d = self.remote.doSomething()
return self.add_callbacks(d, async_cb, async_eb)
/>

How can I achieve similar thing in tx_dbus.

class MyObj (objects.DBusObject):

iface = DBusInterface('org.example.MyIFace',
                      Method('exampleMethod', arguments='s', returns='s' )) --> Here I cant add async_callback param which I can pass 

[Tom Cocagne]

Txdbus was designed from scratch to provide a good async interface to the
DBus protocol. I made no effort to mimic the python-dbus interface so there
are bound to be wide divergences in how the two interfaces are used. Just
looking at the API may be a bit misleading though and the real question is
whether or not txdbus is missing functionality. What can you do with
python-dbus that is either inconvenient or unachievable with txdbus?

On Sat, Jun 20, 2015 at 5:54 PM, funky12 [e-mail] wrote:

Hi

Browsing to the code, it looks like Method interface is not complete. In
ur code u have implemented
Method('exampleMethod', arguments='s', returns='s' )
So it takes arguments and returns only...
But the original package is

method(dbus_interface, in_signature=None, out_signature=None,
async_callbacks=None, sender_keyword=None, path_keyword=None,
destination_keyword=None, message_keyword=None, connection_keyword=None,
byte_arrays=False, rel_path_keyword=None, **kwargs)
source code
Factory for decorators used to mark methods of a dbus.service.Object to be
exported on the D-Bus.

The decorated method will be exported over D-Bus as the method of the same
name on the given D-Bus interface.

Parameters:
dbus_interface (str) - Name of a D-Bus interface
in_signature (str or None) - If not None, the signature of the method
parameters in the usual D-Bus notation
out_signature (str or None) - If not None, the signature of the return
value in the usual D-Bus notation
async_callbacks (tuple containing (str,str), or None) - If None (default)
the decorated method is expected to return values matching the
out_signature as usual, or raise an exception on error. If not None, the
following applies:

async_callbacks contains the names of two keyword arguments to the
decorated function, which will be used to provide a success callback and an
error callback (in that order).

When the decorated method is called via the D-Bus, its normal return value
will be ignored; instead, a pair of callbacks are passed as keyword
arguments, and the decorated method is expected to arrange for one of them
to be called.

On success the success callback must be called, passing the results of
this method as positional parameters in the format given by the
out_signature.

On error the decorated method may either raise an exception before it
returns, or arrange for the error callback to be called with an Exception
instance as parameter.

—
Reply to this email directly or view it on GitHub
#31.

[Tom Cocagne]

Funky12, my apologies for not actually answering your question. The latter half of your text was somehow cut off from the e-mail notification I received and I only now saw the rest of it via the Github web page.

If you haven't already, take a look at the "Explicit Interface Specification" section from the txdbus documentation: http://pythonhosted.org/txdbus/

The line you reference where "Method('exampleMethod'...)" is called is simply defining the signature of the DBus method. You actually invoke the remote method via "proxy_obj.callRemote("exampleMethod"...)". The callRemote() method will return a Twisted Deferred to the eventual results of the call and the addCallback/addErrback methods on the deferred instance are what you're looking for. A good handle on Deferreds is essential for the use of Twisted so you'll want to brush up on that documentation if you're fuzzy on the details.

Sorry for the miscommunication. Let me know if I can help further.