[Fwd: Re: D-BUS on Windows?]
hp at redhat.com
Mon Nov 29 09:11:22 PST 2004
On Mon, 2004-11-29 at 06:56 -0600, Jon Trowbridge wrote:
> - There are some source files that are called *-unix.[ch], even if
> they mostly aren't that Unix-specific, just contain more or less
> nromal socket API calls. Would is still be better to just copy them
> as *-win32.[ch], and modify appropriately, even if the bulk of the
> code would be identical in the "unix" and "win32" versions? Or use
> the *-unix.[ch] files also on Win32 (and modify them to use wrapper
> functions/macros from dbus-sysdeps.[ch])?
This is my big question as well - do we want to create a sockets
abstraction in dbus-sysdeps.c and use the same code everywhere else,
or do we want dbus-transport-win32.c
My best guess is as follows:
- duplicating all of dbus-transport-unix.c is probably a bad idea.
However we could potentially factor a lot of it out into
a base class and then have win32/unix subclasses.
- from the point of view of the .conf file, we should treat whatever
the Windows transports are the same way we do pipes vs. unix domain
sockets vs. tcp sockets - that is, a distinct address
format for example. I'd expect to have different default .conf
files on Windows.
- for the uid/gid I think we should use the sid on Windows, if the
user-based distinctions are even interesting on Windows;
basically we should allow writing a security policy which makes
sense for Windows using normal Windows access control and
A fair starting point for now would be to just not allow
any of the uid/gid stuff on Windows, since it isn't
relevant for the session bus anyhow.
- in short we want to use Windows native stuff, rather than
making the conf file all UNIX-looking and somehow making it run
- my suggestion is to figure out a conf file and public APIs
that are sensible for Windows, then implement that by
wrapping the Windows stuff thinly in dbus-sysdeps.c
(e.g. just have a _dbus_listen_windows_socket() perhaps)
with #ifdef in the rest of the code, then figure out
whether/how we can do a higher-level "GIOChannel" type
of abstraction in dbus-sysdeps.c to drop the other
#ifdefs ... maybe actually doing some of those steps
can be skipped, but conceptually I'd think of it that
- I don't want to have "ambiguous" file descriptor integers
or something like that anywhere; it should be 100% clear
at all points in the code whether an integer is an
abstraction windows/unix exported by sysdeps, or a UNIX
Some thoughts, Tor is the expert here.
More information about the dbus