I’ve added methods for parsing D-BUS Introspection Data.

Now you can get informations about available interfaces, methods, signals and properties with the nsIDBusInterface object.

In order to test my methods I wrote an dbus-viwer clone in XUL : http://trac.csquad.org/browser/trunk/examples/dbus-viewer

Here is a screencast (1 Mo) where you can see dbus-viewer in action.

Here is my current progress on that project :

• Signals are supported, you can send en receive signals
• Introspection XML data is now parsed by my component
• I’ve wrote an dbus-viewer clone in XUL
• I’ve integrated Threads

But I did not release a 0.1 version because my wrapper produce a dead lock :
If you listen for a signal and call a remote method, you program get locked.
This is a common usage of D-BUS and I think that I can’t release my work without it.

This problem is caused by libdbus witch is not threads “aware” and because I don’t have a shared
lock between my threads.

Havoc Pennington explained me howto solve this issue : integrate libdbus inside my mainloop as glib as done :

GLIB Mainloop integration

This integration is hard because D-BUS is using UNIX file handle and NSPR does not provide functions to handle it.

I did not expect so many technical difficulties, but I stay motivated.
I continue to work on my project (after the end of the summer of code) and I will release version 0.1 as soon as the dead lock issue is solved.

This week I was focused on documentation :

• I’ve started the initial draft of the DBuzilla Tutorial, the goal of this document is to quickly explain howto use the API. I’am inspred by Matthew Johnson’s “Using the DBUS C API” article, which I found very clear.
• Updated the API Class diagram.
• Setup LXR for API reference.
• Update the Wiki.

I’ve made progress in the wrapper code :

• Mixed array are now supported : Array(1, ’string’, 2.3)
• Threads are now wrapped.
• Callback are now handled, but not fully : It’s working for the XPCOM part but D-BUS does not call my handle back.

I will release version 0.1 when I find an issue to the callback problems. (I’d like to see asynchronous call and signals managed by 0.1).

Here is my current progress on my project :

    ret = iface.callWithArguments("MethodName", ['arg1', 42, 43.1], 3)

// var arg = new Array(1, 'string', 2.3) // does not work yet
var arg = new Array(1, 2, 3)
ret = iface.callWithArguments("MethodName", [arg], 1)

try {
   ret = iface.call("SomethingGoesWrong")
} catch (e) {
   e.name // error name, ex: org.freedesktop.DBus.Python.dbus.exceptions.UnknownMethodException
   e.message // error details, ex: SomethingGoesWrong is not a valid method of interface...
}

I continue to work on :

• callback and signals
• documentation

I will release version 0.1 next week. ]]> http://www.csquad.org/2006/07/10/d-bus-for-mozilla-project-progress-3/feed/ 2 http://www.csquad.org/2006/07/02/d-bus-for-mozilla-project-progress-2/ http://www.csquad.org/2006/07/02/d-bus-for-mozilla-project-progress-2/#comments Sun, 02 Jul 2006 19:17:09 +0000 cscm http://www.csquad.org/?p=40

Another point on my progress on the D-BUS for Mozilla projet.
Now I’am able to return any basic type form D-BUS method call and I’ve started to work on returning Arrays and Dictionaries.
The next step before the release of version 0.1 (full featured D-BUS client) will be :

• Method Arguments handling
• Error handling with exception

I’ve planned this release in two weeks, soon ! ;0)

var comp = Components.classes[nsDBUSContactID];
var dbus = comp.createInstance();
var session = dbus.SessionBus();
var iface = session.FindInterface('org.mozilla.TestService', '/',  'org.mozilla.TestInterface')
var ret = iface.Call('Hello')
dump('return value = ' . ret )

The ‘ret’ value can be of any kind of type (string, int, array, object, etc…).
I’ve found the javascript code for managing any type of return value from an XPCOM method, in the mozilla xml-rpc extension :

/* Create an instance of the given ContractID, with given interface */
function createInstance(contractId, intf) {
    return Components.classes[contractId].createInstance(Components.interfaces[intf])
}

/* return type */
function testReturn(type) {
    const SUPPORTSID = '@mozilla.org/supports-';
    var ret
    switch(type) {
        case 'INT32':
            ret = createInstance(SUPPORTSID + 'PRInt32;1',
                'nsISupportsPRInt32')
            ret.data = 65
            break
        case 'STRING':
            ret = createInstance(SUPPORTSID + 'cstring;1',
                'nsISupportsCString')
            ret.data = 'arf'
            break
        case 'DOUBLE':
            ret = createInstance(SUPPORTSID + 'double;1',
                'nsISupportsDouble')
            ret.data = 2.4
            break
       ....
    }
    return ret;
}

I’ve wrote the C++ version of this code, but It does not work :
XPIDL prototype of my method :

nsISupports Test();

The C++ implementation :

NS_IMETHODIMP
nsDBusImpl::TestSupports(nsISupports **_retval) {
    nsresult rv;
    nsCOMPtr ret =
        do_CreateInstance("@mozilla.org/supports-PRInt32;1", &rv);
    if (NS_FAILED(rv)) {
        return rv;
    }
    ret->SetData(42);
    // _retval = (nsISupports **) &ret; // Does not work
    // *_retval = ret;  // Segfault

    return NS_OK;
}

I’am stopped by this problem …

• Trac – http://trac.csquad.org/
• Subversion Repository – http://svn.csquad.org/dbuzilla/