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

[Richard Frith-Macdonald]

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