From: Winston W. <st...@ob...> - 2004-12-29 10:21:18
|
I'd like to do some cleaning up of Webware after our v0.9 build. The automated tests are good preparation to that cleanup. When there are a good set of test cases in place, I'd like to make Webware easier to install. I'm also improving my Cheetah ServletFactory which I can add as a kit. And I have a very simple script that functions like Ant or make--it's a place to put short scripts when developing such as "generate MiddleKit sql", "run sql on my database", "clean up temporary files", "run python interactively with the same python path as the appserver", "upload my web application to the production server." "run webware, but using the CVS version instead of v0.81" What improvements would other people like? I will compile a list and post it on the wiki. I'll also sort it in priority order as judged by the enthusiastic responses on this list. -winston _________________________________________ winston wolff - (646) 827-2242 - http://www.stratolab.com - learning by creating |
From: Winston W. <win...@ca...> - 2004-12-29 10:18:30
|
I'd like to do some cleaning up of Webware after our v0.9 build. The automated tests are good preparation to that cleanup. When there are a good set of test cases in place, I'd like to make Webware easier to install. I'm also improving my Cheetah ServletFactory which I can add as a kit. And I have a very simple script that functions like Ant or make--it's a place to put short scripts when developing such as "generate MiddleKit sql", "run sql on my database", "clean up temporary files", "run python interactively with the same python path as the appserver", "upload my web application to the production server." "run webware, but using the CVS version instead of v0.81" What improvements would other people like? I will compile a list and post it on the wiki. I'll also sort it in priority order as judged by the enthusiastic responses on this list. -winston _________________________________________ winston wolff - (646) 827-2242 - http://www.stratolab.com - learning by creating |
From: Robert F. <fo...@zi...> - 2004-12-29 12:34:33
|
hi, not exactly an improvement, but rather a bugfix: i think the issue was already mentioned once on this list. mod_webkit for apache 2 does not work with the apache 2 installation of SuSE linux distribution 9.0. i don't know, whether anyone has solved this very specific problem. admittedly, this is not exactly, what you asked for. your post just pulled that problem back into my mind (at present i simple use the cgi adapter). regards, robert Winston WOLFF wrote: > I'd like to do some cleaning up of Webware after our v0.9 build. The > automated tests are good preparation to that cleanup. When there are a > good set of test cases in place, I'd like to make Webware easier to > install. I'm also improving my Cheetah ServletFactory which I can add > as a kit. And I have a very simple script that functions like Ant or > make--it's a place to put short scripts when developing such as > "generate MiddleKit sql", "run sql on my database", "clean up > temporary files", "run python interactively with the same python path > as the appserver", "upload my web application to the production > server." "run webware, but using the CVS version instead of v0.81" > > What improvements would other people like? I will compile a list and > post it on the wiki. I'll also sort it in priority order as judged by > the enthusiastic responses on this list. > > -winston > _________________________________________ > winston wolff - (646) 827-2242 - http://www.stratolab.com - learning > by creating |
From: Ian B. <ia...@co...> - 2004-12-29 19:09:09
|
While we're talking about improvements, I might re-note the existance of WSGIKit: http://svn.colorstudy.com/trunk/WSGIKit/ I'm personally convinced that this should be the future of Webware (and, in a general architectural sense, Python web programming as a whole). It offers a few current advantages over Webware: * Deployment with different servers. * Simple CGI and multiprocess deployment (e.g., embedding Webware in mod_python). * Some framework neutrality; in time it should be possible to embed other frameworks under Webware, and vice versa. (Well, you can do it now, there just aren't that many other frameworks to embed.) * Decoupled functionality. Dependencies between components are quite minimal. * Easier testability. In part because of the decoupled functions, but also because WSGI provides a spec that makes fake requests very easy to construct. * Easier application testability (functional tests), again because WSGI requests are easy to simulate. * Distutils-installable. * Removes some of the installation cruft we have now. * Mostly backward-compatible. There are some missing corners of the Webware API, but that can be fixed. The whole MakeAppWorkDir thing goes away (for better or worse), and Contexts disappear. But I believe most applications should be able to run under it without modification, or only with small modifications. * It uses spaces not tabs ;) Missing parts: * No PSP. Shouldn't be that hard, but I don't use it so I haven't ported it. The hooks are there (urlparser.URLParser.register_constructor). * No configuration, except by passing in keyword arguments to various constructors. I have a config-file parser that I haven't started using, but should allow lots of cool things. Configuration won't be backward-compatible. This is the thing at the top of my list for WSGIKit. * Some parts have sub-optimal implementations, like the session handler. It works, but it may be slow. Certainly WSGIKit isn't ready to replace the main Webware at this time. But I think it could reach that point reasonably quickly, because the architecture is easier to test. Progress so far has been quite good -- which isn't to say it's developed super-fast, but I haven't put a ton of time into it either. -- Ian Bicking / ia...@co... / http://blog.ianbicking.org |
From: <mp...@sc...> - 2004-12-30 17:49:34
|
Quoting Ian Bicking <ia...@co...>: > While we're talking about improvements, I might re-note the existance of > WSGIKit: http://svn.colorstudy.com/trunk/WSGIKit/ > I prefer Webware over other Python frameworks because of its multithreaded application server. I don't know whether that is at all compatible with the WSGI standard? Michael ---------------------------------------- This mail sent through www.mywaterloo.ca |
From: Ian B. <ia...@co...> - 2004-12-30 17:59:10
|
mp...@sc... wrote: >>While we're talking about improvements, I might re-note the existance of >>WSGIKit: http://svn.colorstudy.com/trunk/WSGIKit/ > > I prefer Webware over other Python frameworks because of its multithreaded > application server. I don't know whether that is at all compatible with the WSGI > standard? Michael Yes, WSGI (and WSGIKit) supports threaded servers. The Twisted server is threaded, and Eric has also tried a WSGIUtils server: http://www.owlfish.com/software/wsgiutils/ which is also multithreaded. -- Ian Bicking / ia...@co... / http://blog.ianbicking.org |
From: Winston W. <win...@ca...> - 2005-01-03 16:53:40
|
So regarding WSGIKit and Webware, how do you think we should proceed as far as the code base and development goes? Should we try to move Webware over to use WSGI, should we develop them in parallel? It seems to me we should at least put them in the same version control system. I prefer Subversion myself, but Sourceforge is very dependable. -winston On Dec 29, 2004, at 2:09 PM, Ian Bicking wrote: > While we're talking about improvements, I might re-note the existance > of WSGIKit: http://svn.colorstudy.com/trunk/WSGIKit/ > > I'm personally convinced that this should be the future of Webware > (and, in a general architectural sense, Python web programming as a > whole). It offers a few current advantages over Webware: > > * Deployment with different servers. > * Simple CGI and multiprocess deployment (e.g., embedding Webware in > mod_python). > * Some framework neutrality; in time it should be possible to embed > other frameworks under Webware, and vice versa. (Well, you can do it > now, there just aren't that many other frameworks to embed.) > * Decoupled functionality. Dependencies between components are quite > minimal. > * Easier testability. In part because of the decoupled functions, but > also because WSGI provides a spec that makes fake requests very easy > to construct. > * Easier application testability (functional tests), again because > WSGI requests are easy to simulate. > * Distutils-installable. > * Removes some of the installation cruft we have now. > * Mostly backward-compatible. There are some missing corners of the > Webware API, but that can be fixed. The whole MakeAppWorkDir thing > goes away (for better or worse), and Contexts disappear. But I > believe most applications should be able to run under it without > modification, or only with small modifications. > * It uses spaces not tabs ;) > > Missing parts: > > * No PSP. Shouldn't be that hard, but I don't use it so I haven't > ported it. The hooks are there > (urlparser.URLParser.register_constructor). > * No configuration, except by passing in keyword arguments to various > constructors. I have a config-file parser that I haven't started > using, but should allow lots of cool things. Configuration won't be > backward-compatible. This is the thing at the top of my list for > WSGIKit. > * Some parts have sub-optimal implementations, like the session > handler. It works, but it may be slow. > > > Certainly WSGIKit isn't ready to replace the main Webware at this > time. But I think it could reach that point reasonably quickly, > because the architecture is easier to test. Progress so far has been > quite good -- which isn't to say it's developed super-fast, but I > haven't put a ton of time into it either. > > -- > Ian Bicking / ia...@co... / http://blog.ianbicking.org > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real > users. > Discover which products truly live up to the hype. Start reading now. > http://productguide.itmanagersjournal.com/ > _______________________________________________ > Webware-discuss mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/webware-discuss > _________________________________________ winston wolff - (646) 827-2242 - http://www.stratolab.com - learning by creating |
From: Ian B. <ia...@co...> - 2005-01-03 17:23:11
|
Winston Wolff wrote: > So regarding WSGIKit and Webware, how do you think we should proceed as > far as the code base and development goes? Should we try to move Webware > over to use WSGI, should we develop them in parallel? It seems to me we > should at least put them in the same version control system. I prefer > Subversion myself, but Sourceforge is very dependable. It's hard to say how development should continue. It depends a lot on what other people think, I guess. Right now WSGIKit shares very little (no?) code with Webware, somewhat intentionally. Some of the code could be moved over -- for instance, Webware handles sessions more efficiently than WSGIKit (which loads and saves pickles for every request). And Webware has better error reporting (WSGIKit just has cgitb). I'm open to any suggestions about how to procede. I've come to quite prefer Subversion to CVS. I could move WSGIKit over to svn://w4py.org -- Ian Bicking / ia...@co... / http://blog.ianbicking.org |
From: Eric R. <th...@er...> - 2005-01-04 13:54:58
|
On 11:53 Mon 03 Jan , Winston Wolff wrote: > So regarding WSGIKit and Webware, how do you think we should proceed > as far as the code base and development goes? Should we try to move > Webware over to use WSGI, should we develop them in parallel? I think WSGIKit and Webware should be maintained in parallel. Features and innovations can be borrowed, so development in one can be ported to the other if it's appropriate. Eric |
From: Tom S. <tom...@we...> - 2005-01-05 02:02:32
|
On Tue, 04.01.2005, 08:53 -0500 Eric Radman wrote: > On 11:53 Mon 03 Jan , Winston Wolff wrote: > > So regarding WSGIKit and Webware, how do you think we should proceed > > as far as the code base and development goes? Should we try to move > > Webware over to use WSGI, should we develop them in parallel? > > I think WSGIKit and Webware should be maintained in parallel. Features > and innovations can be borrowed, so development in one can be ported to > the other if it's appropriate. +1 The overall question about Webware is the future direction this framework wants to take and what makes it different from other frameworks. I just looked once again at CherryPy-2.0-beta http://www.cherrypy.org http://mail.python.org/mailman/listinfo/python-announce-list which has some nice ideas and which people generally seem to like http://pyre.third-bit.com/pywebblog/ Is the presentation on http://colorstudy.com/docs/shootout.html what makes people think they want to give Webware a try? Are Aspects (simple solution in CherryPy) something people would like to see integrated in Webware? +1 from me Is http://www.pythonweb.org/ something worth looking at? Or are continuations On Mo, den 03.01.2005, 16:19 +0000 Nick Murtagh wrote: > Interesting, I recently came across this: > > http://www-106.ibm.com/developerworks/library/j-contin.html > > which talks about using continuations in web programming (Apache > Cocoon). It would be cool to have something like this in Python. > Should be doable with stackless, I've heard mention of people > using stackless with zope. worth putting some more effort in? Maybe using generators and annotations could make Webware much more sophisticated +1 from me just a few ideas... Tom |
From: Ian B. <ia...@co...> - 2005-01-05 04:18:03
|
Tom Schwaller wrote: > On Tue, 04.01.2005, 08:53 -0500 Eric Radman wrote: > >>On 11:53 Mon 03 Jan , Winston Wolff wrote: >> >>>So regarding WSGIKit and Webware, how do you think we should proceed >>>as far as the code base and development goes? Should we try to move >>>Webware over to use WSGI, should we develop them in parallel? >> >>I think WSGIKit and Webware should be maintained in parallel. Features >>and innovations can be borrowed, so development in one can be ported to >>the other if it's appropriate. > > > +1 > > The overall question about Webware is the future direction this > framework wants to take and what makes it different from other > frameworks. I just looked once again at CherryPy-2.0-beta > > http://www.cherrypy.org > http://mail.python.org/mailman/listinfo/python-announce-list > > which has some nice ideas and which people generally seem to like > > http://pyre.third-bit.com/pywebblog/ FWIW, I think it might also have to do with the fact he's implemented the code a few times before, so everything will just feel smoother. Oh, and he was using SQLObject at the same time he used CherryPy ;) And he had a tutorial about making a database-backed website, which is what everyone wants to do, but a lot of frameworks don't properly focus on. Including Webware. > Is the presentation on > http://colorstudy.com/docs/shootout.html > > what makes people think they want to give Webware a try? I tried to be neutral in that, and ended up not putting as much opinion as might be useful. But then, it's kind of out-of-date as well. If I was going to push Webware, I'd talk about the stability of its interface, its age, the community, and the availability of experienced consultants. It's probably second to Zope from that perspective (in the Python world, though maybe Quixote is second). I wish Webware was doing better on all of those attributes, and it's kind of lame how far the second place is from the first place. And it's lame how far Zope is from PHP; Python is missing out big, any way you look at it. But that's another topic. > Are Aspects (simple solution in CherryPy) something people > would like to see integrated in Webware? I don't like aspects; I'm not sure they exist anymore in CherryPy 2? They are basically macros, and don't go well with Python. > +1 from me > > Is http://www.pythonweb.org/ something worth looking at? I think it's Just Another Framework, that happens to be using what looks like a canonical name. > Or are continuations > > On Mo, den 03.01.2005, 16:19 +0000 Nick Murtagh wrote: > >>Interesting, I recently came across this: >> >> http://www-106.ibm.com/developerworks/library/j-contin.html >> >>which talks about using continuations in web programming (Apache >>Cocoon). It would be cool to have something like this in Python. >>Should be doable with stackless, I've heard mention of people >>using stackless with zope. > > > worth putting some more effort in? They won't be compatible with Webware. Continuation-based frameworks are always independent frameworks, as it's a very different structure from a normal framework. I don't know if they'd even be compatible with WSGI (though maybe they would; but not everything is -- async ala Twisted is not exactly compatible). > Maybe using generators and annotations could make Webware much more > sophisticated There's some ideas here. I'm very interested in using decorators instead of subclassing, for instance. And there's other ways of making things more functional. I've been using Component and LoginKit in the w4py.org repository, and I find them useful. But I don't think anyone else uses them. 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. 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. -- Ian Bicking / ia...@co... / http://blog.ianbicking.org |
From: Winston W. <win...@ca...> - 2005-01-05 05:04:41
|
Hi Ian- Great comments, something meaty with a slightly philosophical side we=20 can bite into... > At a certain point when you add in a lot of changes, will it be=20 > Webware? I'll be honest, part of what I want from WSGI is the=20 > possibility to move beyond the Webware interface without splitting=20 > environments; which is why I want to have something that is backward=20= > compatible with Webware while leaving the possibility for using novel=20= > new techniques alongside it. Because I can imagine a better=20 > interface, but I don't want to break Webware trying to get there. =20 > That might have made sense several years ago, but it doesn't make=20 > 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=20= it into something that is considerably different from Webware today,=20 should we still call it Webware? Well, I ask does it matter what we=20 call it? I mean it seems like a bit of a word game, or maybe I don't=20 understand what you mean. Perhaps "Webware" has a special meaning to=20 you since you've been working on it far longer than I have (a few=20 months)? You mentioned "it wouldn't be Webware anymore" when I talked=20= about if Webware could be changed from being servlet centered. I=20 wonder if Webware symbolizes a certain approach to you that I don't=20 get? > And, really, while I want to support Webware applications=20 > indefinitely, it might not be that long before I'm programming with=20 > something else. Achieving that incrementally is part of what I want to=20= > do with WSGIKit -- so that Webware melts away more than me just=20 > choosing (or making) Yet Another Framework. WSGIKit supports a thin=20= > Webware interface over a bunch of neutral components, which means=20 > choosing Webware at that point would be more of an aesthetic choice=20 > than a platform choice. Which I think is a good way to ask users to=20= > make that choice. The way things are now, it's more about weighing=20 > the shortcomings rather than looking for the advantages. I definitely see where you are coming from about WSGIKit as an=20 experiment. We need a place to try new things and make our tools=20 better. I think this might be the heart of the issue. We as=20 developers build our tools and Webware is a tool (the collective) we=20 have built. It does 90% of what I need, but there are some sharp edges=20= that nick me all the time. So what is my best course of action? Write=20= a new web framework myself? Nah takes too long. I have more important=20= stuff to do. Change Webware on my machine to make it do what I want to=20= do? That's a good option. I get done what I need to do, and get the=20 advantage of Webware's code. But if I am modifying Webware to fix=20 sharp edges, maybe others feel the same way. Then I should be helpful=20= and contribute my changes back into Webware. On the other hand, maybe=20= the sharp edges that bug me are just what other people like. Huh, what=20= 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=20= can write a web application in it quickly. It seems very mature, by=20 that I mean it is stable and reliable, it has good error handling, is=20 fast, and has already done the work for me in the areas of database=20 modeling (MiddleKit), templates (PSP and Cheetah). Some thinks I don't like about Webware or I would like to fix, in order=20= of priority: _High_ =95 There are few automated tests, but I'm already well on my way to=20= fixing that =95 the configuration and layout of files seems messy, such as the=20 working files mixed in with the source files. =95 Installation should be easier, better documented, and there should=20= be a stand-alone version for development and testing purposes. =95 PSP Templates shouldn't have to always be servlets. I would like = to=20 choose some PSP files to be servlets, and other PSP files be templates=20= that I use elsewhere. E.g. one PSP file is an interface for slash-dot=20= style discussions but that is not a servlet itself. It is a template=20 used by my servlet that displays articles. _Medium_ =95 There are a lot of special cases in the code made for Contexts, = but=20 I don't see any value to them. It seems to me just different folders,=20= or different instances of Webware achieves the same thing, but cleaner=20= and more reliably. =95 Webware has it's own logging but I'd prefer to replace it with the=20= new standard logging package =95 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=20= the minimum and I love minimalism. My current hesitation is whether my=20= time is better spent working on Webware or WSGIKit. WSGIKit sounds=20 more ideal, but would require more work to get it doing what I need for=20= my project. Whereas Webware is almost doing what I need, but as I say,=20= there are sharp bits that bug me. -winston _________________________________________ winston wolff - (646) 827-2242 - http://www.stratolab.com - learning by=20= creating |
From: Ian B. <ia...@co...> - 2005-01-05 07:02:48
|
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 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 / ia...@co... / http://blog.ianbicking.org |
From: Max I. <ma...@uc...> - 2005-01-05 11:07:30
|
Ian Bicking wrote: > 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. This describes my experience with Webware/WebKit *precisely*. Thanks for freeing me from trying to express the same things in the same clear manner. ;-) IMO, I think webware could be left in a maintaince mode without any major undertaking: 1. it fulfills premises OK for the existing user base 2. it is 'complete' in a sense 3. it would be plain hard to re-architecture / rework it, esp. considering the fact you have to remain backward-compatible 4. There is not many folks eager to *do* this (in contrast with folks *eager* to do this, myself included). 5. It's just not that great as a solid foundation for major changes. Instead, I'd like to see WSGI maturing. To me, ROI from this project would be much higher. The WSGI is small but a functional, working system. If Ian (and others devs) avoid a second-system effect, over-engineering it, which I'm pretty sure about, it seems really promising. Just my 2 cents. |
From: Tom S. <tom...@we...> - 2005-01-06 23:54:12
|
Folk, thanks for the very interesting input! For me: Webware = a nonbloated Python framework with an AppServer, WebKit and some Java-like APIs (Servlets, etc. that's why I am missing Portlets) + some very clever people on this list giving good input and feedback. On 04.01.2005, 22:17 -0600 Ian Bicking wrote: > If I was going to push Webware, I'd talk about the stability of its > interface, its age, the community, and the availability of experienced > consultants. It's probably second to Zope from that perspective (in the > Python world, though maybe Quixote is second). I wish Webware was doing > better on all of those attributes, and it's kind of lame how far the > second place is from the first place. And it's lame how far Zope is > from PHP; Python is missing out big, any way you look at it. But that's > another topic. Yes, unfortunately. 3 years ago I hoped there would be much more people using Webware, but for that to happen you need much more out of the box killer applications (like Plone (Zope), Typo3 (PHP), Mambo (PHP), GForge (PHP),...). I will have to build a new website next week and do not have time available to develop something new. I need the usual simple stuff like News, Wikis, Blogging, RSS Syndication,... Probably I'll go for Plone once more, altough I think it is just overkill in my situation. I wish there was this "WebwareNuke" I could install in 10 minutes and start filling the website. Or did I miss something? > > Are Aspects (simple solution in CherryPy) something people > > would like to see integrated in Webware? > > I don't like aspects; I'm not sure they exist anymore in CherryPy 2? There is a file CherryPy-2.0.0b/cherrypy/lib/aspect.py, so yes, it is still there. What I like in CherryPy is # Of course we can also mount request handler objects right here! cpg.root = HomePage() cpg.root.joke = JokePage() cpg.root.links = LinksPage() Is there something analogous in Webware: I do not rememeber? > > Maybe using generators and annotations could make Webware much more > > sophisticated > > There's some ideas here. I'm very interested in using decorators > instead of subclassing, for instance. And there's other ways of making > things more functional. I've been using Component and LoginKit in the > w4py.org repository, and I find them useful. But I don't think anyone > else uses them. Hmm, you remind me to dig around there ;-) In CherryPy index.exposed = True could be done like @exposed def index(self): Having somehting in Webware like @expose("HTML", "XML", "XML-RPC", "SOAP") and having Webware handle all the magic the scene (e.g. genereating WSDL files files, etc..) could be interesting. As you mention you can avoid subclassing, e.g. in the XML-RPC example: instead of class XMLRPCExample(XMLRPCServlet): def exposedMethods(self): return ['multiply', 'add'] def multiply(self, x, y): return x * y def add(self, x, y): return x + y def divide(self, *args): return reduce(operator.div, args) you do just: class XMLRPCExample: @expose("XML-RPC") def multiply(self, x, y): return x * y @expose("XML-RPC") def add(self, x, y): return x + y def divide(self, *args): return reduce(operator.div, args) Although I do like this @ syntax ( [expose("XML-RPC")] looks nicer, but this discussion is over ;-)), this seems cleaner, since you see directly which methods are exposed. Purist would probably put that in an XML-based deployment descriptor, but is that really better?? I would prefer a simple @expose then and configure globally which exposure methods I'd like to use (e.g. "HTML" and "SOAP"). Otherwise I agree with most of the remarks in this thread, especially On 05.01.2005, 00:04 -0500 Winston Wolff wrote: > Webware has it's own logging but I'd prefer to replace it with the new > standard logging package +1 On 05.01.2005, 00:04 -0500 Winston Wolff wrote: > I have also spend some time looking at CherryPy2.0. It's simplicity > is very attractive, but when I've actually tried to use it, I feel it > is not as mature as Webware. That of course is to be expected, it's > still in "alpha". The other thing I'm not sure about is how it > handles under load since it is not multi-threaded. I think it may be > a strong contender in the future. same for me... My next TODO is to take a look at the CheetahKit (I forgot to copy it on my laptop when leaving 2 days ago ;-() Tom |
From: Ian B. <ia...@co...> - 2005-01-07 05:30:33
|
Tom Schwaller wrote: >>>Are Aspects (simple solution in CherryPy) something people >>>would like to see integrated in Webware? >> >>I don't like aspects; I'm not sure they exist anymore in CherryPy 2? > > > There is a file CherryPy-2.0.0b/cherrypy/lib/aspect.py, so yes, > it is still there. > > What I like in CherryPy is > > # Of course we can also mount request handler objects right here! > cpg.root = HomePage() > cpg.root.joke = JokePage() > cpg.root.links = LinksPage() > > Is there something analogous in Webware: I do not rememeber? Not really, but Winston asked about that sort of functionality a week or two ago, you can look in the archives for my response then; mostly you'd have to code it yourself. >>>Maybe using generators and annotations could make Webware much more >>>sophisticated >> >>There's some ideas here. I'm very interested in using decorators >>instead of subclassing, for instance. And there's other ways of making >>things more functional. I've been using Component and LoginKit in the >>w4py.org repository, and I find them useful. But I don't think anyone >>else uses them. > > > Hmm, you remind me to dig around there ;-) > > > In CherryPy > index.exposed = True > > could be done like > > @exposed > def index(self): At one point I made a subclass of Page where you didn't have to use .actions() to give the function names that are exposed, instead you can set an attribute function.action = True, or a decorator like: def action(func): func.action = True return func Which I think is exactly the same as exposed(). I thought I put that in Component.CPage, but I can't find it now, so maybe I left it out. -- Ian Bicking / ia...@co... / http://blog.ianbicking.org |
From: Winston W. <win...@ca...> - 2005-01-07 13:50:58
|
On Jan 7, 2005, at 12:30 AM, Ian Bicking wrote: > Tom Schwaller wrote: >>>> Are Aspects (simple solution in CherryPy) something people >>>> would like to see integrated in Webware? >>> >>> I don't like aspects; I'm not sure they exist anymore in CherryPy 2? >> There is a file CherryPy-2.0.0b/cherrypy/lib/aspect.py, so yes, >> it is still there. >> What I like in CherryPy is >> # Of course we can also mount request handler objects right here! >> cpg.root = HomePage() >> cpg.root.joke = JokePage() >> cpg.root.links = LinksPage() >> Is there something analogous in Webware: I do not rememeber? > > Not really, but Winston asked about that sort of functionality a week > or two ago, you can look in the archives for my response then; mostly > you'd have to code it yourself. I did indeed like that concept, and thought a long time why we couldn't do it in Webware. The reason you can't do it in Webware but you can do it in CherryPy is that CherryPy all runs in one thread whereas Webware uses multiple threads. In CherryPy, if you only have one thread, there is just one instance of each page. Webware caches multiple instances of each page though, to handle multiple simultaneous requests. So if you have multiple instances of a page, you can't say root.joke = JokePage() because that is linking one instance of 'root' to one instance of 'joke'. The solution I came up with is the create an index of the site so for any page, I can ask the index, "what is my parent page?" or "who are all my ancestors up to the root" so I can make bread crumbs for navigation and so forth. -winston |
From: Thomas E J. <tho...@gm...> - 2005-01-06 17:46:33
|
On Tue, 04 Jan 2005 22:17:43 -0600, Ian Bicking <ia...@co...> wrote: <snip> > There's some ideas here. I'm very interested in using decorators > instead of subclassing, for instance. And there's other ways of making > things more functional. I've been using Component and LoginKit in the > w4py.org repository, and I find them useful. But I don't think anyone > else uses them. > So you know. At my current job we use both Component and LoginKit. We have extracted any framework we could from Page style classes into Components. It has worked very well for us. We even turned FormKit's mix-in into a Component. At any rate just to voice some more support for them. <snip> |
From: Winston W. <win...@ca...> - 2005-01-10 15:54:27
|
Where is this repository? -winston >> There's some ideas here. I'm very interested in using decorators >> instead of subclassing, for instance. And there's other ways of >> making >> things more functional. I've been using Component and LoginKit in the >> w4py.org repository, and I find them useful. But I don't think anyone >> else uses them. >> > > So you know. At my current job we use both Component and LoginKit. > We have extracted any framework we could from Page style classes into > Components. It has worked very well for us. We even turned FormKit's > mix-in into a Component. At any rate just to voice some more support > for them. > > _________________________________________ winston wolff - (646) 827-2242 - http://www.stratolab.com - learning by creating |
From: Ian B. <ia...@co...> - 2005-01-10 17:09:29
|
Winston Wolff wrote: > Where is this repository? svn://webwareforpython.org/Component (& /LoginKit) -- w4py.org and webwareforpython.org are the same machine. -- Ian Bicking / ia...@co... / http://blog.ianbicking.org |
From: Winston W. <win...@ca...> - 2005-01-05 04:28:07
|
Thanks for the feedback Tom and others. Here are some thoughts I have. Also, I've summarized things so far on the wiki (http://wiki.w4py.org/featuresafterv09.html). Tom Schwaller wrote: > The overall question about Webware is the future direction this > framework wants to take and what makes it different from other > frameworks. I just looked once again at CherryPy-2.0-beta I have also spend some time looking at CherryPy2.0. It's simplicity is very attractive, but when I've actually tried to use it, I feel it is not as mature as Webware. That of course is to be expected, it's still in "alpha". The other thing I'm not sure about is how it handles under load since it is not multi-threaded. I think it may be a strong contender in the future. > Or are continuations Continuations seem to be something interesting for web developers, but not something that Webware should be concerned with. I like Webware to do it's one thing only and well. > Maybe using generators and annotations could make Webware much more > sophisticated What would we use these for? _________________________________________ winston wolff - (646) 827-2242 - http://www.stratolab.com - learning by creating |
From: lloyd <sub...@tw...> - 2005-02-19 21:23:41
|
Ian Bicking wrote: > I'm personally convinced that this should be the future of Webware (and, > in a general architectural sense, Python web programming as a whole). It > offers a few current advantages over Webware: [...] > * Mostly backward-compatible. There are some missing corners of the > Webware API, but that can be fixed. The whole MakeAppWorkDir thing goes > away (for better or worse), and Contexts disappear. is that a good thing (contexts going away)? recently i was looking over the (abandoned?) "webware experimental refactoring" project, and it had some interesting improvements that, to me, seemed like a natural progression for webware: - contexts become "applications" - get their own sessions and state; - multiple applications/contexts can run under a single server instance; improvements to webware after 0.9 - - formalized method for executing (context/)application-specific code once on startup, with access to various webware components. (what's the recommended way to do this now? stick it in a site page at module level?) - out-of-the-box connection pooling - get webware into debian's repository? :-) these are suggestions from a lowly webware user, not a webware developer... take them for what they're worth... |
From: Winston W. <win...@ca...> - 2005-02-19 23:37:18
|
> is that a good thing (contexts going away)? Either they should go away, or become a mechanism for web applications. Right now they don't do anything but cause complexity. > recently i was looking over the (abandoned?) "webware experimental > refactoring" project, and it had some interesting improvements that, > to me, seemed like a natural progression for webware: > > - contexts become "applications" - get their own sessions and state; > > - multiple applications/contexts can run under a single server > instance; Hmm, I never looked in there. > improvements to webware after 0.9 - > > - formalized method for executing (context/)application-specific code > once on startup, with access to various webware components. (what's > the recommended way to do this now? stick it in a site page at module > level?) Yes, that's a good idea. > - out-of-the-box connection pooling Wouldn't this depend on what you are using to save things in your DB? E.g. MiddleKit has it's own pooling mechanism. > - get webware into debian's repository? :-) > > > these are suggestions from a lowly webware user, not a webware > developer... take them for what they're worth... They are very useful. I've added them to the wiki list: http://wiki.w4py.org/featuresafterv09.html _________________________________________ winston wolff - (646) 827-2242 - http://www.stratolab.com - learning by creating |
From: Ian B. <ia...@co...> - 2005-02-20 03:09:51
|
lloyd wrote: >> * Mostly backward-compatible. There are some missing corners of the >> Webware API, but that can be fixed. The whole MakeAppWorkDir thing >> goes away (for better or worse), and Contexts disappear. > > > is that a good thing (contexts going away)? > > recently i was looking over the (abandoned?) "webware experimental > refactoring" project, and it had some interesting improvements that, to > me, seemed like a natural progression for webware: > > - contexts become "applications" - get their own sessions and state; I definitely want to support multiple applications living in the same process. Contexts don't really help me do that, though. So I'd rather simply have per-directory (or per-url-path) configuration. Then an application could simply be dumped somewhere, or the directory could be pointed to from some configuration file, and that would be it. > - formalized method for executing (context/)application-specific code > once on startup, with access to various webware components. (what's the > recommended way to do this now? stick it in a site page at module level?) The Context's __init__.py will be loaded, and I think some method from that called (contextInitialize or something). > - out-of-the-box connection pooling Is there anything wrong with MiscUtils.DBPool? At least, stuff that couldn't be fixed? > - get webware into debian's repository? :-) They have pretty strict policy, which Webware as it is now doesn't follow very well. Though it's kind of fuzzy... if Webware is just a package with a per-instance installation script, do the instances have to conform to policy? I'm not sure. -- Ian Bicking / ia...@co... / http://blog.ianbicking.org |
From: lloyd <sub...@tw...> - 2005-02-20 08:18:49
|
Ian Bicking wrote: >> - contexts become "applications" - get their own sessions and state; > > I definitely want to support multiple applications living in the same > process. Contexts don't really help me do that, though. So I'd rather > simply have per-directory (or per-url-path) configuration. Then an > application could simply be dumped somewhere, or the directory could be > pointed to from some configuration file, and that would be it. by any other name :-) could there be per-"application/directory/context/whatever" sessions and state with this approach? > The Context's __init__.py will be loaded, and I think some method from > that called (contextInitialize or something). would that method be passed a reference to server- and context-wide storage, so the the startup code could create and store objects there? how about a similar one for server startup / storage that isn't logically related to any one context? >> - out-of-the-box connection pooling > > Is there anything wrong with MiscUtils.DBPool? At least, stuff that > couldn't be fixed? i think once there is server- and context-level storage and startup code, my confusion over this would go away. the dbpool could be created in the startup code and stored with the server or context, as appropriate. (sorry if my terminology or grasp of webware is off - i'm still a bit new to it and am just starting to look at the source code.) |