Great comments, something meaty with a slightly philosophical side we can bite into...
At a certain point when you add in a lot of changes, will it be Webware? I'll be honest, part of what I want from WSGI is the possibility to move beyond the Webware interface without splitting environments; which is why I want to have something that is backward compatible with Webware while leaving the possibility for using novel new techniques alongside it. Because I can imagine a better interface, but I don't want to break Webware trying to get there. That might have made sense several years ago, but it doesn't make sense now, that's just not the place Webware is strategically anymore.
So you are saying, if we develop WSGIKit, or Webware itself and evolve it into something that is considerably different from Webware today, should we still call it Webware? Well, I ask does it matter what we call it? I mean it seems like a bit of a word game, or maybe I don't understand what you mean. Perhaps "Webware" has a special meaning to you since you've been working on it far longer than I have (a few months)? You mentioned "it wouldn't be Webware anymore" when I talked about if Webware could be changed from being servlet centered. I wonder if Webware symbolizes a certain approach to you that I don't get?
And, really, while I want to support Webware applications indefinitely, it might not be that long before I'm programming with something else. Achieving that incrementally is part of what I want to do with WSGIKit -- so that Webware melts away more than me just choosing (or making) Yet Another Framework. WSGIKit supports a thin Webware interface over a bunch of neutral components, which means choosing Webware at that point would be more of an aesthetic choice than a platform choice. Which I think is a good way to ask users to make that choice. The way things are now, it's more about weighing the shortcomings rather than looking for the advantages.
I definitely see where you are coming from about WSGIKit as an experiment. We need a place to try new things and make our tools better. I think this might be the heart of the issue. We as developers build our tools and Webware is a tool (the collective) we have built. It does 90% of what I need, but there are some sharp edges that nick me all the time. So what is my best course of action? Write a new web framework myself? Nah takes too long. I have more important stuff to do. Change Webware on my machine to make it do what I want to do? That's a good option. I get done what I need to do, and get the advantage of Webware's code. But if I am modifying Webware to fix sharp edges, maybe others feel the same way. Then I should be helpful and contribute my changes back into Webware. On the other hand, maybe the sharp edges that bug me are just what other people like. Huh, what to do?
So here is what I think of Webware.
I like it because it is simple to use, simple to understand mostly so I can write a web application in it quickly. It seems very mature, by that I mean it is stable and reliable, it has good error handling, is fast, and has already done the work for me in the areas of database modeling (MiddleKit), templates (PSP and Cheetah).
Some thinks I don't like about Webware or I would like to fix, in order of priority:
_High_
• There are few automated tests, but I'm already well on my way to fixing that
• the configuration and layout of files seems messy, such as the working files mixed in with the source files.
• Installation should be easier, better documented, and there should be a stand-alone version for development and testing purposes.
• PSP Templates shouldn't have to always be servlets. I would like to choose some PSP files to be servlets, and other PSP files be templates that I use elsewhere. E.g. one PSP file is an interface for slash-dot style discussions but that is not a servlet itself. It is a template used by my servlet that displays articles.
_Medium_
• There are a lot of special cases in the code made for Contexts, but I don't see any value to them. It seems to me just different folders, or different instances of Webware achieves the same thing, but cleaner and more reliably.
• Webware has it's own logging but I'd prefer to replace it with the new standard logging package
• It's not clear how to define my own error pages
I like the idea of WSGIKit, it sounds like you have stripped it down to the minimum and I love minimalism. My current hesitation is whether my time is better spent working on Webware or WSGIKit. WSGIKit sounds more ideal, but would require more work to get it doing what I need for my project. Whereas Webware is almost doing what I need, but as I say, there are sharp bits that bug me.
-winston
_________________________________________
winston wolff - (646) 827-2242 - http://www.stratolab.com - learning by creating
