RE: [Webware-discuss] Zope vs Webware (Not Really)
Chuck Esterbrook wrote: > On Thursday 12 June 2003 06:16 am, Geoffrey Talvola wrote: >> This has bitten some people on this mailing list in the past because >> of bugs in database adapters. And right now I'm trying to track down >> a problem where I have a servlet that makes an HTTPS request to >> another web site (using Python's built-in SSL support), and it looks >> like every once in a while, something happens during that outgoing >> HTTPS request that crashes the app server. It only happens like once >> a week, so I haven't had any luck tracking this down. If Webware >> used some sort of process pool instead of a thread pool, and served >> only one request per process, this wouldn't be as much of a problem. > > Could you factor this out to another WebKit instance which you would > hit with Pickle-RPC or XML-RPC from the main one? Then when your > HTTPS code crashed, your main app server would be intact. > > I realize that solution isn't on a silver platter, but then setting up > and calling RPC services with WebKit *is* fairly straightforward. Even easier, I'll probably just use stunnel to handle the encryption if this continues to happen. - Geoff --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Webware-discuss mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-discuss
Re: [Webware-discuss] Zope vs Webware (Not Really)
On Thursday 12 June 2003 06:16 am, Geoffrey Talvola wrote: > This has bitten some people on this mailing list in the past because > of bugs in database adapters. And right now I'm trying to track down > a problem where I have a servlet that makes an HTTPS request to > another web site (using Python's built-in SSL support), and it looks > like every once in a while, something happens during that outgoing > HTTPS request that crashes the app server. It only happens like once > a week, so I haven't had any luck tracking this down. If Webware > used some sort of process pool instead of a thread pool, and served > only one request per process, this wouldn't be as much of a problem. Could you factor this out to another WebKit instance which you would hit with Pickle-RPC or XML-RPC from the main one? Then when your HTTPS code crashed, your main app server would be intact. I realize that solution isn't on a silver platter, but then setting up and calling RPC services with WebKit *is* fairly straightforward. -- Chuck http://ChuckEsterbrook.com --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Webware-discuss mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-discuss
RE: [Webware-discuss] Zope vs Webware (Not Really)
Ian Bicking [mailto:[EMAIL PROTECTED] wrote: > > I would also like to see a standard "container". I don't think it even > has to be terribly intrusive or conformist -- it just has to create > request and response objects, and map those to some "resource", which > would be somewhat more abstract than servlets. My private experiments suggest that it isn't that hard to make an abstraction layer for Webware and mod_python - in these cases, the main differences are where one finds certain facilities (eg. request and response streams, content type and encoding information) and whether those facilities are implemented by separate objects or not. Providing an environment for a Webware-style plug-in (which takes responsibility for certain resource types) within mod_python isn't an insurmountable problem either, and I'm convinced that there's enough common ground in Twisted and Zope to cover those frameworks as well. Under the covers, in Zope Products, Zope isn't so different after all. > I was trying to pursue this kind of unification after PyCon, but I'm > afraid I lost momentum, and actually writing code is much more > satisfying than trying to organize stuff. I'd still like to pursue it, > though. The "shootout" paper was certainly very interesting, and recent coverage of Twisted Web suggests that it wouldn't be absolutely necessary to put the whole of Webware on top of Twisted to get a decent application environment with a different execution model: http://twistedmatrix.com/users/nafai/pycon-paper/tw_deploy-01.html That would be compelling: a common environment which runs on servers with completely different underlying "scalability" models (threads, processes, asynchronous tasks) - I doubt that there's such diversity between the mainstream Java application servers. > I've been working on a component idea, for adding functionality to > servlets -- a bit finer grained than plugins. It's in the Webware > sandbox (webware-sandbox.sf.net), in ianbicking/Component, with a user > authentication component as an example. I've also used it for (my still > in heavy development) form processing toolkit, in FormEncode, also in > the Sandbox. Perhaps I should get around to looking at this as well. Paul --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Webware-discuss mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-discuss
RE: [Webware-discuss] Zope vs Webware (Not Really)
Ian writes: > Personally I detest XML files -- the beauty of OO is when data is not > exposed, just methods, and XML exposes data in an inflexible way. But > the interchangeability would be great. At Autodesk, we had an object-oriented approach to XML for the Streamline engineering collaboration service. We had class libraries in both C++ and Java for client code (web apps, server apps, and publishing apps), who used objects rather than XML text. XML was used to persist CAD data in "packages," crack open packages to populate databases, and stream structured metadata from databases to web clients. It is very much like C# uses attributes to serialize objects in XML, but we had a finer degree of control. The wrong XML definition was shown to balloon text size to an unacceptable degree pretty quickly. More recently, I used Webware/Python to prototype an online catalog for a local not-for-profit institute serving the visually-impaired. The catalog was defined in XML. (No formal schema, just me inventing a syntax. The initial catalog has 90-100 entries, enough to give me a warm feeling that the XML has pretty good coverage.) One of the goals for the site design was to be able to maintain the web presentation separately from the catalog content. The website look and feel would not change often, but products would be added or deleted from the catalog on an ongoing basis, prices would change, etc. [It should be noted that the online catalog and site are designed only for presentation, and not to support direct purchase at this time.] I got two things from python: 1) A nice class hierarchy for the web page types (welcome, show items in a given category, show search-by-keyword results, show specific item) along with a parallel class hierarchy for the XML filters needed to support them. 2) Good built-in support for SAX parsing, without validation. Given that, what I got from Webware was a straightforward and repeatable organization for the WriteContent method on my python server pages: # parse values from the HTTP request, if any, ... # Read the catalog and render the page, for example # base = os.path.dirname(self.request().serverSidePath()) pp = GoreySearchPage(self, base, 'Gorey.xml', ...) pp.read() pp.render() The read() method parses the XML file, pulling out the juicy bits. The render() method writes the HTML response. Granted, the python statements to crank out the HTML response were tedious to write, but there is a lot of common content across the page types, which was well-supported by the class hierarchy. I was able to get a feature-rich site running in about a week, with no previous Webware experience and somewhat rusty python skills, and to extend the functionality easily a couple times already. On the XML side, the catalog file worked as I intended it to. Changes were automatically reflected in the website, even if the change added or removed a product category, changed the number of pages occupied by a category, or added/removed an entry from a keyword search result on screen. (An aside: pagination is very important when delivering data to the visually-impaired, some of whom might be using a text-to-speech system to READ webpages to them, others who might be using very large type. As a sighted user, I tend to want many results on a page. But I have also experienced the tedium of the mechanical voice droning on and on. We are experimenting with various strategies for separately formatting content to suit users with various classes of visual impairment.) So Webware seemed to be the right venue for getting a proof-of-concept done in a short amount of time, while still having an understandable and extensible design. It remains to be seen whether we will go live with that architecture. Tom Dennehy Private Citizen Bloomfield Hills MI --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Webware-discuss mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-discuss
Re: [Webware-discuss] Zope vs Webware (Not Really)
On Thu, 2003-06-12 at 13:57, Chris Bruce wrote: > I am not to worried about process vs threads right now. > > My only concern is "rolling my own" security and stuff like that. I like > how Zope's security allows you to use different acl_users folder that > supports different authorizations--although I want groups. But on the > flip-side, one of the reasons I am reluctant about Zope is that anything I > do will only work in Zope. It is not very useable outside Zope. > > This is the one drawback about developing with python for web-apps compared > to Java right now. There are no real standards for developing/deploying > python web-apps and it almost always depends on what python app > server/apache mod that you use. I hate the fact that the Java community has > all these crazy "best practices" for developing web apps, however some > things are kinda cool about the servlet containers when it comes to standard > ways of defining security and uri mapping. The idea is really nice that you > can take a java .war file (web archive) and drop it into most any java app > server and it is ready to go. Then the admin can just modify some xml > files. Personally I detest XML files -- the beauty of OO is when data is not exposed, just methods, and XML exposes data in an inflexible way. But the interchangability would be great. But you can make general, framework-neutral structures in Python -- they just don't *quite* integrate with the framework. You'll have to write per-framework code to glue it in (and make it feel more native). The exception is Zope, where you need to do lots of extra work, and where Zope objects aren't often useful in isolation -- but this is not true of any of the other Python frameworks. > I am not sure if it is good or bad to have some kind of standard > "container"? I wish developing python web-apps could run on most any python > app server. But after spending many years developing java apps, I can say > for sure that java is really dissappointing for developing web apps. But, I > think Webware has some great potential with plug-ins. I just wish there > were more of them! But that might be the way to go right now, developing > the Zope-like things that make it easy to build web-apps in Zope as plug-ins > for Webware. I would also like to see a standard "container". I don't think it even has to be terribly intrusive or conformist -- it just has to create request and response objects, and map those to some "resource", which would be somewhat more abstract than servlets. That model could support servlets, or procedural server pages (think ASP or PHP, rather than JSP, as in Spyce), or object publishing, like with Quixote, or templates, or whatever. Interface differences would be handled with adapters, something that Twisted and Zope people are working on. I was trying to pursue this kind of unification after PyCon, but I'm afraid I lost momentum, and actually writing code is much more satisfying than trying to organize stuff. I'd still like to pursue it, though. As far as plugins, yes, they offer some opportunities, but a lot of stuff can be created without any Webware integration at all -- Cheetah is an example of something written with Webware in mind, but with no dependencies. Then you might write a plugin to glue it together. I've been working on a component idea, for adding functionality to servlets -- a bit finer grained than plugins. It's in the Webware sandbox (webware-sandbox.sf.net), in ianbicking/Component, with a user authentication component as an example. I've also used it for (my still in heavy development) form processing toolkit, in FormEncode, also in the Sandbox. Ian --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Webware-discuss mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-discuss
Re: [Webware-discuss] Zope vs Webware (Not Really)
On Thursday, June 12, 2003, at 12:53 PM, Ian Bicking wrote: Also, because Webware doesn't publish everything, you can use Python modules and objects that aren't Zope-aware. Zope makes this really hard -- like, for some reason a Postgres connection is returning an mxDateTime (un-Zope-aware) object periodically, instead of a Zope DateTime object. Trying to access the .year attribute, I get a not authorized error. That's just stupid. I had a small demo application working in Zope 2.5 (I think) and upon upgrading to Zope 2.6 it stopped working for exactly the reasons described. My reaction: "WTF?!" Moreover, this all seemed so obvious to those already familiar with Zope that it took a while before I found the magic words to unbreak my application in some documentation or mailing list archive or other. It wasn't as if the offending objects were doing anything unreasonable - they were just simple data containers. Yeah, basic OO methodology is *really hard* in Zope. I think that's what drives me crazy, and it comes back to the security stuff. But the result is that it's too easy to create bad applications in Zope, and too painful to create good applications. That problem exists everywhere -- procedural code is easier to bang through -- but Zope goes too far. All I can say is that Zope hurt my brain when I tried to use it. If application servers were gloves, Zope would be a huge mangling metal monstrosity that latches around your ligaments, compromises the integrity of your bone structure, denudes you of subtle sensations and basically atrophies the muscular system of an otherwise healthy hand. While Webware, on the other hand, is like smooth satin joy. You can still do everything you could do before, but it's much more fun because it feels so good! --T --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Webware-discuss mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-discuss
Re: [Webware-discuss] Zope vs Webware (Not Really)
I am not to worried about process vs threads right now. My only concern is "rolling my own" security and stuff like that. I like how Zope's security allows you to use different acl_users folder that supports different authorizations--although I want groups. But on the flip-side, one of the reasons I am reluctant about Zope is that anything I do will only work in Zope. It is not very useable outside Zope. This is the one drawback about developing with python for web-apps compared to Java right now. There are no real standards for developing/deploying python web-apps and it almost always depends on what python app server/apache mod that you use. I hate the fact that the Java community has all these crazy "best practices" for developing web apps, however some things are kinda cool about the servlet containers when it comes to standard ways of defining security and uri mapping. The idea is really nice that you can take a java .war file (web archive) and drop it into most any java app server and it is ready to go. Then the admin can just modify some xml files. I am not sure if it is good or bad to have some kind of standard "container"? I wish developing python web-apps could run on most any python app server. But after spending many years developing java apps, I can say for sure that java is really dissappointing for developing web apps. But, I think Webware has some great potential with plug-ins. I just wish there were more of them! But that might be the way to go right now, developing the Zope-like things that make it easy to build web-apps in Zope as plug-ins for Webware. Chris - Original Message - From: Ian Bicking To: [EMAIL PROTECTED] Cc: Webware discuss Sent: Thursday, June 12, 2003 10:53 AM Subject: RE: [Webware-discuss] Zope vs Webware (Not Really) On Thu, 2003-06-12 at 04:49, [EMAIL PROTECTED] wrote: > Ian Bicking [mailto:[EMAIL PROTECTED] wrote: > > > > Well, I'm not exactly objective, but then while Webware is my > > preference, Zope is my current reality in professional programming. > > You're relatively lucky, then. The closest to job-related Web > applications I get these days involves vanilla J2EE technologies. Yeah, I'm not complaining. I must admit I'm still subtley suggesting changes which may include Webware (knock on wood). > > Also, because Webware doesn't publish everything, you can use Python > > modules and objects that aren't Zope-aware. Zope makes this really hard > > -- like, for some reason a Postgres connection is returning an > > mxDateTime (un-Zope-aware) object periodically, instead of a Zope > > DateTime object. Trying to access the .year attribute, I get a not > > authorized error. That's just stupid. > > I had a small demo application working in Zope 2.5 (I think) and upon > upgrading to Zope 2.6 it stopped working for exactly the reasons > described. My reaction: "WTF?!" Moreover, this all seemed so obvious > to those already familiar with Zope that it took a while before I > found the magic words to unbreak my application in some documentation > or mailing list archive or other. It wasn't as if the offending > objects were doing anything unreasonable - they were just simple data > containers. Yeah, basic OO methodology is *really hard* in Zope. I think that's what drives me crazy, and it comes back to the security stuff. But the result is that it's too easy to create bad applications in Zope, and too painful to create good applications. That problem exists everywhere -- procedural code is easier to bang through -- but Zope goes too far. The heavy app server also makes upgrading and such difficult. It seems common to run several discrete applications on a single Zope server, which seems like a bad idea to me -- development versions living alongside production versions, having to upgrade things en masse, and then testing that big heap of code... bad stuff. > > For deployment, Webware is much lighter than Zope (and not just > > CPU-wise), and I think that makes deployment easier. But you won't find > > things prepackaged, or many hosts that specifically support Webware, so > > you do have to do deployment on your own. But it's not hard, and you > > get to use file-based tools. > > One thing that has reportedly been problematic with Zope and Webware > is the choice of threads for distributing work and the scalability > issues that this brings with it. Having said that, the threaded > paradigm is probably so entrenched in the average Webware application > (or in power-user applications, at least) that I can't see a > process-oriented variant of Webware any time soon. While it wouldn't be that hard to port the basic Webware infrastructure to a process model, I also think
RE: [Webware-discuss] Zope vs Webware (Not Really)
On Thu, 2003-06-12 at 04:49, [EMAIL PROTECTED] wrote: > Ian Bicking [mailto:[EMAIL PROTECTED] wrote: > > > > Well, I'm not exactly objective, but then while Webware is my > > preference, Zope is my current reality in professional programming. > > You're relatively lucky, then. The closest to job-related Web > applications I get these days involves vanilla J2EE technologies. Yeah, I'm not complaining. I must admit I'm still subtley suggesting changes which may include Webware (knock on wood). > > Also, because Webware doesn't publish everything, you can use Python > > modules and objects that aren't Zope-aware. Zope makes this really hard > > -- like, for some reason a Postgres connection is returning an > > mxDateTime (un-Zope-aware) object periodically, instead of a Zope > > DateTime object. Trying to access the .year attribute, I get a not > > authorized error. That's just stupid. > > I had a small demo application working in Zope 2.5 (I think) and upon > upgrading to Zope 2.6 it stopped working for exactly the reasons > described. My reaction: "WTF?!" Moreover, this all seemed so obvious > to those already familiar with Zope that it took a while before I > found the magic words to unbreak my application in some documentation > or mailing list archive or other. It wasn't as if the offending > objects were doing anything unreasonable - they were just simple data > containers. Yeah, basic OO methodology is *really hard* in Zope. I think that's what drives me crazy, and it comes back to the security stuff. But the result is that it's too easy to create bad applications in Zope, and too painful to create good applications. That problem exists everywhere -- procedural code is easier to bang through -- but Zope goes too far. The heavy app server also makes upgrading and such difficult. It seems common to run several discrete applications on a single Zope server, which seems like a bad idea to me -- development versions living alongside production versions, having to upgrade things en masse, and then testing that big heap of code... bad stuff. > > For deployment, Webware is much lighter than Zope (and not just > > CPU-wise), and I think that makes deployment easier. But you won't find > > things prepackaged, or many hosts that specifically support Webware, so > > you do have to do deployment on your own. But it's not hard, and you > > get to use file-based tools. > > One thing that has reportedly been problematic with Zope and Webware > is the choice of threads for distributing work and the scalability > issues that this brings with it. Having said that, the threaded > paradigm is probably so entrenched in the average Webware application > (or in power-user applications, at least) that I can't see a > process-oriented variant of Webware any time soon. While it wouldn't be that hard to port the basic Webware infrastructure to a process model, I also think that Webware *is* threads, at least at this point -- it's a framework, and threads are implicitly a part of that framework. That said, most use of threads could probably be abstracted fairly easily -- it's mostly just data sharing, and while that's easy with threads it's still not entirely trivial (at least if you handle concurrency). Perhaps abstractions are possible that would make something like POSH a drop-in replacement. Personally I don't buy the scalability arguments for processes -- they are based on theory, not practice -- but I definitely do appreciate the reliability issues. Of course, then there's the problem that processes work very badly on Windows... but again, with the right abstractions. Ian --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Webware-discuss mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-discuss
Re: [Webware-discuss] Zope vs Webware (Not Really)
I like webware becuase you can write all of the "business logic" as normal python modules, test them outsite of a webserver w/ full debugging, and then call it from a very small servlet. I hate debuggin in a web server. Here is an example of how I use Webware. I need to pull data from Quickbase.com - a web based database ASP type service. 1) Created a generic QBClient module in python that interacts w/ Quickbase --- All coding done w/o webware at all 2) Create a servlet with this method: def prepareReport(self): qb = QBClient() qb.userName = 'This is not my qbusername' qb.passwd = 'This is not my passwd' qb.database = 'this is not my database' ctable = qb.getCVSTable() <-- return CVS data csvdata = ASV.ASV()< ASB is a module to parse CVS data csvdata.set_field_names(['Name','Products','Alt1','Alt2','Alt3','Alt4','Alt5']) csvdata.input(ctable,ASV.CSV()) csvdata.data.pop(0) <- the top row is header info, lose that self.records = csvdata 3) create a PSP file that uses self.records <%def writeTableRecord(row):%> <%= row['Name']%> <%= row['Products']%> <% end %> on the other hand if you are building a pretty standard website Zope is much easier. I build a large website and support site in Zope and it was very easy to build up a FAQ and knowledge base. Of course when I had to integrate that Knowbase into a MsSQL database things got interesting. -Aaron Chris Bruce wrote: I truly believe that Python is probably the best web development language around. I have actually been paid to develop with Java, ASP, PHP, and Perl and none of them are the silver bullet, like python appears to be. But, I am now trying to find a great framework to use on all future apps done in Python. I am getting ready to build a large webbased application. I am set on python (still wondering how to make installation easy) and am deciding between Zope and Webware. I have developed many Zope applications, but new to Webware. I am well aware that they are very different and they can't truly be compared. But many things I have read about Webware always mention "Non of the Headaches of Zope" or something similar. What is meant by this? Can you guys offer some objective information for/against Zope/Webware in general. My application is basically "a website in a box" designed for the needs of a specific industry.. I am not looking to start a debate or anything, just trying to get some fresh points of view. Some of the reasons why I am looking at Webware: MiddleKit mod_webkit I have had weird ZODB issues in the past. Maximum use of Python Features about Zope I like: Webbased access to development and whole system Built in Security (no coding) Super fast to develop and deploy apps Virtual Host Support Thanks, Chris --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Webware-discuss mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-discuss --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Webware-discuss mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-discuss
Re: [Webware-discuss] Zope vs Webware (Not Really)
I think the process issue lies within the Webware application server, and not the connection from Apache to Webware. - Original Message - From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, June 12, 2003 7:17 AM Subject: RE: [Webware-discuss] Zope vs Webware (Not Really) > Hancock, David (DHANCOCK) [mailto:[EMAIL PROTECTED] wrote: > > > > It seems to me that adopting a process-based architecture would reduce > > performance considerably, but maybe there's some middle ground using FastCGI > > or mod_python. > > I suppose I should have said "process pooling" rather than process-oriented, because people do tend to think of CGI or intensive process creation/destruction when processes are mentioned. > > > My main concern about mod_python (and mod_perl, which I have > > more experience with) is that they bloat up httpd processes considerably. I > > haven't used either with Apache 2.0 in its threaded mode, so I don't know if > > it's an issue there or not. > > I haven't looked *that* deeply into mod_python, but I have also heard scary things about mod_perl. As for the thread vs. process situation, it seems to me that the main benefit of using threads is the reduced overhead in inter-thread communication and access to shared data, but I'm not entirely convinced that this is always going to be a dominant factor in Web applications. Any comments on that? > > Paul > > > --- > This SF.NET email is sponsored by: eBay > Great deals on office technology -- on eBay now! Click here: > http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 > ___ > Webware-discuss mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/webware-discuss > --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Webware-discuss mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-discuss
RE: [Webware-discuss] Zope vs Webware (Not Really)
Hancock, David (DHANCOCK) [mailto:[EMAIL PROTECTED] wrote: > > It seems to me that adopting a process-based architecture would reduce > performance considerably, but maybe there's some middle ground using FastCGI > or mod_python. I suppose I should have said "process pooling" rather than process-oriented, because people do tend to think of CGI or intensive process creation/destruction when processes are mentioned. > My main concern about mod_python (and mod_perl, which I have > more experience with) is that they bloat up httpd processes considerably. I > haven't used either with Apache 2.0 in its threaded mode, so I don't know if > it's an issue there or not. I haven't looked *that* deeply into mod_python, but I have also heard scary things about mod_perl. As for the thread vs. process situation, it seems to me that the main benefit of using threads is the reduced overhead in inter-thread communication and access to shared data, but I'm not entirely convinced that this is always going to be a dominant factor in Web applications. Any comments on that? Paul --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Webware-discuss mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-discuss
RE: [Webware-discuss] Zope vs Webware (Not Really)
Two cents worth from an not-very-informed user. We had problems with Zope vs. long-running processes initially and that drove us to Webware, and we've been happy with it ever since. With Zope, if a web request spawned one long-running process, no problem: other web requests would continue to be answered. As soon as you spawned a second long-running request, all other web requests would hang until one of the two long-running processes ended. We tried the same with Webware, and had no problems at all handling many concurrent requests, even when some of them spawned lengthy processes. It seems to me that adopting a process-based architecture would reduce performance considerably, but maybe there's some middle ground using FastCGI or mod_python. My main concern about mod_python (and mod_perl, which I have more experience with) is that they bloat up httpd processes considerably. I haven't used either with Apache 2.0 in its threaded mode, so I don't know if it's an issue there or not. Cheers! -- David Hancock | [EMAIL PROTECTED] | 410-266-4384 -Original Message- From: Geoffrey Talvola [mailto:[EMAIL PROTECTED] Sent: Thursday, June 12, 2003 9:16 AM To: [EMAIL PROTECTED] Subject: RE: [Webware-discuss] Zope vs Webware (Not Really) [EMAIL PROTECTED] wrote: > One thing that has reportedly been problematic with Zope and > Webware is the choice of threads for distributing work and > the scalability issues that this brings with it. Having said > that, the threaded paradigm is probably so entrenched in the > average Webware application (or in power-user applications, > at least) that I can't see a process-oriented variant of Webware any > time soon. I love the coding convenience that Webware's threaded architecture gives me. It makes caching things like SQL results in memory trivially easy. It's memory-efficient. And so forth. But there is a drawback. If there's a bug in any of your C-coded extension modules that causes the process to crash, it kills the whole app server including any other requests that were being processed. And then you lose all of the current sessions. This has bitten some people on this mailing list in the past because of bugs in database adapters. And right now I'm trying to track down a problem where I have a servlet that makes an HTTPS request to another web site (using Python's built-in SSL support), and it looks like every once in a while, something happens during that outgoing HTTPS request that crashes the app server. It only happens like once a week, so I haven't had any luck tracking this down. If Webware used some sort of process pool instead of a thread pool, and served only one request per process, this wouldn't be as much of a problem. - Geoff --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Webware-discuss mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-discuss --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Webware-discuss mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-discuss
RE: [Webware-discuss] Zope vs Webware (Not Really)
Geoffrey Talvola [mailto:[EMAIL PROTECTED] wrote: > > If Webware used some sort of process pool instead of a > thread pool, and served only one request per process, this > wouldn't be as much of a problem. It could be interesting to investigate the tantalising, but still apparently obscure, POSH (poshmodule.sf.net) mechanism for sharing data between processes in an apparently "thread-like" fashion. Sadly, I don't have the time (or mandate) to look into that, but it could address the various scalability and reliability complaints that have come up, at least if it didn't disrupt the programming model employed by most Webware applications too much. On a more mundane level, I should really send some patches in around "classic" CGI environment variables, and possibly around URLs and paths, although I imagine that Ian Bicking's work probably conflicts with the latter somewhat. Paul --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Webware-discuss mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-discuss
RE: [Webware-discuss] Zope vs Webware (Not Really)
[EMAIL PROTECTED] wrote: > One thing that has reportedly been problematic with Zope and > Webware is the choice of threads for distributing work and > the scalability issues that this brings with it. Having said > that, the threaded paradigm is probably so entrenched in the > average Webware application (or in power-user applications, > at least) that I can't see a process-oriented variant of Webware any > time soon. I love the coding convenience that Webware's threaded architecture gives me. It makes caching things like SQL results in memory trivially easy. It's memory-efficient. And so forth. But there is a drawback. If there's a bug in any of your C-coded extension modules that causes the process to crash, it kills the whole app server including any other requests that were being processed. And then you lose all of the current sessions. This has bitten some people on this mailing list in the past because of bugs in database adapters. And right now I'm trying to track down a problem where I have a servlet that makes an HTTPS request to another web site (using Python's built-in SSL support), and it looks like every once in a while, something happens during that outgoing HTTPS request that crashes the app server. It only happens like once a week, so I haven't had any luck tracking this down. If Webware used some sort of process pool instead of a thread pool, and served only one request per process, this wouldn't be as much of a problem. - Geoff --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Webware-discuss mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-discuss
RE: [Webware-discuss] Zope vs Webware (Not Really)
Ian Bicking [mailto:[EMAIL PROTECTED] wrote: > > Well, I'm not exactly objective, but then while Webware is my > preference, Zope is my current reality in professional programming. You're relatively lucky, then. The closest to job-related Web applications I get these days involves vanilla J2EE technologies. > > I have had weird ZODB issues in the past. > > ZODB seems kind of separate from Zope -- you can use Zope without making > any interesting use of ZODB (just using it as a container for your > scripts), or you can use ZODB without using Zope. In the golden age of Bobo, I noticed some unreliability with ZODB (as it probably wasn't known back then) and I do confess to being somewhat unnerved by pickle-based persistence. However, the main advantage with using ZODB outside Zope is that you can easily split your data into many databases - a huge single file ZODB database (Data.fs?) would scare me in a production environment. > Webware servlets are the one and only frontend to your application. > Most applications don't have a huge number of servlets. But there's a > lot of objects and modules. Since Webware doesn't publish everything, > you don't have to worry about this stuff. Yes, in contrast, if you want to take full advantage of Zope's management capabilities, it would seem that everything runs the risk of being exposed unless protected by various access rules. It's a bit like someone insisting that you perform all your life's activities on a public beach. > Also, because Webware doesn't publish everything, you can use Python > modules and objects that aren't Zope-aware. Zope makes this really hard > -- like, for some reason a Postgres connection is returning an > mxDateTime (un-Zope-aware) object periodically, instead of a Zope > DateTime object. Trying to access the .year attribute, I get a not > authorized error. That's just stupid. I had a small demo application working in Zope 2.5 (I think) and upon upgrading to Zope 2.6 it stopped working for exactly the reasons described. My reaction: "WTF?!" Moreover, this all seemed so obvious to those already familiar with Zope that it took a while before I found the magic words to unbreak my application in some documentation or mailing list archive or other. It wasn't as if the offending objects were doing anything unreasonable - they were just simple data containers. > For deployment, Webware is much lighter than Zope (and not just > CPU-wise), and I think that makes deployment easier. But you won't find > things prepackaged, or many hosts that specifically support Webware, so > you do have to do deployment on your own. But it's not hard, and you > get to use file-based tools. One thing that has reportedly been problematic with Zope and Webware is the choice of threads for distributing work and the scalability issues that this brings with it. Having said that, the threaded paradigm is probably so entrenched in the average Webware application (or in power-user applications, at least) that I can't see a process-oriented variant of Webware any time soon. Paul --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Webware-discuss mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-discuss
Re: [Webware-discuss] Zope vs Webware (Not Really)
Hallo, Chris Bruce hat gesagt: // Chris Bruce wrote: > Thanks for the info. If you have any additional suggestions or comments, > please let me know. > > As far as security, is UserKit useable? I found that the file(pickle)-based UserManager just doesn't work (for me). The MiddleKit backend reportedly is in use and works just fine, but as I don't use MK, I could not use UserKit without writing my own backend. ciao -- Frank Barknecht _ __footils.org__ --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Webware-discuss mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-discuss
Re: [Webware-discuss] Zope vs Webware (Not Really)
--- Chris Bruce <[EMAIL PROTECTED]> wrote: > > I am getting ready to build a large webbased application. I am set > on > python (still wondering how to make installation easy) and am > deciding > between Zope and Webware. I have developed many Zope applications, > but new > to Webware. I am well aware that they are very different and they > can't > truly be compared. But many things I have read about Webware always > mention > "Non of the Headaches of Zope" or something similar. What is meant > by this? > If it really is an "I" project and not a "we" project, I don't think Zope has much to offer you. I tried a while back, but never managed to do anything useful with Zope. To me, Zope seems only appropriate for a large team of developers. The learning curve is pretty steep for one person to climb without someone elses shoulders to stand on now and then. Roger Haase __ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Webware-discuss mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-discuss
Re: [Webware-discuss] Zope vs Webware (Not Really)
On Wed, 2003-06-11 at 16:29, Chris Bruce wrote: > As far as security, is UserKit useable? My experience, shared by a number of other people, is that UserKit doesn't help with the interesting problems (like security, authentication, etc), and isn't worth it for the conceptual overhead. I read the term Ravioli Code recently, which described it well. http://c2.com/cgi/wiki/wiki?RavioliCode --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Webware-discuss mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-discuss
Re: [Webware-discuss] Zope vs Webware (Not Really)
Thanks for the info. If you have any additional suggestions or comments, please let me know. As far as security, is UserKit useable? Chris - Original Message - From: Chris Bruce To: Webware discuss Sent: Wednesday, June 11, 2003 11:25 AM Subject: [Webware-discuss] Zope vs Webware (Not Really) I truly believe that Python is probably the best web development language around. I have actually been paid to develop with Java, ASP, PHP, and Perl and none of them are the silver bullet, like python appears to be. But, I am now trying to find a great framework to use on all future apps done in Python. I am getting ready to build a large webbased application. I am set on python (still wondering how to make installation easy) and am deciding between Zope and Webware. I have developed many Zope applications, but new to Webware. I am well aware that they are very different and they can't truly be compared. But many things I have read about Webware always mention "Non of the Headaches of Zope" or something similar. What is meant by this? Can you guys offer some objective information for/against Zope/Webware in general. My application is basically "a website in a box" designed for the needs of a specific industry.. I am not looking to start a debate or anything, just trying to get some fresh points of view. Some of the reasons why I am looking at Webware: MiddleKit mod_webkit I have had weird ZODB issues in the past. Maximum use of Python Features about Zope I like: Webbased access to development and whole system Built in Security (no coding) Super fast to develop and deploy apps Virtual Host Support Thanks, Chris --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Webware-discuss mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-discuss --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Webware-discuss mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-discuss
Re: [Webware-discuss] Zope vs Webware (Not Really)
Hi, Chris.
I muddle my way through both Zope and Webware almost daily. I'm neither
a novice nor an expert with either.
With mod_webkit, you get to take advantage of Apache's built-in
functionality. If mod_ssl is installed/configured, then secure stuff
dynamically generated through webkit is a given. Trying to get Zope and
SSL to play nicely is a far cry from easy. Plus, someone's going to
have to admin the Apache server anyway (incl. vhosting), so why not
keep things simple?
Webware is knowing Python and some HTML, even CSS if you like. You
don't have to learn yet another markup language or worry about crazy or
non-intuitive syntax (e.g. dtml-call "dict.update({'a': 'b'}). You'll
write fewer lines of code using Webware since you don't have to worry
about closing DTML tags, which can also cause some headaches if you're
deeply nesting things.
Also, whether you shove data into a database or use pickles in the
filesystem (not recommended for concurrency reasons), that information
is available system-wide. MiddleKit looks promising and works, though I
haven't gotten it to work 100% with MySQL yet (missing a req'd module,
too much other stuff to do). Getting stuff out of the ZODB, as far as I
know, isn't easy or intuitive.
In Zope, I find myself writing a lot of External Methods to do the
'heavy lifting', and call them from within the DTML. In WebKit, the
'heavy lifting' is just part of the Python, not a requisite separate
entity.
Wherever I'm not *required* to use Zope, I don't even think about it...
I go straight to Webware/WebKit.
On Wednesday, June 11, 2003, at 02:25 PM, Chris Bruce wrote:
I truly believe that Python is probably the best web development
language
around. I have actually been paid to develop with Java, ASP, PHP, and
Perl
and none of them are the silver bullet, like python appears to be.
But, I
am now trying to find a great framework to use on all future apps done
in
Python.
I am getting ready to build a large webbased application. I am set on
python (still wondering how to make installation easy) and am deciding
between Zope and Webware. I have developed many Zope applications,
but new
to Webware. I am well aware that they are very different and they
can't
truly be compared. But many things I have read about Webware always
mention
"Non of the Headaches of Zope" or something similar. What is meant by
this?
Can you guys offer some objective information for/against Zope/Webware
in
general. My application is basically "a website in a box" designed
for the
needs of a specific industry..
I am not looking to start a debate or anything, just trying to get some
fresh points of view. Some of the reasons why I am looking at Webware:
MiddleKit
mod_webkit
I have had weird ZODB issues in the past.
Maximum use of Python
Features about Zope I like:
Webbased access to development and whole system
Built in Security (no coding)
Super fast to develop and deploy apps
Virtual Host Support
Thanks,
Chris
---
This SF.NET email is sponsored by: eBay
Great deals on office technology -- on eBay now! Click here:
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
___
Webware-discuss mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/webware-discuss
Re: [Webware-discuss] Zope vs Webware (Not Really)
Hallo, Chris Bruce hat gesagt: // Chris Bruce wrote: > I am getting ready to build a large webbased application. I am set > on python (still wondering how to make installation easy) and am > deciding between Zope and Webware. I have developed many Zope > applications, but new to Webware. Why not just develop some Webware apps?! It's really easy for someone already familiar with Python and HTML/HTTP. I'm sure, this is the best way to "get a feeling" for Webware. > But many things I have read about Webware always mention "Non of the > Headaches of Zope" or something similar. What is meant by this? I guess, it's the thinness of Webware. WW is "pro-Python", which means, that everything you do is more than less directly done in Python. No DHTML, no (or only little) web-based configuration. This - at least IMO - is one of the strong points in Webware: it doesn't put anything between the application developer and Python. > Can you guys offer some objective information for/against Zope/Webware in > general. My application is basically "a website in a box" designed for the > needs of a specific industry.. I always had problems really understanding Zope. A lot of the docs look like MS-Word manuals describing which menus to open: "Go to Options->Preferences, click the radio box labeled 'spam'" and so on. I didn't like that. I like the Webware-way: "Write a class called 'SitePage' that inherits from 'Page'..." > I am not looking to start a debate or anything, just trying to get some > fresh points of view. Some of the reasons why I am looking at Webware: > MiddleKit sqlobject.org would be an alternative. > Features about Zope I like: > Webbased access to development and whole system That you would have to develop in Webware yourself first. > Built in Security (no coding) A non-decided issue in Webware. Currently everyone has his/her own security system. > Virtual Host Support Here you'd need to use your webserver's capabilities with WW. ciao -- Frank Barknecht _ __footils.org__ --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Webware-discuss mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-discuss
Re: [Webware-discuss] Zope vs Webware (Not Really)
Well, I'm not exactly objective, but then while Webware is my preference, Zope is my current reality in professional programming. That said, I'm not terribly experienced with Zope, but then I've coming into a shop where all the people who have been using Zope much longer than me don't seem more experienced, at least with respect to application design (administration and maintenance being a different issue). On Wed, 2003-06-11 at 13:25, Chris Bruce wrote: > I truly believe that Python is probably the best web development language > around. I have actually been paid to develop with Java, ASP, PHP, and Perl > and none of them are the silver bullet, like python appears to be. But, I > am now trying to find a great framework to use on all future apps done in > Python. > > I am getting ready to build a large webbased application. I am set on > python (still wondering how to make installation easy) and am deciding > between Zope and Webware. I have developed many Zope applications, but new > to Webware. I am well aware that they are very different and they can't > truly be compared. But many things I have read about Webware always mention > "Non of the Headaches of Zope" or something similar. What is meant by this? > > Can you guys offer some objective information for/against Zope/Webware in > general. My application is basically "a website in a box" designed for the > needs of a specific industry.. > > I am not looking to start a debate or anything, just trying to get some > fresh points of view. Some of the reasons why I am looking at Webware: > MiddleKit While distributed together, MiddleKit and Webware are mostly separate. You can use either without the other. Stylistically they are similar; for instance, MK works best in a threaded environment, which happens to be the environment that Webware uses. > mod_webkit mod_webkit, while quite useful, isn't unique -- mod_skunkweb and mod_scgi are nearly identical in function. FastCGI is the same idea, only more complex. > I have had weird ZODB issues in the past. ZODB seems kind of separate from Zope -- you can use Zope without making any interesting use of ZODB (just using it as a container for your scripts), or you can use ZODB without using Zope. > Maximum use of Python Indeed! > Features about Zope I like: > Webbased access to development and whole system I find other tools to be much more pleasant than Zope -- tools like CVS for file storage, Apache/mod_dav for viewing and editing resource files, and all the other tools that work with files (but don't work with ZODB objects). > Built in Security (no coding) Webware is a little light on this, but I find Zope's security as much of a curse as a feature. Webware isn't flat in the way Zope is -- Zope developers are Zope users, Zope script sources are protected just like page views, and inclusion, calling and viewing over HTTP are all the same mechanism. Seems elegant, but in practice I find it terribly difficult to work with. The security that I want to define is usually something like, page X can be viewed by someone with role Y, where X is one of a handful of scripts. So X calls some component Z -- I don't want to protect Z. I don't want Z available over HTTP at all. Webware servlets are the one and only frontend to your application. Most applications don't have a huge number of servlets. But there's a lot of objects and modules. Since Webware doesn't publish everything, you don't have to worry about this stuff. Also, because Webware doesn't publish everything, you can use Python modules and objects that aren't Zope-aware. Zope makes this really hard -- like, for some reason a Postgres connection is returning an mxDateTime (un-Zope-aware) object periodically, instead of a Zope DateTime object. Trying to access the .year attribute, I get a not authorized error. That's just stupid. > Super fast to develop and deploy apps Webware is pretty quick to work with. It's hard to judge, since experience is a big part of speed of development, but I think Webware should be as fast or faster to develop compared to Zope. You do have to implement a few things from scratch (like users :( ), but in my experience the result is so nice and small that it's almost worth reimplementation. I say "almost", because we could stand to do better, but no implmentation is still better than misimplementation. For deployment, Webware is much lighter than Zope (and not just CPU-wise), and I think that makes deployment easier. But you won't find things prepackaged, or many hosts that specifically support Webware, so you do have to do deployment on your own. But it's not hard, and you get to use file-based tools. > Virtual Host Support With Webware you'd go through Apache. Any option (two domains on one codebase, one codebase with different template per domain, totally separate codebases, etc) is doable. You have to design the specifics yourself, but the result is an implementation with no magic or
