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

Reply via email to