Hi,<br><br><div><span class="gmail_quote">On 3/1/06, <b class="gmail_sendername">Joe Shaw</b> <<a href="mailto:joeshaw@novell.com">joeshaw@novell.com</a>> wrote:</span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
These bindings are definitely a lot cleaner than the old ones, so here<br>are my comments:</blockquote><div><br>Thanks for reading them and your comments. <br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
* Your bindings use the glib main loop, which I think is good<br> and should be provided since a lot of the applications that are<br> going to use dbus-sharp will be gtk-sharp apps. But I think<br> it's also important to provide your own main loop integration,
<br> probably by handling the dbus connection in a separate thread.<br> Obviously this isn't a showstopper, but it's something that<br> tends to get set aside.</blockquote><div><br>Agreed. <br></div><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> * You seem to provide a lot of the low-level APIs. A binding<br> shouldn't wrap most of that stuff; it should provide a nice,
<br> high level API. Providing wrappers for things like additional<br> dbus connections is nice, but that should be something that<br> probably should be added later.</blockquote><div><br>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 :)
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> * You provide the concept of a "Service". This may be because I
<br> felt in the past that compatibility with the old bindings (which<br> provided a Service) was important, but I don't really thing it<br> is anymore[1]. Dbus has long since dropped the service metaphor
<br> and simply calls them "names" now, which merely identify the<br> application to other apps on the bus. It doesn't make sense to<br> "register" objects with the "service" anymore. I think it makes
<br> a lot more sense to set up filter functions behind the scenes in<br> the bindings and pull out all the possible objects by using<br> custom attributes and introspection. That way registration<br>
becomes unnecessary.</blockquote><div><br>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.<br><br>public static ImportObject Create (Service service, string target_path, Type [] ifaces)<br><br>would become<br><br>public static ImportObject Create (Connection connection, string service_name, string target_path, Type [] ifaces)
<br><br>I'm not sure I really understand what you are saying about introspection data. Do you mean generating new types based on introspection data?<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
* There's no memory management right now. Doing memory<br> management of C objects from C# is a real pain. Partly this is<br> due to a lack of tools, but partly it's because it's just plain<br> hard, even in C. Trust me on this one: you really, really want
<br> to address this issue up front by making all of your objects<br> which wrap C structures IDisposable and make sure you clean up<br> after them. Don't wait until you have the binding mostly<br> finished and then go back and add them.
</blockquote><div><br>Yep, this is high on the list of priorities. <br></div></div><br>Adam<br><br>