Problems with mono bindings

[Joe Shaw]

Hi Adam,

On Sat, 2005-03-26 at 23:51 +0000, Adam Lofts wrote:
> - The bindings are too slow. All types are boxed and unboxed during
> transmission (although i don't think this is the only problem).

In the grand scheme of things I have my doubts that the boxing and
unboxing of types is a significant performance hit.  That said, any
profiling information will help.

> - No support for messages without replies / asynchronous communication

I think this would be pretty easy to add by tagging the method with an
attribute of some kind, and implementing the wrapped methods in
Method.cs (and some of the glue in ProxyBuilder.cs).

> - Inability to use remote objects at method parameters on the client side. eg
> 
> object my_obj = Service.Get ( connection, "my.interface" );
> my_obj.Method ( my_obj );

How would you do this in C?  I think you'd use the object path.  Having
not looked at it in detail I suspect that it'd be fairly straightforward
to check to see if the object being passed in is a dbus object and
serialize it to an object path

> - No access to raw dbus api

Do you mean the raw network API, or the low-level C API?

The purpose of the bindings is to provide functionality to the
applications without needing the raw dbus C API.  If there is
functionality missing in the bindings then lets get it in there.

If you mean talking the core dbus protocol, that's a possibility but I
don't think it buys us that much considering the virtual ubiquity of the
C bindings and the ease of binding the CLR to C.  (Unlike Java, where
you'd have to deal with JNI and a lot of pain.)

> - https://bugs.freedesktop.org/show_bug.cgi?id=2153

The fix for this might be as simple as looking up an existing proxy
class and using that, or using a GUID to uniquely identify the created
proxy assemblies.  I think I tried both of those things and they worked
for me, but I haven't tested it extensively.

> - InterfaceAttribute is defined on an object type, not an interface type.

This should be a one-line change, no?

> If i carry keep working on my bindings (and they prove to be faster),
> would they be accepted into dbus? Would they require an identical API?
> Would i offend anyone in the process?

I'm wary of doing a wholesale replacement of the bindings at this point.
A number of projects are starting to make use of them.  And any new
bindings are likely to have similar bugs to the old bindings that took a
long time to shake out: lifecycle issues with delegates passed into
unmanaged code, disposing of managed classes because the GC doesn't know
how big the underlying unmanaged class is, etc.

There are a lot of weaknesses in the current bindings: the DBusType
stuff as you said is a little awkward; the boundaries between classes is
a little difficult to deal with, partly because of object lifecycles;
some probably don't make sense anymore (ie, Service); some object types
aren't well supported (dicts aren't supported at all, for example; the
object path one you brought up is another).

Certainly if you have started work on another binding I'd love to see
the code.  I have no problem with improving the current binding or even
refactoring huge chunks of it, but I don't think that throwing away what
we've got and starting from scratch is the best approach here.

Joe