text: Geoff,
  On Thursday 06 December 2001 06:32, Geoffrey Talvola wrote:
  > Tavis,
  >
  > I'm slowly taking a look at your redesign code. The first big
  > incompatibility I noticed is the configuration mechanism. My
  > concerns are:
  >
  > - For Windows users, it's much nicer to have a specific extension
  > associated with config files. I can associate the ".config"
  > extension with my favorite Python editor so that I can edit it just
  > by double-clicking it, then since a config file is also a valid
  > Python source file, I get good syntax coloring. With your redesign
  > code, I can't really do that because it's called ".webkit_config"
  > or ".webkit_config_annotated" which are very unix-centric naming
  > conventions.
  I wanted a scheme that was simple, but extensible and not tied to a
  particular directory structure. Hence my proposal for a single
  config file that follows the unix standard of using ~/.whatever for
  storing application settings in a users directory. However, I'm
  beginning to rethink that.
  If we are using pure Python code as the default config syntax it
  might make sense to have a file name that allows the config file to
  be imported as a normal Python module. That would rule out dot
  files.
  Furthermore, we need a scheme that handles settings for all Webware
  Components, not just WebKit. That's where Chuck's multifile layout
  makes more sense than my single file scheme. Though, I still prefer
  having a single file for WebKit itself.
  you wrote:
  > - Why force all settings into a single file? I actually liked the
  > fact that settings for different components live in different
  > files, although I suppose I wouldn't mind the _option_ of combining
  > them into a single file. In Python source format this could be
  > done with class syntax like this:
  >
  > class AppServer:
  >
  class HTTPServer:
  setting1 = 'qux'
  The best of both worlds - bloody good idea! This layout would make
  it possible to use a single file or multifile layout!! ...
  With Python 2.1 and above, we could even use nested scopes to do
  things like:
  from __future__ import nested_scopes
  class WebKit:
  class AppServer:
  port = 8080
  class HTTPServer:
  serverString = 'WebKit HTTP Server'
  class ApplicationDefaults:
  usePrivateSessions = 0
  sessionIDToken = '_WEBKIT_SID_'
  class MyApp(ApplicationDefaults):
  someOtherSetting = 'foo'
  class MyOtherApp(ApplicationDefaults):
  someOtherSetting = 'bar'
  We'd need to provide an interface to get at the settings as the
  import statements wouldn't always work as expected, but that's no big
  deal.
  The keyword 'class' might be a bit misleading as we're not promissing
  1-to-1 mappings to actual classes, but that's no big deal either. In
  fact, we can use anything that supports __getatrr__ and __setattr__
  for the settings containers: modules, classes, objects, etc. This is
  much cleaner than dictionaries!
  One of the key features of the 'webkit' launcher script is that it
  can be launched from any directory and will find the appropriate
  config file, or use the one specified as an argument to the command.
  This proposal wouldn't affect the latter case, but if we used pure
  python imports to get the settings we'd probably have to do some
  temporary sys.path manipulation to make sure the correct
  'webware_config' is imported in the former.
  The current search order for config files is
  ['.webkit_config',
  os.path.join(os.path.expanduser('~'),
  '.webkit_config'),
  '/etc/webkit_config'
  ]
  Your thoughts?
  Tavis
  View entire thread