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:
> setting1 = 'foo'
> setting2 = 'bar'
>
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!!
If we just make WebKit and all other Webware components
"""import webware_config""" to get their settings we can use a single
'webware_config.py' module or 'webware_config/' package. Both look
the same to Python. WebKit would have settings in
webware_config.WebKit, UserKit would have them in
webware_config.UserKit, and so on. If we use the 'class whatever:'
scheme you suggested, the settings for WebKit could be in the module
webware_config.WebKit OR the class WebKit in the module
webware_config. The settings for AppServer could be in
the module webware_config.WebKit.AppServer or in the class AppServer
inside the webware_config.WebKit module. And so on ...
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
_______________________________________________
Webware-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/webware-devel
