[PEAK] Does a PEAK-ized webware esist ?

Ian Bicking ianb at colorstudy.com
Thu Jan 29 18:33:34 EST 2004


wayne at larsen.st wrote:
> PEAK/Webware integration could be done in several ways -- however, this
> proposal is not what I was thinking.  You appear to be proposing a way to
> run webware from within the peak framework (ie as a CGI).  This was
> opposite to my thinking, of wanting to embed peak components within
> webware.
> 
> Let me ramble a bit and lay out my requirements and analysis, and maybe
> Ian and Philip can set me straight.
> 
> I have a couple of existing web apps that are running under the Webware
> framework right now (I am also using MiddleKit, FormKit, and Cheetah).  As
> I was developing a third, I ran into a number of issues related to
> component flexibility, reuse, and configuration -- at the same time, I
> came across PEAK.  It's certainly a mind shift in thinking, and I am still
> grasping at comprehension, but I do believe that there is a lot of
> potential for improvement by integrating PEAK into my applications.  Going
> through PEAK also led me to relook at ZopeX3, leaving me with three
> potential options for moving forward:
> 1. Switch to Zope3
> 2. Work with peak.web
> 3. Integrate PEAK into Webware
> 
> So, backing up, what would I see as the perfect framework:
>  - Webware style app server, with the mod_webkit adapter, so that the app
> server can be run behind Apache for dynamic content
>  - Utilize the PEAK config and component frameworks for allowing flexible
> configuration of servlets.  Servlets in a directory tree should allow for
> dynamic discovery and configuration, so that subdirectories can override
> settings as required.

There's something along these lines in Standalone WebKit (which is where 
any of this development would make sense).  URLParser picks up 
configuration files named "webware.ini", and adds them to a 
request-specific configuration.  Since you can reroute URL parsing in 
several ways, you can do something like:

/MyRoot/webware.ini
/MyRoot/__init__.py which points to -->
/AppRoot/...

Then servlets in AppRoot can see the configuration from 
/MyRoot/webware.ini, but you don't need to touch the application's files 
or directory at all.  You can do stuff in __init__.py so that everything 
is redirected to another directory (after reading the config) without 
consuming any of the URL.  You should be able to do this redirection in 
webware.ini, but you can't now -- URL controlling configurations can't 
be passed along (since they only apply to one location), so there has to 
be some mechanism either for URLParser to consume configuration, or ways 
to mark configurations as local, URL-specific, or something.

I don't think that's all of what you want, but it probably fits in there 
somewhere.  Potentially URLParser could look for other .ini files to 
bring into the request.

I'm open to suggestions about how Standalone WebKit does configuration. 
  Maybe PEAK configuration would fit.  This stuff is in 
Sandbox.ianbicking.WebKit.Configuration (in webware-sandbox.sf.net).

Some of the details of WebKit.Configuration, which might align with 
PEAK's configuration, or not:

* I allow for the possibility of other configuration formats besides 
.ini, but haven't implemented any other parsers.
* When option values are retrieved, type information is given.  So 
there's no configuration schema.
* While several configuration files are brought in, they all get loaded 
into the same space (except for configuration files URLParser adds). 
The only partitioning is the section headers in the .ini files 
themselves.  This includes configuration files URLParser brings in.
* Configuration.ChainedConfiguration allows you to look through 
different configurations in order.  This way URLParser's configuration 
shadows the global configuration.
* There's a separate URLParser.FileParser instance for each segment of 
the path, and each instance has its own configuration (or none if 
there's no webware.ini).  Other kinds of parsers could add configuration 
differently.  Or the parser could add a configuration when it finds the 
servlet, i.e., look for servletname.ini and load that configuration.

I don't really know enough about PEAK configuration to comment on the 
rest much...

>  - Handle all the default web services, such as session management,
> cookies, log files, headers, already provided via Webware.
>  - Enable reuse of my existing components, and enable pythonic development
> 
> So, while ZopeX3 looks to be a marked improvement over Zope2, and I would
> like to understand it better, for now, let's ignore it and look at the two
> other options - peak.web and Webware/PEAK integration.  It would be great
> to see a non trivial application running within peak.web, as there are a
> lot of things I do not understand about it.  I could not get the trivial
> examples to  run right now with Zope3 CVS - however, even if I had that
> running, as far as I can understand, there are a lot of things yet to be
> decided and implemented.
> 
> Thus, I started looking at integrating PEAK and Webware.  To me, this
> means doing the following:
> 1. - Convert the configuration system to use peak.config
> 2. - Make some of the main classes components
> 3. - Convert the UrlParser and ServletFactory components to launch the
> servlets with the appropriate configuration root.
> 
> This last step is where I'm at right now - I would like to enable a
> structure like:
> 
> ServletRoot/main.ini
> ServletRoot/Site1/
> ServletRoot/Site1/site.ini
> ServletRoot/Site1/index.py
> ServletRoot/Site1/page1.py
> ServletRoot/Site1/subdir/resource.ini
> ServletRoot/Site1/subdir/page2.py
> ServletRoot/Site2/
> ServletRoot/Site2/site.ini
> ServletRoot/Site2/index.py
> ...

What's the meaning of main.ini, site.ini, and resource.ini?  I.e., what 
distinguishes them, when do they get loaded, what's their scope?  Is 
this a PEAK convention?

> Looking at peak.ini, it appears that there is support for this style of
> configuration file / path setup, but I have no idea how that would be
> used.
> 
> A lot of open issues for me -- any comments?




More information about the PEAK mailing list