Mono bindings

[Joe Shaw]

Hi,

On Wed, 2006-03-01 at 16:05 +0000, Adam Lofts wrote:
> I have recently revived my old mono bindings in order to create a
> telepathy [1]  client in C#. The bindings haven't been tested very
> much except with this. They do support some features the old bindings
> did not (arrays, structs, out parameters) and work with current dbus.
> Joe Shaw [2] seemed to imply that this alone is enough for them to
> supersede the old bindings. 
> 
> If so, then the bindings split seems a handy time to integrate them.
> This message is basically just to let people know that these bindings
> are available and a snapshot can be found here [3]. 

These bindings are definitely a lot cleaner than the old ones, so here
are my comments:

        * Your bindings use the glib main loop, which I think is good
        and should be provided since a lot of the applications that are
        going to use dbus-sharp will be gtk-sharp apps.  But I think
        it's also important to provide your own main loop integration,
        probably by handling the dbus connection in a separate thread.
        Obviously this isn't a showstopper, but it's something that
        tends to get set aside.
        
        * You seem to provide a lot of the low-level APIs.  A binding
        shouldn't wrap most of that stuff; it should provide a nice,
        high level API.  Providing wrappers for things like additional
        dbus connections is nice, but that should be something that
        probably should be added later.
        
        * You provide the concept of a "Service".  This may be because I
        felt in the past that compatibility with the old bindings (which
        provided a Service) was important, but I don't really thing it
        is anymore[1].  Dbus has long since dropped the service metaphor
        and simply calls them "names" now, which merely identify the
        application to other apps on the bus.  It doesn't make sense to
        "register" objects with the "service" anymore.  I think it makes
        a lot more sense to set up filter functions behind the scenes in
        the bindings and pull out all the possible objects by using
        custom attributes and introspection.  That way registration
        becomes unnecessary.
        
        * There's no memory management right now.  Doing memory
        management of C objects from C# is a real pain.  Partly this is
        due to a lack of tools, but partly it's because it's just plain
        hard, even in C.  Trust me on this one: you really, really want
        to address this issue up front by making all of your objects
        which wrap C structures IDisposable and make sure you clean up
        after them.  Don't wait until you have the binding mostly
        finished and then go back and add them.

Yes, it's a long list but I don't want you to get discouraged by this.
The Java bindings might be a decent place to look at to get a starting
point because the languages and runtimes are so similar.

[1] Most of the C# apps that seem to be using dbus are using it
primarily for remote control interfaces as far as I can tell, or for
getting some simple info out of HAL.  Use just isn't that widespread.
Given the state of bitrot in the current bindings, although a year ago I
probably said that maintaining the current API is important, now I feel
like getting it right is more important.

Joe