Winston Wolff wrote:
> 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
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
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:
> • 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
> • 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
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.
> • 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 / ianb@... / http://blog.ianbicking.org