[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Excellent technical overview of D-BUS
Re: Excellent technical overview of D-BUS
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:
If, as Rogelio suggested (or was it you, I can't remember) libdbus
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.
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
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.
someone was to provide an optional d-bus based implementation
runtime selectable) which did not break the existing system, I would
only as a good thing ... and we would have an opportunity to move over
it having been able to do a proper comparison of the performance and
of the old and new code.
To the best of my knowledge, you have always been wrong/misleading
stating what my opinions would be! I would be happier if you didn't
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
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 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.
As far as I know, the long term goal is to have D-BUS working
Presumably also under Microsoft Windows. I could look into whether or
it seems to want to compile under mingw. I will try to do that today,
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
is not a show-stopper (ie we could make default behavior differ
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
request inter-host distributed objects.
for my own reference.
You seem to have misunderstood me here ... I was referring to your
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
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
Because NSMessagePort doesn't work under windows ... because it's
the same code as NSSocketPort but using unix domain sockets rather than
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
Why "of course"?
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
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.
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.
- Re: Excellent technical overview of D-BUS,
Richard Frith-Macdonald <=