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