Hi Ian-
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)?
When I say "Webware", I mean the Webware/WebKit interface. Not really any more than that; I don't think of it as a philosophy or anything so fancy.
The other side is that Webware has a bunch of other features, like the AppServer, the exception handler, etc. These I think of as features, but not part of the essence. Another framework could reach parity with Webware fairly easy in those terms, but if matches the Webware interface then it "is" Webware. At least, that's the way I think of it when I think of WSGIKit.
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?
More mechanically. You can build things on top of Webware reasonably easily. It's not always the most elegent way -- e.g., using a single servlet that dispatches to other objects. But I think that's okay, I think Webware is reasonably simple to layer things on top of.
There's a problem though -- if you do that, that's fine for you. But it's quickly become hard to share code at that point, because all of your code will be built on metaphors that are specific to you. It's like you've made your own framework. Which is fine, and it's a lot easier than starting from scratch, but your application is not "Webware" in my mind.
The really crappy part is that this sub-framework will appeal to only a portion of the Webware audience, which is a small portion of the Python audience. You're splitting your audience into every smaller chunks.
After writing this, I realize the biggest reason I'm interested in WSGI and WSGIKit is because I don't want to split my audience, I'm tired of that. I accept and am okay that my audience is people who are using Python, but if it's just people who use Python and have chosen Webware, that's too small a chunk. And I don't like the idea that first you choose your framework, then you choose the other libraries based on that; it's not good for users either.
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.
Not an experiment as much as a foundation for experiments, as well as a foundation for legacy APIs or anything else.
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?
At different times I've less or more ambitious about making changes to Webware in an effort to advance it. It doesn't always work out. For instance, I've never felt happy about URLParser. I think it's neat, and you can do interesting things with it, but I haven't done what I've needed to do to make it right for Webware. It's made me reluctant to do other things as part of the core, because I'm afraid I'll just mess things up for other people, and it's better to leave it alone and build abstractions on top of what is, instead of changing what is.
Anyway, that's part of how I've resolved (or not resolved) those questions.
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
System tests can be added; I think it's hard to add unit tests to the current Webware architecture. Generally I prefer unit tests, though of course system tests are still way better than nothing (or at least nothing automated).
• the configuration and layout of files seems messy, such as the working files mixed in with the source files.
Yes; MakeAppWorkDir improves things a great deal, but the implementation is quite hackish, and there's no reason for Webware to support anything *but* MakeAppWorkDir (or an analogous layout). And while it's better, it's still not terribly Unix-y. Though actually it's grown on me a bit; when apps go into maintenance mode, it's nice to be able to shove all the files together in a single directory and forget about them. The Unix-y way means sharing files, but disk space is cheap and maintenance time isn't.
WSGIKit should resolve this. Though tight now the layout is nearly non-existant, because it's doing less (no access logs, no error logs, no caching, sessions dumped in /tmp).
• Installation should be easier, better documented, and there should be a stand-alone version for development and testing purposes.
Certainly. WSGIKit is very easy to install, what with a server that you just give a file path to. It'll be a little more complicated when it has a daemon mode, configuration, etc., but still simpler I think.
• 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.
PSP is kind of problematic. It doesn't have a champion, and hasn't for years. If I wanted something PSP-like, I'd probably use Spyce. I don't really like templates as servlets; using separate templates leads to a nice MVC split, where the servlet is the controller, your Webware/web-neutral libraries are the model, and the templates are the view. I'm happy working that way.
_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.
I agree. Contexts were an idea that was never really flushed out. WSGIKit has a configuration system (implemented but not yet used) that allows for nested configuration, so you could have localized configuration (which was an original intention for Contexts), but overriding things at any point in the URL.
• Webware has it's own logging but I'd prefer to replace it with the new standard logging package
Certainly Webware's logging is pretty silly.
• It's not clear how to define my own error pages
Mmm... Component allows you to do this. LoginKit is an example, if you raise HTTPAuthorizationRequired, it will forward to a servlet. It uses general methods of Component.cpage.CPage and Component.component.Component to do this. Though it only really works for known and expected exceptions -- if you just want to display a different error page than the default message when you get unexpected errors, then it won't help. If that's what you're looking for, I expect it would be a fairly easy modification to make to Webware.
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.
Well, it depends on what your motivations and schedule are, and where you see your project going. If you are willing to deal with some rough edges for now in WSGIKit, with the potential to clean up all sorts of edges ultimately, then it might be a good fit. If you are focused on your project, and Webware is just a useful tool, then maybe not; but then, you probably wouldn't be active in this discussion if that was the case. There's also a middle ground, where you both soften Webware's edges and move some of its functionality to WSGIKit at the same time; if you understand and can simplify code in Webware, you'll have figured out enough to move it over to WSGIKit at the same time.
-- Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org
------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ Webware-discuss mailing list Webware-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/webware-discuss
