Mono bindings

[Adam Lofts]

Hi,

On 3/1/06, Joe Shaw <joeshaw at novell.com> wrote:

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


Thanks for reading  them and your 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.


Agreed.

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


Sure, though is it not best to keep the low level wrappers in until an api
which provides all required functionality is reached? The tarball wasn't
intended to be a "release" and is not polished by any standards. Most of my
effort so far has just been getting in all the functionality i require :)

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


It would be trivial to modify the constructor to ImportObject to accept a
Connection and a service name instead of a service. All the service object
really does is to bind a name and a connection. I.e.

public static ImportObject Create (Service service, string target_path, Type
[] ifaces)

would become

public static ImportObject Create (Connection connection, string
service_name, string target_path, Type [] ifaces)

I'm not sure I really understand what you are saying about introspection
data. Do you mean generating new types based on introspection data?

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


Yep,  this is high on the list of priorities.

Adam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/dbus/attachments/20060301/235826e1/attachment-0001.html