win32 dbus_connection_get_unix_user() problem

[Havoc Pennington]

Peter Kümmel wrote:
> Havoc Pennington wrote:
>> 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.
> 
> Isn't you suggestion in principle something like this:
> 
> void function()
> {
>   do_unx_func();
>   do_win_func();
>   do_wce_func();
>   do_mac_func();
>   do_sym_func();
>   do_palm_func();
> }
> 

No, I don't think so, because there is no enclosing function(). What I'm 
saying is, the config file already supports a number of unrelated 
options for when a policy applies, such as unix user, unix group, bus 
name owned, etc. Just add also windows sid as something the file 
supports. So my suggestion is something like:

   parse_policy() {
     parse_unix_user_attribute()
     parse_unix_group_attribute()
     parse_windows_sid_attribute()
     parse_name_owned_attribute()
     return policy;
   }

Some of the attributes will not make sense on some platforms. On unix 
the windows sid attribute will always be empty as if it were not 
specified, and on windows the unix attributes will always be empty as if 
they were not specified.

In any case, if you think this is a bad way to do it (it might turn out 
to be once you try it), then feel free to come up with another one. But 
I've outlined the properties it has to have (no unix emulation on 
windows in a way that leaks into public API/config, no process-specific 
made-up integers sent over the wire, and no #ifdef hell that will be 
unmaintainable)

Another way to think about it is that the cross-platform abstraction 
should be *internal*, not leaking into the config file, and not leaking 
into the API. Clients of the API do not want to see a "DBusFile" or 
"DBusUser" or something; they will need to either map directly to 
platform-specific types, or they will need to map to a different 
non-dbus cross-platform abstraction such as Qt. Either way, they need 
the actual platform-specific information, not a DBus abstraction.

When using QtDBus on Windows, *then* someone would be completely 
protected from platform specific API, because Qt would offer the 
abstractions for file and user and so forth. But those APIs don't belong 
in the *public* API/config portions of DBus itself.

Havoc