At 06:15 PM 10/24/2001 -0700, Tavis Rudd wrote:
>what are your thoughts about Webware after 0.6? i.e. "what
>issues need to be addressed before 1.0"
After 0.6? Why 0.6.1, of course. ;-)
The largest project for 1.0 is an automated regression test suite for WebKit.
>I assume that 0.6 will:
>* fix the console hanging and socket binding problems that
>Jeff's been working on
Those are either op sys or Python problems; not Webware. I'm not aware of
any outstanding work in this area other than providing convenient options
for discarding daemon output.
Clark Evans has some issues, but they also look to be op sys or
Python+opsys specific. He is investigating other configurations and will
get back to us. If he hasn't gotten back by the time 0.6 is ready, we will
>* incorporate the fixes to Session handling that Ken
Likely in 0.6.
>* incorporate the HEAD method fix from Ken
>* fix small misc bugs
>There's alot of ideas and code floating around for taking
>Webware to the next level after the 0.6 release:
>I think there should be a formal plan to deal with these
>ideas. It should address and prioritize the following:
We'll do some outlining, but I think there is enough laundry items to go
after 0.6.1 without formalizing a big plan for 1.0. Short term fixes and
badly needed refinements are the highest priority.
After 0.6.1, we can incorporate some of the major ideas being tossed about
for a 0.7 release.
>*** making the switch to distutills (probably requires a
>new package structure)
Not high on my list. Compared to what other people are pining for (fixes,
URL handling, etc) this is small.
Also, from what I know of Python, distutils and that *.pth thing, we
probably need to do little in terms of package structure. Webware
components are Python packages to begin with, after all.
>*** implementing a more flexible framework for url handling
>... relates to Clark's path sessions and the non-PATH_INFO
>stuff I've been working on.
>** implementing some form of the multi-application idea
>that Jay and I have been working on
And don't forget my ideas, too. ;-)
>* improving the structure of the config files (see the
>example in http://www.calrudd.com/Webware/)
We'll have to talk more about that. But our current configs are working OK
so I won't give it much attention until other higher priority items are done.
>* adding a .shutdown() method to the Servlet API (see the
>startup/shutdown code in http://www.calrudd.com/Webware/).
>This also relates to Ken's DBPool.shutdown() suggestion.
Oh, upon shutting down the app server? Sounds reasonable. Could probably
squeeze into 0.6.1.
>* working on the DBPool/Application API as being discussed
I'll consider that a separate community effort that at least would provide
a Kit for Webware. Depending on its generality, value, docs, test suite,
etc. we could then include it in Webware proper.
>* implementing some form of an output caching API (I posted
>about this a few months ago)
Another "third party" community effort that will not get driven by me,
simply because I have other things on my list and my web sites are running
plenty fast with the type of caching I do now.
I presume such an API would come with benchmarks of realistic applications
to show the benefit.
>* implementing a ZODB version of SessionStore that would
>allow sessions to be shared between multiple machines.
They can be shared now via a shared file system. But if someone wants to
create a ZODBSession subclass of Session, knock yourself out. Also, don't
forget Pyro (http://pyro.sourceforge.net/) as a tool for distribution.
>* scrapping (or documenting) 'cans'
Already done in CVS and hence 0.6.
>* packaging Cheetah 1.0 and FunFormKit 1.0 with the Webware
>distro (once they're released)
I'm thinking of 2 distro's in the future:
- Webware for Python: contains only what's in Webware CVS. What we do now.
- Webware Deluxe: Contains the usual Webware plus hand-selected valuable
packages like Cheetah, MySQLdb, etc. For the person who wants a complete
web dev package out of the box (e.g., .tar) containing only stable,
documented packages than can work together.
>Maybe a formal decision making process like Python's PEP's
>would help with all this. Chuck, didn't you write a WEP at
>one stage for the Page.py changes? Webware's certainly
>large enough and complex enough to warrant something formal
>like that. If we go that route there should be a WEP
>section on the Webware site to house/categorize the WEPs.
Yes, I have put forth multiple WEPs. However, WEPs are less formal than
PEPs due to Webware's smaller community size and people's lack of
enthusiasm in writing proposals. :-)
Basically, anyone can write a WEP anytime following examples you find in
the -discuss archives or even looking at PEPs. Post them to webware-discuss
I'm not quite ready to get more formal about WEPs.
>Finally, I think it would help to start a DEVEL_BRANCH in
>the cvs that would allow experimentation on these ideas,
>while the work on a stable 0.6 release continues.
Yeah, although I would appreciate people helping me out with 0.6 before
blazing trails of glory while I fix obscure bugs, clean code and cut
maintenance releases. And to his credit, Geoff has indeed been a bug fixing
and discussion support trooper.
The 0.6 release is close enough at hand that I would just like to push it
until it's done. We're all part time on Webware and with 0.5.1 (or rather
rc3) we obviously wavered and dropped the ball.
Also, let me bring up some other important issues, more important than many
of the issues above.
- We often use OneShot.cgi for development and while it works, the delay
can be inhibit productivity. We should be able to run the persistent app
server in a "reload" mode that checks the timestamps of modules and reloads
them as necessary. This would allow faster development and benefit *everybody*.
- We should provide a SequentialAppServer to complement ThreadedAppServer
for use in debugging environments like WingIDE. Again the benefits could be
reaped by the majority of WebKit users.
I've talked to the WingIDE folks and the above two mods would likely make
WingIDE and WebKit get along well. We'd at least be closer. And I would
certainly LOVE to step through the execution of my applications.
- The Install Guide could use more guidelines and advice about the
distinctions between running WebKit for development vs. deployment. Again,
the pay off is universal.
Anyone can push and work on any 3rd party Webware compatible packages they
want. And people do. Take a look at Cheetah and Terrel's various WebKit
In the main project, I would like to focus our limited resources more
sequentially. 0.6, followed by 0.6.1 and various enhancements listed above
in 0.7, etc. A few solid deliveries will help us much more than 6
concurrent subprojects which are all too immature to use in real sites.