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