It seems like there are three things going on here:
1. Customizing classes
2. Access privileges
3. Directory inheritance
I think 1. definitely goes into the existing
WebKit/Configs/Application.config file. It would also be cool if WebKit
would automatically pick up and use classes in applications that had the
same name. e.g. you could just make a Session class that inherits from
WebKit.Session and it would be used by convention of it's name. This
wouldn't replace the configuration capability; it would just be a convenience.
Note that application does take arguments for the various classes and
stores them as attributes. It then uses those when creating new sessions,
requests, etc. So we're half way there. It's the config that's missing (as
Dan has pointed out).
2. Access priv.: Not really sure how this should work. I certainly don't
mind if someone takes a crack at it. Does this mean having classes like
Role, User, etc.?
Or is using the authentication of the HTTP server possible and sufficient?
3. Directory inheritance: A Zope-/Quixote-inheritance scheme could be a
useful thing, although there's obviously a performance hit for such things
(e.g., scanning through each directory). That's why I prefer to use class
inheritance rather than directory inheritance: It's all in memory and
generally faster. But I can still see the utility of directory inheritance
for easier configuration and better file system organization.
To get started, it might be useful to create a Page class/mix-in that
offers methods such as:
That are able to use files in directories under predetermined conventions.
I'm picturing that properties are dictionary oriented, with the closest
dictionaries being overlayed as you travel up the directory chain. In each
directory there would be a Properties.config file. You would want to cache
these and check the timestamps to have an efficient process while still
having the ability to update them on disk at any time.
The objects would be larger things like graphics files or HTML fragments
that are searched for up the directory chain and found according to
filename. These could also be cached by time stamp.
You could also map extensions to Python classes, so that when an object is
asked for, the class is instantiated with it and that's what you get.
For properties, you could special case dictionaries that have a key called
'class'. For such dictionaries, the dictionary would be replaced by an
instance of the class which would receive the readProperties() message.
These are just some brainstorming ideas on my part to warm up the conversation.
With regards to 2 & 3, what I'd really like to see are WebKit plug-ins
rather than a new versions of WebKit.
The reasons are:
* Plug-ins can be developed independently of each other.
* People can then embrace as much or as little of the services we
provide as what they want.
* People can provide alternative versions of our services if they think
they know how to do it better/faster.
* Continuing with the plug-in architecture will encourage more plug-ins
and Webware will evolve faster.
I'm more than willing to guide people in creating plug-ins. It's really
just a small set of conventions for laying out your directories and files
and making a function that lets you hook into WebKit at load time.
With regards to config files, I definitely prefer good ol' Python
dictionaries rather than a custom format. Python config files allow for
infinitely recursive dictionaries and lists and the only thing we have to
do is eval().
Again, if people want to take a crack at plug-ins like this, I will
certainly lend you a hand in ideas, testing, reviews, tech help on Webware,
Provided something is produced that is useful, tested, documented and
follows Webware conventions, we could put it in and you could aquire fame
and fortune. Well, at least fame. :-)