win32 dbus_connection_get_unix_user() problem

[Havoc Pennington]

Hi,

Peter Kümmel wrote:
> To provide a platform independent API is not our
> job, especially because the code isn't understandable,
> when you are not a full time developer working on dbus.
> It is the job of the lib creator/designer, so back to
> the drawing board.

This is just bogus. We're talking about one function, not "the API", and 
  I'm not even asking you to create a cross-platform API; I'm saying, at 
most, add dbus_connection_get_windows_user() that always fails on unix, 
and then copy all the uses of get_unix_user(), doing the analogous thing 
with the windows sid.

But that's *at most*; I also suggested that you simply *don't need* the 
entire feature of associating policies with a user on Windows, since the 
system bus makes no sense on Windows. So basically what you can do is 
just *slightly modify* the code to barf if the config file specifies 
user-associated policies with a user other than "*"

This should take a couple of hours. Maybe a day or two at most if you 
aren't that familiar with the dbus code.

On the other hand, the patch you guys want me to accept *in no way even 
works* because it passes a process-specific integer with no meaning 
aside from the hash table in one process, between processes as if it 
were a system-global value.

I'm fine with hacks and shortcuts, if they are even remotely 
sane/working and don't create a long term wrong API or protocol decision.

Finally, I'm not a full time developer working on dbus, and have not 
been since writing the bulk of the code a few years ago. In fact there 
are *no* full time developers working on it. It is not even my job to 
work on it anymore, I basically participate in this list on a volunteer 
basis.

> Before I start to change the API of dbus, I'll reeimplemet
> dbus with C++ and QtCore as basis, maybe I get sponsored by
> Trolltech ;).

I realize you aren't serious, but stepping back for a minute, what I'm 
asking you to get right all involves changes to the *specification* - 
using Windows-native concepts in the config file, protocol, how to 
locate the bus, etc. where appropriate. You would still have to figure 
out all that if you were porting the C#, Java, or other dbus 
implementation. In fact, those other implementations are a big part of 
*why* I don't want the windows port to rely on random implementation 
details for libdbus on unix.

The whole problem here is that you guys are just trying to make the 
implementation pass "make check" using unix emulation, instead of 
pausing to ask *what API and spec changes are needed* for the thing to 
even be useful on Windows at all. Making things *build and make check* 
on Windows is not the goal! The goal is something a Windows app 
developer would find useful and logical.

> We cannot change hundreds of functions without understanding
> the code,

Then try *understanding the code*. There is no way to port dbus to 
Windows without understanding the code, I'm sorry. I don't know why you 
would think otherwise.

I've also tried to walk you through it, in detail, on numerous 
occasions, generally telling you exactly how to write the patches.

> we could only implement some platform specific
> functions, and test if they work. Currently all bugs of our
> code only pops up as a bug somewhere in the depth of dbus's
> endless function calls. We can't debug this.

If you can't debug software, how do you expect to be a software 
developer? Nobody's patches work the first time, at least not consistently.

> I've not a problem with a long term winDBus-project on sourceforge
> (I don't wanna call it fork.) All we can do we've done.

If you want an unmaintainable and broken windows patch outside the tree, 
then you are welcome to have it. My requirements are simply that if you 
want to put the code in the mainline tree, that it a) work and b) be 
maintainable, because I'm quite sure someone other than you guys will 
have to maintain it eventually.

Look, I'm happy to help, but I have minimum requirements for this port 
that I think are reasonable (I would estimate *maybe* a couple weeks of 
full-time effort, at most, to meet them). I'm going to insist on those 
requirements if you want to put this in the mainline source tree.

Havoc