On Wed, 2005-02-02 at 14:35 -0600, Ian Bicking wrote: > I brought up the idea of a reference/common/standard set of WSGI > middleware on the Web-SIG list, but didn't get much reaction. It could > be pressed harder.
absolutely! > I'll copy my message from there: > Some candidates I imagine: > > * Sessions middleware > * Logging middleware/library (based on the standard library of course) > * Error reporting middleware/library > * Test frameworks (?) > * A file application (handling If-Modified-Since, etc) > * A proxy application > * Libraries for parsing query strings and all that. Most of what is in > Phillip's wsgiref. > * Authentication (this would be on the ambitious end) > * URL parsers (several, but maybe we could distill this down to a few > primary models for parsing) > * And maybe a few of the more boring servers, like the CGI server, which > will otherwise be homeless (or widely repeated). That's a pitty. A lot of good ideas. Maybe one should ask what would be the result if the Python community does not get its act together to implement this common foundation. Maybe it's not "Python - batteries inlcuded" anymore but "many incompatible battery formats" at the moment and eternal competition on the battery level does not look very attractive to me. > >> I have to admit, I get frustrated these days when I work on the Webware > >> core :( > > > > > > What exactly is frustrating you? Is there a remedy for that frustration? > > Well, it's not the way I want it to be. It's hard to test. It has lots > of unused or redundant interfaces. It's not well documented or well > documentable. It combines concepts that don't need to be combined. > It's hooks for extension are sometimes misdesigned or fragile. Some > things aren't as convenient as I'd like them to be, yet fixing that > would mean even more redundant interfaces. There's a lot of good parts > too -- I'm basically pretty happy with the servlet model. I like > SitePage. Component actually works better than I'd expect, even those > it's patched on top of something that wasn't designed for it > (WebKit.Page). But while I feel I can refine some pieces of my own > applications, it doesn't create a framework for others to work with a > more refined layout. > With my frustration with documentation, I hate trying to explain > something when there's not a good reason for it. I feel a need to > apologize for cruft. And there's just too many little details to > explain, without an overriding direction or purpose to serve as a > framework for those ideas. OK, I get the picture. Thanks for input. <philosophy> Documenting, cleaning up and explaining the architecture of Open Source projects is always a hard thing. I gave a lot of talks lately about what I call the architectural nightmare of Open Source Projects which shows up when you have to integrate a lot of different technology stacks to achieve higher level enterprise functionality. The same problems happen of course - on a much smaller scale though - in the subprojects themselves. Fighting the architectural frustration is unfortunately a never ending story but the only way to make progress. ;-) </philosophy> Tom ------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ Webware-discuss mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/webware-discuss
