>> * Mostly backward-compatible. There are some missing corners of the
>> Webware API, but that can be fixed. The whole MakeAppWorkDir thing
>> goes away (for better or worse), and Contexts disappear.
> is that a good thing (contexts going away)?
> recently i was looking over the (abandoned?) "webware experimental
> refactoring" project, and it had some interesting improvements that, to
> me, seemed like a natural progression for webware:
> - contexts become "applications" - get their own sessions and state;
I definitely want to support multiple applications living in the same
process. Contexts don't really help me do that, though. So I'd rather
simply have per-directory (or per-url-path) configuration. Then an
application could simply be dumped somewhere, or the directory could be
pointed to from some configuration file, and that would be it.
> - formalized method for executing (context/)application-specific code
> once on startup, with access to various webware components. (what's the
> recommended way to do this now? stick it in a site page at module level?)
The Context's __init__.py will be loaded, and I think some method from
that called (contextInitialize or something).
> - out-of-the-box connection pooling
Is there anything wrong with MiscUtils.DBPool? At least, stuff that
couldn't be fixed?
> - get webware into debian's repository? :-)
They have pretty strict policy, which Webware as it is now doesn't
follow very well. Though it's kind of fuzzy... if Webware is just a
package with a per-instance installation script, do the instances have
to conform to policy? I'm not sure.
Ian Bicking / ianb@... / http://blog.ianbicking.org