dbus/bus policy.c,1.25,1.26

[Ralf Habacker]

Havoc Pennington schrieb:
> 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.
Sorry, I could not believe this. There was hard work done in the last 
years starting with Tor Lillqvist and Peter Kümmel, Christian Ehrlicher 
and others to get the windows port to the level it is. Sure it isn't 
complete, but this will come by time.
>
> Finishing the Windows port in a maintainable way should take *maybe* a 
> couple weeks of full-time work for the entire remaining Windows patch.
Thats exactly the problem - it is to much work for one person to do this 
in the spare time and it need more people working together.
>
> 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.
Yes you have explained very much, but please be aware, that some thing 
under windows does not go in the unix way.

I think now it the time to roll up one's sleeves and to start moving 
from - of the windows side  'unmaintable' unix code - to a platform 
independent code.

The main issues currently are the dbus_uid_t  and dbus_gid_t types which 
are unix only.  Do you have ever tried to make a struct from it and how 
much locations you have to touch ? For my opinion a partial port does 
not work, either *all* is ported or nothing.

The main task looks to me to make dbus_uid_t and dbus_gid_t platform 
independent and this does not belong to the core windows port. It is a 
requirement to be able to make the port.

I have thought about how to encapsulate them, may be using a DBusUser 
struct, but unfortunally such a type is already there but with a 
different meaning. This requires an internal redesign in a dimension, 
which is out of the personal time of the related developers. So we are 
stopped here. :-(

> Some of the remaining issues with the Windows port involve significant 
> (days, a week) code writing, code refactoring, or design issues. 
yes , but the problem is that the currently api isn't  platform 
independing and need to be done at first as mentioned above.

> So far you are saying that any such issue is an impossible hurdle to 
> overcome. 
no
> This is simply not true. It may be that you don't have time to do it, 
> and that's fine. 
But I see currently noone else taking the challenge - how to proceed ?
> But it is *possible* and the work is reasonable in size.
I agree. I think we differ in the way how to do.
>
> So what we need is a volunteer who has time to do this work. 
or part the burden into smaller pieces, which could be done by more 
people one after the another.
> Until then the Windows port won't be ready to merge into the main tree.
I don't agree. The first thing is to make parts of the internal dbus 
core api platform independend to have room to implement the windows 
parts for example the dbus_uid_t and dbus_gid_t stuff mentioned above.

Ralf