Fwd: Problems with mono bindings

[Adam Lofts]

Forgot the list.

---------- Forwarded message ----------
From: Adam Lofts <adam.lofts at gmail.com>
Date: Mon, 28 Mar 2005 19:25:08 +0100
Subject: Re: Problems with mono bindings
To: Joe Shaw <joeshaw at novell.com>


On Mon, 28 Mar 2005 12:24:04 -0500, Joe Shaw <joeshaw at novell.com> wrote:
> 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.

Yeah, I sortof agree with you here - boxing is pretty fast and i dont
think this is actually what the problem is. Basically, I looked at the
current bindings (and hated the indentation style) and decided I would
write some bindings without boxing - i enjoyed it so much that i took
the bindings quite a long way. System.Reflection.Emit is pretty cool.

[Ok, so this might piss you off a bit given i essentially duplicated
the work you've already done]

>
> > - 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?

I meant the low level api, but i think i was wrong here.

>
> 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?

I think so, can that change be made ?- i think its important that a
dbus interface actually represents an interface. How much are the
bindings api locked now applications are starting to use them?

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

I'll post the code soon so you can have a look.

Thanks,
Adam

>
> Joe
>
>