Geoff wrote:
>- Many of the differences in your design sound very similar
>to the multi-app stuff that Jay has been working on.
I haven't looked closely at Jay's implementation, but many
the design ideas are the same. If we go ahead with
finishing this refactoring off it would be great to go
through the equivalent classes of the two implementations
and synthesize the best elements.
Jay, what was the URL again? Did you get anymore feedback?
Also, can you spot any obvious flaws in the way output
streaming is handled in this code? The input streaming is
handled exactly as you implemented it in WebKit, but for
the output I just created a buffered write-mode file object
from the socket connection and mapped its write and flush
methods into the Response object. It seems to work fine,
but I haven't tested it with large outputs yet.
> - Distutils support is a good thing.
Good :-) Unfortunately, refactoring for Distutils makes
patching against the existing code-base in the CVS rather
difficult. The directory structure is different and most
of the changes are highly interrelated.
What's the best way to proceed from here? I'd like to get
this code into a CVS somewhere so it's not just me
tinkering around and making arbritary design decisions.
Getting it in a CVS would allow division of labour on this.
We could flesh out the TODO list and claim sections of it
to work on. Should we setup a new branch in the Webware
CVS or a temporary sourceforge project with a separate CVS?
I prefer the former as it emphasizes the similarities and
prevents people from getting the impression that this is a
fork.
There's a few areas that I've neglected completely so far
as I felt it was better to have them worked on by someone
who fully understands and uses them: e.g. request
forwarding.
>- I really like config files to be in Python syntax. Any
>reason you went with a different format as the default?
>(I did notice that you also allow Python syntax as an
>option. I'd vote for that as the default.)
I found the syntax to be easier to read in the .ini format,
but Python syntax does offer more flexibility. How about
providing the annotated and sample config files in both
formats and let people choose from there?
BTW, some of the new setting names will probably need
discussion to get the semantics sorted out.
>- You mention that existing servlets will work even though
>the package structure has changed. If this does get
>incorporated into Webware, it ought to display a
>DeprecationWarning that explains how to switch to the
>new package structure. Maybe it already does this.
I hadn't thought about it, but that's a wise idea. It
should be easy to add in.
Tom Schwaller wrote:
>Wow, Tavis! I just installed it in my lunch break and
>tested the performance with ShowTime.py (215
>requests/second for ab -n 100 -c and almost 200
>requests/second for ab -n 1000 -c 20).
>This is of course no serious test, but shows the peak
>performance of the code. You really did some magic here...
>WebwareCVS gives 70 requests/second for almost the same
>example and an older Webware version gives 30
>requests/second.
Actually the speed diff isn't that huge. That ShowTime.py
example in the new framework isn't doing any of the
processing from the Example.py base class as there are some
changes / holes in the Application API (loading plugins,
listing contexts, etc.) that currently prevent that code
from running as is. That's the 10% that I wrote about. An
increase of 70 req/sec rather than 145 is more likely for
that example.
>The configuration is much easier. I have one question
>though: What is the difference between DEFAULT_APP and
>ROOT_APP?
DEFAULT_APP is exactly the same as WebKit's 'default'
context. http://blarg.com/WK/myServlet.py. ROOT_APP is
the application that processes requests that are passed
through the SCRIPT_NAME cgi var rather than through
PATH_INFO. It allows http://blarg.com/myServlet.py to map
directly into an application without needing to do any
mod_rewrite magic. See Jeff's posts from a few days ago
for more on that.
Cheers,
Tavis
_______________________________________________
Webware-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/webware-devel
