discuss-gnustep
[Top][All Lists]
Advanced

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

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


From: Rogelio Serrano
Subject: Re: D-BUS versus GDOMAP (WINDOWS users please note)
Date: Tue, 31 Aug 2004 15:04:48 +0800

On 2004-08-31 14:44:45 +0800 Richard Frith-Macdonald <richard@brainstorm.co.uk> wrote:
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...
I think DO is more like the libdbus layer not the message bus 
layer. Im not really interested in using it. We can instead 
create something similar to the dbus daemon.
Can DO use unix domain sockets? Im more intereseted in using 
the message bus daemon idea to emulate mac os x boot services. 
And on demand startup of system services. So I can simplify my 
init.app. its a mess now with boot script tracking and 
dependency tracking and system shutdown.

--
Blood is thicker then water... And much tastier
                            John Davidorff Pell





reply via email to

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