At 06:15 PM 10/24/2001 -0700, Tavis Rudd wrote: >Hi guys, >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 ship anyway. >* incorporate the fixes to Session handling that Ken >contributed Likely in 0.6. >* incorporate the HEAD method fix from Ken Probably. >* fix small misc bugs As usual. >There's alot of ideas and code floating around for taking >Webware to the next level after the 0.6 release: > >ftp://ftp.jslove.org/pub >http://www1.ics.uci.edu/~tshumway/webware/ >http://www.calrudd.com/Webware/ > >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. 0.7 >** implementing some form of the multi-application idea >that Jay and I have been working on 0.7 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 >right now 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 for...discussion. 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 enhancements. http://webware.sourceforge.net/ThirdParty.shtml 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. -Chuck _______________________________________________ Webware-discuss mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-discuss
