dbus/bus policy.c,1.25,1.26

[Havoc Pennington]

Hi,

Ralf Habacker wrote:
> Hmmh, with this patch i can start dbus-daemon on windows in session mode 
> and are able to connect from several clients.
> I see this a little more pracmatical. Is it easier to change the 
> direction of a moving target, than a standing one. The only alternative 
> I see is to wait another half year for someone who provides a patch to 
> rework the complete user database, which means to refactor the complete 
> DBusUID and DBusGid code *before*.

If nobody is going to work on it, all the more reason not to put in 
broken hacks, since they will never get fixed.

Finishing the Windows port in a maintainable way should take *maybe* a 
couple weeks of full-time work for the entire remaining Windows patch.

I feel that I've explained what 'maintainable' means on many occasions 
and with respect to many of the outstanding issues. I am getting the 
sense that I'm failing to communicate it, though. If that's my fault 
then it's my fault, and I'm sorry about it. But I'm not sure how else to 
explain things.

Some of the remaining issues with the Windows port involve significant 
(days, a week) code writing, code refactoring, or design issues. So far 
you are saying that any such issue is an impossible hurdle to overcome. 
This is simply not true. It may be that you don't have time to do it, 
and that's fine. But it is *possible* and the work is reasonable in size.

So what we need is a volunteer who has time to do this work. Until then 
the Windows port won't be ready to merge into the main tree.

There is no point wasting time trying to put hacks into the main tree in 
the meantime, because they just make it harder for anyone who wants to 
show up and fix things properly, and deceive users into thinking they 
can use Windows D-Bus and expect it to be production ready.

A more useful task in the meantime would be to save links to past 
threads about each of the outstanding issues, and keep a list of those 
issues.

Havoc