[Top][All Lists]

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

Re: D-BUS versus GDOMAP (WINDOWS users please note)

From: Richard Frith-Macdonald
Subject: Re: D-BUS versus GDOMAP (WINDOWS users please note)
Date: Tue, 31 Aug 2004 07:44:45 +0100

On 29 Aug 2004, at 19:49, Alex Perez wrote:

Rogelio Serrano wrote:

is DO similar to d-bus? Or can we implement something like dbus using DO?
D-bus is basically "DO Done Right" (with a proper authentication mechanism and significantly more focus on security. I've suggested a few times in #GNUstep (and maybe here on the list as well, check the archives)

not that I can see ... I don't think most developers use IRC.

that we replace gdomap with it, since it's a lot more secure, more generally accepted as "canonical", has a much larger userbase, is a Freedesktop.org spec/app, meaning that Those Other Desktops(tm) will eventually use it (and quite possibly Xorg itself at a future date (after 6.8 is released, for sure)

This is the first time I've looked at it, but I've gone through the tutorials and a bit of the source code and it does not look as though there would be an easy way to use it to replace gdomap ... it would instead replace the entire transport layer. So 'D-BUS versus GDOMAP' is misleading since they are not really doing the same sort of job. While gdomap is used once per connection, to lookup the port and then the client connects directly to the server, with dbus the client connects to the bus and then passes all messages to the bus, which forwards them to the server. I think it would be possible (and desirable for GNUstep) to work out a way to use the bus solely as a name server and connect peer to peer, but that's not the way its designed. As far as I can tell, d-bus is not finished yet and is certainly not portable yet (I'm not sure it's ever intended to work under ms-windows). So if anyone wants to rewrite the distributed objects system to use d-bus, they would most likely need to contribute quite a bit of work to d-bus too.

In any event, with alexm's default set, you do not need gdomap running for local-host DO (you only need it for inter-host DO) Personally I think that should be the default, but I'm relatively convinced that Richard Frith-McDonald would disagree with me on that point.

To the best of my knowledge, you have always been wrong/misleading when stating what my opinions would be! I would be happier if you didn't do it.

If anyone agrees that gdomap should be disabled by default (keeping in mind that functionality is not lost for intra-host DO, and only for inter-host DO) please voice your opinion on the matter here. IMHO, gdomap shouldn't be required to simply run a GNUstep app, since this creates problems with setup of the environment that cause potential converts to scurry into the underbrush before we can feed them the Kool-Aid.

Richard, I'd also appreciate it greatly if you'd give us your opinion on the matter. As far as I understand it, with alexm's default set right now, inter-host DO is still possible but you have to explicitly say you want it.

I would prefer to have host-local DO with filesystem based service name lookup the default, but there are still a few problems with it. I had a long, confused discussion about it with Alexander many months ago, in which the final position as I understood it was that we would progress when he had time to do some coding. At the time I was a bit concerned about how tested/reliable the new code was (that's no longer an issue). There are a few other concerns...

1. There is no implementation for ms-windows. We really should have this working on all the systems GNUstep runs on before we make it the default. I don't use windows myself, so I'm biased towards saying this is not a show-stopper (ie we could make default behavior differ between windows and unix), but I don't know what popular opinion would be. 2. The change will break existing code, so we need to go through at least one release cycle where we deprecate the old behavior very clearly. I've finally got round to adding a macro to NSDebug.h to issue once-per-process warning messages when deprecated functions/methods are executed ... something like that should be used to make sure that developers switch over to using methods to explicitly request inter-host distributed objects.

I said we should make the local DO the default if the system is running in MacOS-X compatibility mode (GSMacOSXCompatible user default) ... since apps designed for MacOS-X should be expecting that behavior anyway. That change is now in place, but of course it doesn't work under ms-windows.

There was a lot more stuff than that covered, but I think I've hit the main relevant points.

I now think, at the time of these discussions we should have put out a call for developers to do a windows implementation. I was kind of expecting Alexander to do the coding as he was pushing for the changes, but I now think I was mistaken/unreasonable to expect that (after all, I hate windows coding, so why should I expect anyone else who doesn't use windows to do it).

So, if anyone would care to develop a windows version of NSMessagePort and NSMessagePortNameServer I'd be grateful. It may be possible to use a modified version of the NSSocketPort code (using only as the host and using the filesystem to hold service name information), but I think it would probably be a *lot* better to use some sort of windows native messaging mechanism if possible. Such code would be substantial enough to require copyright assignment to the FSF, so any volunteer should already have done that, or should please get that process going as soon as possible.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]