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
