Re: Excellent technical overview of D-BUS

[Richard Frith-Macdonald]

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
> > it.
> 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
> themselves...

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
> > ms-windows.
> 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 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.