Ian Bicking wrote:
- 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
lloyd wrote:
* 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?)
is that a good thing (contexts going away)?
Either they should go away, or become a mechanism for web applications. Right now they don't do anything but cause complexity.
recently i was looking over the (abandoned?) "webware experimental refactoring" project, and it had some interesting improve
Ian Bicking wrote:
I'm personally convinced that this should be the future of Webware (and,
in a general architectural sense, Python web programming as a whole). It
offers a few current advantages over Webware:
[...]
* Mostly backward-compatible. There are some missing corners of the
Webware AP
Winston Wolff wrote:
So regarding WSGIKit and Webware, how do you think we should proceed as
far as the code base and development goes? Should we try to move Webware
over to use WSGI, should we develop them in parallel? It seems to me we
should at least put them in the same version control syste
So regarding WSGIKit and Webware, how do you think we should proceed as far as the code base and development goes? Should we try to move Webware over to use WSGI, should we develop them in parallel? It seems to me we should at least put them in the same version control system. I prefer Subversio
[EMAIL PROTECTED] wrote:
While we're talking about improvements, I might re-note the existance of
WSGIKit: http://svn.colorstudy.com/trunk/WSGIKit/
I prefer Webware over other Python frameworks because of its multithreaded
application server. I don't know whether that is at all compatible with th
Quoting Ian Bicking <[EMAIL PROTECTED]>:
> While we're talking about improvements, I might re-note the existance of
> WSGIKit: http://svn.colorstudy.com/trunk/WSGIKit/
>
I prefer Webware over other Python frameworks because of its multithreaded
application server. I don't know whether that is
While we're talking about improvements, I might re-note the existance of
WSGIKit: http://svn.colorstudy.com/trunk/WSGIKit/
I'm personally convinced that this should be the future of Webware (and,
in a general architectural sense, Python web programming as a whole).
It offers a few current advan
I'd like to do some cleaning up of Webware after our v0.9 build. The automated tests are good preparation to that cleanup. When there are a good set of test cases in place, I'd like to make Webware easier to install. I'm also improving my Cheetah ServletFactory which I can add as a kit. And I h
hi,
not exactly an improvement, but rather a bugfix:
i think the issue was already mentioned once on this list. mod_webkit
for apache 2 does not work with the apache 2 installation of SuSE linux
distribution 9.0. i don't know, whether anyone has solved this very
specific problem.
admittedly, thi
I'd like to do some cleaning up of Webware after our v0.9 build. The automated tests are good preparation to that cleanup. When there are a good set of test cases in place, I'd like to make Webware easier to install. I'm also improving my Cheetah ServletFactory which I can add as a kit. And I h
12 matches
Mail list logo
