Excellent technical overview of D-BUS

[Alex Perez]

On Tue, 31 Aug 2004, Richard Frith-Macdonald 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.
Some do, just not most. We have lots of idlers who just poke in when they 
have a few moments and are merely lurking most of the time.
> 
> > 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?

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

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

> 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.
Why "of course"?

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

Shoulda' Woulda' Coulda'... :) What's done is done. I don't blame others 
for not having any desire to program under Windows, but there are those 
who want their stuff to be portable.

> 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?