win32 dbus_connection_get_unix_user() problem

[Peter Kümmel]

Havoc Pennington wrote:
> 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()
>     return policy;
>   }

I would handle all problems the same way,
no unix/win functions in the independent code:

parse_policy() {
  parse_attribute()
  return policy;
}

-unix.c file:
parse_attribute() {
  parse_unix_user_attribute()
  parse_unix_group_attribute()
  parse_name_owned_attribute()
  return ...
}

-win.c file:
parse_attribute() {
  parse_windows_sid_attribute()
  return ...
}


Even when it is only one place, so you don't have to think about
how the platform specific problem is handled at this special place.

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


-- 
Peter Kümmel