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 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 ------------------------------------------------------- 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
