I wholeheartedly support a new release. I am curious though why you want to spin all the other kits off into their own projects? From the point of view of someone who has just finished installing everything, I don't like having so many pieces to download and fit together. Already I have had to download and configure:
- webware
- Cheetah
- postgresql
- mkDateTime
- psycopg
- and I also was trying out ZODB/ZEO.
The process of evaluating new technologies for an upcoming project is already arduous. I would suggest that making this process easier will promote Webware's adoption.

-winston


From: Matt Feifarek <[EMAIL PROTECTED]>

<<inline: msg.gif>>

Towards a new release: request for thought and discussion  
2004-08-05 14:57

There was a little chatter a couple of weeks ago about a new release. It
seems to have died down, so, I"d like to start a discussion to see where
people think a new release might go.


Herein lies my opinion. I have no vested control over Webware, but I and
my firm have been using it basically exclusively for 3 years for all web
work.


Here"s a stab at a plan:


0. pull the head of the CVS as a base


1. remove all non-core "kits" like middlekit, comkit, taskkit, userkit,
etc. When there is a dependency on one of them for Webkit, fix the
dependency. To the extent that these projects have interest (like
MiddleKit) spin them into their own projects.


2. upgrade Page.py to include support for XHTML, W3C standards, and a
few other simple things (we"ve got a good lead on this one already)


3. Choose one (1) templating option (maybe PSP) if it"s deemed essential
to get the php/asp crowd comfortable. If we can"t agree on one (1) then
ditch it, and include *prominent* links to the contenders, and how to
install them.


4. make sure that at least for quick-test, one can run a stand-alone
python-based httpd next to the appserver to solve all the httpd
configuration junk (Ian"s standalone webkit is a perfect place to start)


5. fix the whole MakeAppWorkDir thing and any associated problems


6. distribute relevant adapters somewhat separately (mod_webkit et
al)... as in the stuff that isn"t python doesn"t come "inside" of
webkit, but it is readily available from the project. Also, get the
ancillary adapters out of the way, and make it clear which one is *the*
one to use.


7. include a "how to set-up your application" document, or prominent
links. Most newbies that I"ve introduced have had this question... and
I"ve got some ideas of what to write (yes, I"m volunteering to write this)


8. include a form processing library into webkit itself


This last one is likely to seem a little controversial, but a web
application framework that doesn"t handle form processing out-of-the-box
is hard to take seriously. Naturally, as my firm wrote FormKit
( http://dalchemy.com/opensource/formkit/ ) I would suggest that,
including a few fixes based on astute comments from this list. We"d be
more than happy to "donate" the FormKit project to the Webware/Webkit
project.


BUT, even if we use FFK, or Ian"s new FormEncode, or something else, we
need SOMETHING. To have a web-framework that doesn"t do forms is ridiculous.


So, what about something along the lines of my list above for
Webware/Webkit 0.9?


There are lots of things that are no doubt precious to lots of us that I
haven"t included above. Some of these are just too ambitious for a next
release, so I"ve listed them here, as a speculative 1.0 release:
- python 2.3 (2.4) features leveraged
- unit tests
- new docs (I know someone who is good and is willing)
- support for things like email, dav, SOAP, etc.
- real securepage with users/logins, etc.
- adapter for twisted (so you can use twisted as httpd)
- python distutils support and some packages (rpm, deb, whatever)


Reply via email to