win32 dbus_connection_get_unix_user() problem

Havoc Pennington hp at redhat.com
Tue Mar 13 15:24:01 PDT 2007


Peter Kümmel wrote:
> I don't see a broblem to have DBusFile DBusUser in the API when there is a
> 'member function' to get the platform specific data type.

There are about 2 places in the public API where a user appears, none of 
them used by any typical app, so it's simple to just avoid DBusUser. You 
would still have a get_unix_user()/get_windows_sid() operation on 
DBusUser, so it's not like some kind of metaphysical purity would be 
obtained. Also, the public API is frozen, so we'd have to deprecate and 
make a mess that way.

Anyone using a framework that abstracts users will be able to 
immediately construct their framework's cross-platform user object with 
the unix uid or windows sid that dbus supplies. This can even be done by 
the binding such as QtDBus.

>> You cannot implement an interface on Windows that looks like:
>>
>>  interface Connection {
>>    uid_t get_unix_user_id();
>>  }
> 
> But:
> 
> #ifndef DBUS_WIN
> typedef uid_t dbus_uid_t;
> #else
> typedef sid dbus_uid_t
> #endif
> 
> interface Connection {
>   dbus_uid_t get_id();
> }
...
>> What you could implement on Windows is this:
>>
>>   interface Connection {
>>     DBusUserAbstractionObject get_user();
>>   }
>>
> Ah, ok...

Hopefully it's clear that this is the same as the #ifdef thing, just not 
implemented through an #ifdef

> My idea is more like this:
> 
> interface DBusUserAbstractionObject {
> #ifndef DBUS_WIN
>   uid_t get_native();
> #else
>   sid   get_native();
> #endif
> }

The #ifdef approach is just messy imo. The two get_native can't be used 
interchangeably, and uid_t/sid can't be used interchangeably. So why 
name them the same thing or bother with the #ifdef? Just have two 
methods with names indicating what they do, that is, they return a 
platform-specific data type.

This is especially true for something like connection_get_unix_user() 
where it isn't clear we even *need* connection_get_windows_user(), since 
there may not be any bus daemons on Windows that care about multiple users.

Havoc



More information about the dbus mailing list