From: Tavis R. <ta...@ca...> - 2001-10-25 01:06:18
|
Hi guys, what are your thoughts about Webware after 0.6? i.e. "what issues need to be addressed before 1.0" I assume that 0.6 will: ---------------------------------- * fix the console hanging and socket binding problems that Jeff's been working on * incorporate the fixes to Session handling that Ken contributed * 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: 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: ------------------------------------------------------------------------------ *** making the switch to distutills (probably requires a new package structure) *** 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 * improving the structure of the config files (see the example in http://www.calrudd.com/Webware/) * 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. * working on the DBPool/Application API as being discussed right now * implementing some form of an output caching API (I posted about this a few months ago) * implementing a ZODB version of SessionStore that would allow sessions to be shared between multiple machines. * scrapping (or documenting) 'cans' * packaging Cheetah 1.0 and FunFormKit 1.0 with the Webware distro (once they're released) 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. 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. Cheers, Tavis |
From: Geoff T. <gta...@na...> - 2001-10-25 15:04:39
|
Now that we're talking about future work... For my use of Webware, a single box is more than enough horsepower. But suppose I had to scale up to 2 or more boxes to handle the load and/or for redundancy. How would I do it with Webware? For that matter, how is it typically done with other systems like IIS with Active Server Pages or Java Servlets? Is there some sort of front-end hardware or software that distributes the requests evenly to the different web servers? Would Webware support this now, or would it need to be enhanced? The only problem area I can think of is session handling. Fortunately, it would be easy to write a session store that used a database back-end. Or, without too much pain you could modify the adapters so that they always route requests for the same session to the same appserver. -- - Geoff Talvola gtalvola@NameConnector.com |
From: Federico Di G. <fo...@de...> - 2001-10-25 15:15:32
|
On Thu, 2001-10-25 at 17:03, Geoff Talvola wrote: > Now that we're talking about future work... >=20 > For my use of Webware, a single box is more than enough horsepower. But=20 > suppose I had to scale up to 2 or more boxes to handle the load and/or fo= r=20 > redundancy. How would I do it with Webware? For that matter, how is it=20 > typically done with other systems like IIS with Active Server Pages or Ja= va=20 > Servlets? Is there some sort of front-end hardware or software that=20 > distributes the requests evenly to the different web servers? when using zope (abandoned in favor of webware) we had the same problem. we solved it by using 4 application server boxes + 1 db box + load balancer box. the load balancer uses a modified kernel from the linux virtual server project (http://www.linuxvirtualserver.org/) and balance the incoming net load by rewriting packet headers. outgoing packets (already mangled) go directly from the app servers to the client.=20 =20 > Would Webware support this now, or would it need to be enhanced? The onl= y=20 > problem area I can think of is session handling. Fortunately, it would b= e=20 > easy to write a session store that used a database back-end. Or, without= =20 > too much pain you could modify the adapters so that they always route=20 > requests for the same session to the same appserver. sessions were hold on the db, but i think you can very easy write a DistributedSession class that propagates and cache session data... the lvs also has a configurable timeout to route incoming connections to the same server, but with the large number of today masquerated hosts, you don't usually get anywhere (i.e., one box overloaded, the others almost idle...) ciao, federico --=20 Federico Di Gregorio Debian GNU/Linux Developer & Italian Press Contact fo...@de... INIT.D Developer fo...@in... Don't dream it. Be it. -- Dr. Frank'n'further |
From: Ian B. <ia...@co...> - 2001-10-25 18:08:03
|
Geoff Talvola <gta...@na...> wrote: > For my use of Webware, a single box is more than enough horsepower. But > suppose I had to scale up to 2 or more boxes to handle the load and/or for > redundancy. How would I do it with Webware? For that matter, how is it > typically done with other systems like IIS with Active Server Pages or Java > Servlets? Is there some sort of front-end hardware or software that > distributes the requests evenly to the different web servers? Well, you could use the poor-man's load balancing -- just redirect new visitors to the box they should use. I.e., www.whatever.com (and whatever.com) point to a front-end box that does nothing but immediately redirect the user to www1.whatever.com, www2.whatever.com, etc. Users will then always go to the same server from that point on in their session, so you don't need to share sessions. Of course, there's also an advantage to caching the output as well, which a more intelligent load-balancer could do. It seems plausible that Webware could cache its output on its own fairly efficiently, though, though you'd still get the adapter overhead. Maybe the adapter could cache the output... Ian |
From: Chuck E. <Chu...@ya...> - 2001-10-25 08:39:12
|
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 |
From: Tavis R. <ta...@ca...> - 2001-10-25 17:01:15
|
On Thursday 25 October 2001 01:39, Chuck Esterbrook wrote: <SNIP - and SHUFFLE> > >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. .... > 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. Agreed. That said, a very visible TODO list makes it clear how people can contribute in both the short and long-term. It highlights where patches, docs, and thought are needed. It also makes delegation easier and could take some of the load off you. It sounds like 0.6 is just around the corner. Many of the people who have nothing solid to contribute to 0.6 have thoughts (and code) on those ideas we just listed and might like to contribute to the 0.7 work. (http://dev.zope.org/Resources/ZopeRoadmap.html sums up my argument well) You mentioned 'separate community efforts' several times in your reply. This makes sense, but we need some sort of vehicle or forum to guide these efforts and prevent them from being lost in the ether. It needs to provide structure, continuity and a process for collaboration. The email lists are simply not adequate for this task. The 3rd party page is a good start, but it doesn't encourage collaboration. Python uses SIGS with communication via email lists and PEPs. Zope uses 'projects' with communication via wikis. Both approaches have worked wonderfully in some cases and failed miserably in others. I feel some time invested now in setting up something similar for Webware will pay off big-time on the way to 1.0. What do people think?? Does anyone have experience setting up a wiki? What other options are there? Clearly, this would fall into the 'separate community effort' category and should function without requiring effort from you (Chuck). There's enough people floating around here that it shouldn't be too difficult to find some volunteers to steer this. > The largest project for 1.0 is an automated regression > test suite for WebKit. Ah, forgotten about that one. I agree! Use of unittest has been a huge blessing for Cheetah dev. This is something that could proceed independently of the main Webware coding and would also be beneficial to Webware users developing their own applications. I think I've convinced Steve Purcell to change the license of his HTTPSession.py from the GPL to a Python/Webware style one so it can be used here. What were your concerns about the structure of the package again? > >** 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. ;-) What are they??? :-) You were going to post your notes at one stage. > 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. Good idea! Standard vs Batteries-Included. Cheers, Tavis |
From: Ian B. <ia...@co...> - 2001-10-25 18:27:56
|
Tavis Rudd <ta...@ca...> wrote: > What do people think?? Does anyone have experience > setting up a wiki? What other options are there? Clearly, > this would fall into the 'separate community effort' > category and should function without requiring effort from > you (Chuck). There's enough people floating around here > that it shouldn't be too difficult to find some volunteers > to steer this. I just set up a Wiki for another project, and it would be easy to add a Webware section to it. It's only useful if people really use it -- a critical mass has to be reached -- but if people are interested it would be easy to set up. Ian |
From: <ir...@ms...> - 2001-10-25 18:55:49
|
On Thu, Oct 25, 2001 at 01:30:40PM -0500, Ian Bicking wrote: > Tavis Rudd <ta...@ca...> wrote: > > Does anyone have experience setting up a wiki? > > I just set up a Wiki for another project, and it would be easy to add > a Webware section to it. It's only useful if people really use it -- > a critical mass has to be reached -- but if people are interested it > would be easy to set up. Our Seattle Python users' group has a wiki: http://zipcon.net/seapig We use it to decide topics for our meetings, to poll our members about the best meeting times and places, etc. We also have topics of a more permanent nature, such as how each member discovered Python, what our personal projects/skills/interests are, etc. Wikis are very convenient for this. We also have an intranet wiki at work used to build collaborative documentation, and to pool our task lists and status updates for distributed projects. It works best for documents that are short (a few screenfuls max), and that don't require precise formatting. The original wiki (WikiWiki) is a Perl CGI script. There's a Zope version called ZWiki. There are several Python versions starting with PikiPiki (the one our PIG [Python Interest Group] is using). PikiePikie and MoinMoin are enhanced forks of PikiPiki. Pyle offers logins and permissions to control write access; that's the one we're using at work. (Of course, that's against the wiki philosophy of allowing anyone to edit anything anonymously, but our management felt insecure and insisted on that.) * * * * * For doing polls, our PIG has developed this strategy: each question gets a section. Each answer gets a paragraph in that section; e.g.: Which day to meet? [0.5] Tuesday * PennyPythoneer, that's great for me (vote 1) * GeorgeBorge, I can't (vote -1) * JimBim, OK but I'd rather not (vote .5) * AnnieKate, I don't care (vote 0) Whenever somebody votes, they add their comment and add or subtract their vote from the top. They can change their vote at any time. * * * * * You don't need a lot of active people for a wiki. Just one or two people willing to build the initial set of pages, and then it will take care of itself. -- -Mike (Iron) Orr, ir...@ms... (if mail problems: ms...@ji...) http://iron.cx/ English * Esperanto * Russkiy * Deutsch * Espan~ol |
From: Chuck E. <Chu...@ya...> - 2001-10-25 21:53:08
|
At 12:15 PM 10/25/2001 -0700, Tavis Rudd wrote: >* what to do with one-shot Say what? |
From: Tavis R. <ta...@ca...> - 2001-10-25 21:56:21
|
On Thursday 25 October 2001 14:53, Chuck Esterbrook wrote: > At 12:15 PM 10/25/2001 -0700, Tavis Rudd wrote: > >* what to do with one-shot > > Say what? I was paraphrasing you: """ - 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*.""" |
From: Chuck E. <Chu...@ya...> - 2001-10-25 22:15:06
|
At 03:04 PM 10/25/2001 -0700, Tavis Rudd wrote: >On Thursday 25 October 2001 14:53, Chuck Esterbrook wrote: > > At 12:15 PM 10/25/2001 -0700, Tavis Rudd wrote: > > >* what to do with one-shot > > > > Say what? > >I was paraphrasing you: >""" >- 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*.""" Got it. But OneShot stays at is. The one liner for this is: - enable autoreloading of python modules in the persistent app server -Chuck |
From: Tavis R. <ta...@ca...> - 2001-10-25 19:06:25
|
On Thursday 25 October 2001 11:30, Ian Bicking wrote: > Tavis Rudd <ta...@ca...> wrote: > > What do people think?? Does anyone have experience > > setting up a wiki? What other options are there? > > Clearly, this would fall into the 'separate community > > effort' category and should function without requiring > > effort from you (Chuck). There's enough people > > floating around here that it shouldn't be too difficult > > to find some volunteers to steer this. > > I just set up a Wiki for another project, and it would be > easy to add a Webware section to it. It's only useful if > people really use it -- a critical mass has to be reached > -- but if people are interested it would be easy to set > up. I'm interested. Anyone else?? The email lists are great for discussion, but most of 0.7 topics will require more than just a free-flow discussion. They are complex enough that it will be a huge aid if there was a single place that someone can drop into at any time and get an overview of the issue, the target release, the status, the background & concepts, the decisions made / code written, the open issues / needed code, etc. (just like PEPs) http://dev.zope.org/ is a good model, although it's obviously larger and more complex than we can manage. We should keep the number of pages to a minimum so we don't run into a gardening problem later on. I was thinking of a central page that provides an overview plus index of open/closed projects and then a single structured page for each topic/project. Each project would have a clearly defined scope and release target (e.g. 0.7). The index would list the current status of each topic. This information would be repeated on the topic's page. Does this sound reasonable? Here's several topics we could start with: * the regression testing suite for Webware that Chuck mentioned * the URL/path parsing issue that's being discussed on Webware-devel: http://www.geocrawler.com/lists/3/SourceForge/9552/0/6904216/ * what to do with one-shot * migrating to distutils (package structure, etc.) I think each topic/project should have a 'leader' like on dev.zope.org that is responsible for keeping the project's index entry and the status blurb up to date. Cheers, Tavis |
From: Geoff T. <gta...@na...> - 2001-10-25 19:17:42
|
At 12:15 PM 10/25/01 -0700, Tavis Rudd wrote: >On Thursday 25 October 2001 11:30, Ian Bicking wrote: > > I just set up a Wiki for another project, and it would be > > easy to add a Webware section to it. It's only useful if > > people really use it -- a critical mass has to be reached > > -- but if people are interested it would be easy to set > > up. > >I'm interested. Anyone else?? The email lists are great >for discussion, but most of 0.7 topics will require more >than just a free-flow discussion. They are complex enough >that it will be a huge aid if there was a single place that >someone can drop into at any time and get an overview of >the issue, the target release, the status, the background & >concepts, the decisions made / code written, the open >issues / needed code, etc. (just like PEPs) I'd certainly try out a Wiki for Webware. I've never participated in one before, so it'll be a good learning experience :-) -- - Geoff Talvola gtalvola@NameConnector.com |
From: Ian B. <ia...@co...> - 2001-10-25 19:21:52
|
Tavis Rudd <ta...@ca...> wrote: > > I just set up a Wiki for another project, and it would be > > easy to add a Webware section to it. It's only useful if > > people really use it -- a critical mass has to be reached > > -- but if people are interested it would be easy to set > > up. > > I'm interested. Anyone else?? The email lists are great > for discussion, but most of 0.7 topics will require more > than just a free-flow discussion. They are complex enough > that it will be a huge aid if there was a single place that > someone can drop into at any time and get an overview of > the issue, the target release, the status, the background & > concepts, the decisions made / code written, the open > issues / needed code, etc. (just like PEPs) Well, what the heck, I set it up. It's at: http://webware.colorstudy.net/twiki It uses TWiki (http://twiki.sf.net), which is in Perl :(, but I had set it up before, and it seems to be well supported. It has versioning, which is a very nice feature. I'm thinking of doing the Parnassus-like page for Webware on the same site -- where people can post useful servlets they made, and post links to any other projects as well. It could potentially be done directly in the Wiki (which would be real easy), or with a Webware servlet or two. I think this might encourage more useful code sharing... not the killer application Tom was talking about, but hopefully a set of good, small, reusable pieces of code. Ian |
From: Tavis R. <ta...@ca...> - 2001-10-25 19:50:55
|
On Thursday 25 October 2001 12:24, Ian Bicking wrote: > Well, what the heck, I set it up. It's at: > > http://webware.colorstudy.net/twiki learning time ... ;) > I'm thinking of doing the Parnassus-like page for Webware > on the same site -- where people can post useful servlets > they made, and post links to any other projects as well. > It could potentially be done directly in the Wiki (which > would be real easy), or with a Webware servlet or two. > > I think this might encourage more useful code sharing... > not the killer application Tom was talking about, but > hopefully a set of good, small, reusable pieces of code. Sounds like a good idea. |
From: Tom S. <tom...@we...> - 2001-10-26 20:26:01
|
Tavis Rudd wrote: > > On Thursday 25 October 2001 12:24, Ian Bicking wrote: > > Well, what the heck, I set it up. It's at: > > > > http://webware.colorstudy.net/twiki > > learning time ... ;) > > > I'm thinking of doing the Parnassus-like page for Webware > > on the same site -- where people can post useful servlets > > they made, and post links to any other projects as well. > > It could potentially be done directly in the Wiki (which > > would be real easy), or with a Webware servlet or two. > > > > I think this might encourage more useful code sharing... > > not the killer application Tom was talking about, but > > hopefully a set of good, small, reusable pieces of code. > > Sounds like a good idea. absolutely. On good thing would also to have a page containing something like "how to write a good Webware application", so people adopt a similar style (the Webware style so to say ;-). Learning by copying good style is never bad in my opinion. -- Tom Schwaller tsc...@gn... http://www.python.de |
From: Clark C . E. <cc...@cl...> - 2001-10-25 19:51:30
|
| 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. I'm on hold doing any further investigation until a new box shows up here on Saturday or Monday (I hope). Then I'll first try OpenBSD. If this doesn't work, I'll try Debian (newest version in testing), and failing that I'll try the newest Red Hat. If all of them fail, then I'll have to do more debugging. Thank you all for your kind help. Your plans for the current and future versions sound wonderful. Best, Clark |
From: Chuck E. <Chu...@ya...> - 2001-10-25 21:48:06
|
At 10:10 AM 10/25/2001 -0700, Tavis Rudd wrote: >Python uses SIGS with communication via email lists and >PEPs. Zope uses 'projects' with communication via wikis. >Both approaches have worked wonderfully in some cases and >failed miserably in others. I feel some time invested now >in setting up something similar for Webware will pay off >big-time on the way to 1.0. > >What do people think?? Does anyone have experience >setting up a wiki? What other options are there? Clearly, >this would fall into the 'separate community effort' >category and should function without requiring effort from >you (Chuck). There's enough people floating around here >that it shouldn't be too difficult to find some volunteers >to steer this. Sure, I would like to see Webware SIGs and/or projects. We can host both the webpages, mailing lists and CVS via Webware's sourceforge area if we want. Or a project could have its own SF area and just be included in the "Webware Project Index". If someone wants to step up to be the Webware Project Curator, that would be great. > > The largest project for 1.0 is an automated regression > > test suite for WebKit. > >Ah, forgotten about that one. I agree! Use of unittest >has been a huge blessing for Cheetah dev. This is >something that could proceed independently of the main >Webware coding and would also be beneficial to Webware >users developing their own applications. > >I think I've convinced Steve Purcell to change the license >of his HTTPSession.py from the GPL to a Python/Webware >style one so it can be used here. What were your concerns >about the structure of the package again? I forget off the top of my head. Something to do with concepts like request, response and useragent which I don't think were captured exactly as they should have been. It wasn't a huge deal, just some tweaks. I think Steve even agreed with my ideas, but I don't know that any code ever got changed. You'll have to dig through mailing lists for the details. Or start the WebKit Regression Test project and I'll join as a member and participate. ;-) > > >** 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. ;-) > >What are they??? :-) You were going to post your notes at >one stage. Yeah, but then I keep getting swamped with other things. -Chuck |
From: Tavis R. <ta...@ca...> - 2001-10-26 17:03:54
|
On Thursday 25 October 2001 14:47, Chuck Esterbrook wrote: > > Sure, I would like to see Webware SIGs and/or projects. > We can host both the webpages, mailing lists and CVS via > Webware's sourceforge area if we want. Or a project could > have its own SF area and just be included in the "Webware > Project Index". > > If someone wants to step up to be the Webware Project > Curator, that would be great. Sure, what the hell ... I'll do some work on setting something up at the end of next week. > > > The largest project for 1.0 is an automated > > > regression test suite for WebKit. > > > >Ah, forgotten about that one. I agree! Use of unittest > >has been a huge blessing for Cheetah dev. This is > >something that could proceed independently of the main > >Webware coding and would also be beneficial to Webware > >users developing their own applications. > > > >I think I've convinced Steve Purcell to change the > > license of his HTTPSession.py from the GPL to a > > Python/Webware style one so it can be used here. What > > were your concerns about the structure of the package > > again? > > I forget off the top of my head. Something to do with > concepts like request, response and useragent which I > don't think were captured exactly as they should have > been. It wasn't a huge deal, just some tweaks. I think > Steve even agreed with my ideas, but I don't know that > any code ever got changed. > > You'll have to dig through mailing lists for the details. > Or start the WebKit Regression Test project and I'll join > as a member and participate. ;-) more on this next week. > > > >** 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. ;-) > > > >What are they??? :-) You were going to post your notes > > at one stage. > > Yeah, but then I keep getting swamped with other things. well, are you going to post your notes? ;-) |
From: Chuck E. <Chu...@ya...> - 2001-10-26 21:47:28
|
At 10:11 AM 10/26/2001 -0700, Tavis Rudd wrote: > > Yeah, but then I keep getting swamped with other things. > >well, are you going to post your notes? ;-) Not right now. There are more pressing tasks at hand that will be delivered first anyway, so I might as well focus on them. -Chuck |
From: <ir...@ms...> - 2001-10-25 16:21:03
|
On Wed, Oct 24, 2001 at 06:15:11PM -0700, Tavis Rudd wrote: > * packaging Cheetah 1.0 and FunFormKit 1.0 with the Webware > distro (once they're released) As long as Cheetah can continue its development at its own pace, and not be held back to adhere to Webware's release schedule. I like Chuck's idea for a "Webware Deluxe" package that would include Cheetah. However, perhaps this also could be done as its own project, "Python Web Development-in-a-Box", integrating software from third parties into one easy-to-install package with overall umbrella documentation and examples, similar to what the Linux distributions do. They could also provide feedback to the original projects on ways that software could be made to play together with others. Of course, with the proposed restructurings in the air (e.g., distutils compatibility), these would profoundly affect not only Webware, but how Webware fits into this "Deluxe" package. So perhaps it's not feasable to spin off the Deluxe package until after the restructurings are done. There are at least two targets for an integrated package: 1) Those who want to install it in their home directory for personal use. 2) Those who want to install it system-wide so all their users can build their own sites. We've talked about this before, how there's some issues with how to isolate the distributed objects so they can be upgraded while keeping each user's objects and configuration separate. Perhaps this is an issue an integration project can tackle, and let Webware concentrate on other development. Provided, of course, that the integrators can do most of their work "around" Webware rather than changing its innards. We just need to make sure it handles both. Or maybe get a "Personal Deluxe Package" out the door first, and then make a server version. -- -Mike (Iron) Orr, ir...@ms... (if mail problems: ms...@ji...) http://iron.cx/ English * Esperanto * Russkiy * Deutsch * Espan~ol |