winDBus authentication stage
Havoc Pennington
hp at redhat.com
Tue Mar 13 15:38:01 PDT 2007
Ralf Habacker wrote:
> Nice statement, I agree with you, the problem is that there may be
> multiple views how to reach this aim. The main discussion we had - and
> may be will have - looks to me as a try to find a common base where we
> can go together on the road. Let me explain this with the following
> example:
>
> I found split_paths_and_append() in dbus-sysdeps-win.c (see below) and
> the comment says:
>
> // @TODO: this function is duplicated from dbus-sysdeps-unix.c
> // and differs only in the path separator, may be we should
> // use a dbus path separator variable
>
> It is a long function and for my opinion there is no reason to duplicate
> it as it is. I would add a constant DBUS_PATH_SEPARATOR to
> config.h.cmake for cmake (and configure.in for autools) and place this
> function into dbus-sysdeps.c. Ready. Someone else may think in another
> and we can discuss over this detail until death, which isn't wanted by
> anyone and the real important stuff is undone. The important question
> is: Where is the limit ?
>
For this example, I would accept the Windows port upstream with or
without cleaning up split_paths_and_append(). I think it would be nice
to clean up, if it can be done sensibly. I think we talked about
split_paths_and_append and I forget the details, maybe there was
something hard about cleaning it up nicely.
I'm generally more willing to accept cut-and-paste code than bad hacks
or complicated code, btw. It's more important that things make sense
than to never duplicate a line.
The things I care about are for example:
- put abstractions at the right "level" - fix the root problem
- avoid #ifdef hell ; if the project builds on one platform,
at least the platform-independent files should build on all,
and the breakage on other platforms should be compiler-detectable
- the library and daemon look sane and platform-native to
developers and admins on each platform
- unix concepts don't leak into windows and vice versa
- follow the code formatting style and other cosmetic conventions
Havoc
More information about the dbus
mailing list