Problems with mono bindings

[John (J5) Palmieri]

I can't speak for Joe or Mono specifically but as one of the maintainers
for the Python bindings I do have a couple of comments here.  

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).

Measurably slow or theoretically slow? It is always good to post some
sort of metric.

> - No support for messages without replies / asynchronous communication

Most bindings suffer from this just because the easy case was to write
for blocking I/O and get them useful first.  Should be fairly easy to
add asynchronous I/O.

> - 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 );

This is an interesting point.  It is very hard to do with IPC.  Best way
would probably be to serialize it as an object path and then reconstruct
it on the other side.

> - No access to raw dbus api

In theory bindings should hide all the low level junk and where it is
insufficient they should be fixed.

> Some of the problems above are inherent in the architecture of the
> current bindings - e.g. the whole DBusType namespace implies boxing of
> parameters. Because of this i have experimented with writing another
> mono binding, which is at a state where the basic raw api is (mostly)
> exposed and dynamic objects are created sufficient to call functions
> with no return message (without any boxing of parameters).
> 
> 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?

It is best to fix the current bindings since they are being used by a
number of applications already.  Rewrites should only be done if the
current code base is such as mess that it is unmaintainable and
completely unfixable.

-- 
J5