[Top][All Lists]

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

Re: Excellent technical overview of D-BUS

From: Richard Frith-Macdonald
Subject: Re: Excellent technical overview of D-BUS
Date: Wed, 1 Sep 2004 06:20:35 +0100

On 31 Aug 2004, at 21:46, Alex Perez wrote:

On Tue, 31 Aug 2004, Richard Frith-Macdonald wrote:

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.
If, as Rogelio suggested (or was it you, I can't remember) libdbus might
be sufficient for this..what do you think about that?

I'm not sure it would be sufficient ... I can't see how it would handle the case where you ask for a service provided by any host on the network (ie specify the host name as '*' when creating an NSConnection). However, there may be a mechanism for
this that I missed.
Rewriting DO to use libdbus does not currently seem particularly useful ... basically it does not seem to provide any technical advantage. However, if someone was to provide an optional d-bus based implementation (preferably runtime selectable) which did not break the existing system, I would see that only as a good thing ... and we would have an opportunity to move over to it having been able to do a proper comparison of the performance and features
of the old and new code.

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
Well, I did state that it's what I *thought* you would think, and it's
certainly worth pointing out that while you took issue with what I said I
thought you would think (convoluted, eh?) you did not refute the claims

I don't know what claims you mean here ... just to clarify -
You said that gdomap should only be needed for inter-host DO, and that
'I'm relatively convinced that Richard Frith-McDonald would disagree with me on that point'
I said
'I would prefer to have host-local DO with filesystem based service name lookup the default'

It seems clear we agree it would be better not to have to run gdomap for host local connections.

  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.
As far as I know, the long term goal is to have D-BUS working everywhere. Presumably also under Microsoft Windows. I could look into whether or not it seems to want to compile under mingw. I will try to do that today, just
for my own reference.

You seem to have misunderstood me here ... I was referring to your question
about whether gdomap/inter-host DO or host-local DO (without gdomap)
should be used. This is totally different to the issue of whether to try to
replace gdomap with the d-bus daemon ... as the same sort of reasons
can be given for not wanting newbies to have to start the d-bus daemon
and gdomap,

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
Why "of course"?
Because NSMessagePort doesn't work under windows ... because it's basically the same code as NSSocketPort but using unix domain sockets rather than tcp/ip
sockets ... and windows doesn't have unix domain sockets.

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.

What parts of it are non-portable as it stands now?

NSMessagePort.m and NSMessagePortNameServer.m both depend on
unix domain sockets.  Windows specific versions need to be written using
some windows host-local messaging system.

reply via email to

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