Re: New module decisions for 2.22

Vincent Untz wrote:
cc-ing release team to get input from others.

Le samedi 12 janvier 2008, à 03:38 +0000, Alp Toker a écrit :
Vincent Untz wrote:

Le vendredi 11 janvier 2008, à 23:29 +0000, Alp Toker a écrit :
Alp Toker wrote:
 + ndesk-dbus, ndesk-dbus-glib (external dependency)
  - good from a security point of view
  - need to be in a mono-specific section of the external dependencies
    (because of the special rules about depending on mono)
  => accept
Hi Vincent,

I'm not too comfortable having this in a Mono-specific section. Managed D-Bus isn't a Mono project for good reasons and I've taken care not to depend at all on Mono or other non-standardised platform libraries. This is pure ISO-specified C# code as much any C module in the platform -- it can be considered a Free replacement for non-standardised .NET Remoting features.

The IPC system based on two freely available specifications (XDG[0] and D-Bus[1]), both of which are widely implemented and deployed without issues.


Sorry, I forgot to explain UnixMonoTransport.cs which may have thrown you off. It's still in the git repository but isn't shipped in tarballs. It's been rewritten to use standard Unix interfaces in the file UnixNativeTransport.cs specifically so managed D-Bus can become a fully blessed GNOME dependency.

You can find out more about the clean room approach to development in my slides from GUADEC:

An update on-list clarifying that it's an ordinary blessed dependency without special status would be appreciated.
We should probably talk about this with the whole release team, but
here's the rationale:

 + AFAIK, ndesk-dbus needs mono to be used
I did mention, it doesn't need Mono so we can avoid that whole debate. I put care into making sure managed D-Bus works on multiple CLR implementations throughout the development cycle.

It's been known to run under DotGNU (somewhat slowly) and I know there's at least one educational project using it with Rotor (they're using D-Bus to remotely control their robots; fascinating project using a GTK+ frontend and managed D-Bus -- all done without Mono).

I quickly looked at the, and it still seems to require
mono, via the Mono.Posix assembly, eg.

But I see your point, and that's an interesting one: DotGNU wasn't
considered when creating the mono rule.

Mono.Posix is just a thin wrapper around Unix syscalls and doesn't depend on Mono or any non-standardised CLR extensions. If having "Mono" in the name is still a problem for the release team, I can look into copy-and-pasting the 200 lines or so I need directly into managed D-Bus.

Managed D-Bus is written in ISO/IEC 23270 C#, just like we write other parts of GNOME in ISO/IEC 9899 C. It's built up on standards, some of which I've helped to author -- this is pretty much as free as free software gets.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]