Forum OpenACS Q&A: Article on ACS x Zope

Most people pick their web toolkits at first reading to the language wars.. the db wars.. the web server wars.. the os wars.. etc.. at first.

Then they figure out that, well, they can't really rule anyone out--though that's the initial (being realistic) intent. If they are really reasonable, they keep tab on all systems and as Kevin discovered, which for the best of both worlds. It turns out that all those flames did was to point out each component's specific advantages and disadvantages, and whether it meets your business needs.

That's what I am trying to get at. You can use anything, just make it work with your current contract. That's the goal. Scripting languages at the end of the day are easy to pick up. So is SQL. The TCPIP and CGI and web server apis. And a bit of common unix/nt/mac wizardries you pick up over time from books and friends. They all are basically pick-up-able. They all work just about the same way. As a matter of fact they are so simple (for the designer to code) that they end up being scalable (for the user)--almost by accident.

The machines will run them no matter what and handle complexity rather well--the problem is programmer efficiency (that's fundamentally the debate between Zope and ACS Kevin is trying to decypher).

ACS tries to answer the problem by assuming everyone in your company will want to sit down with some chinese take-out during lunch break and log-in--some day--maybe NOW (I know this from past work experience). It seems that's what ACS is aiming for. Oracle was a minor ugly detour that sorta ended that little dream though but initially when Philip had the dream it was with Tcl, simple SQL on Solid (dirt simple to admin), and AOLserver (very simple and design done right). So ACS initially was aiming for easier learning curve for users who want to dig into a web programming work flow (just as Python made Highschool students express difficult ideas quickly--objected oriented or not...)

Zope again is a dream come true for many. I have no doubt that after a swat team of clear headed experienced object orientation savvy programmers have their way with the system: they'll come up with their homebrew tool kit like ACS and optimally users can go in and add content, extend classes, poke and fetch from object pools. Elegant and done right--despite planned complexity. But the programmers know they can't get anyone to touch the code completely--it's object oriented, there's a trillion acrynums and middle-layers involved, although it's object oriented and programmer friendly--and looks good on paper--it is hard to understand for those who haven't had community college C++ training. But it'll survive in a large company IT sweat shop. Just don't try to show it to the secretary. Zope had no intention to let the secretary dig in a write a script based on a complex custom tool kit. Unless all secretaries in the future comes OOP/XML/XSL/Object Database/N-Tier ready from MIT's Secretaries Media Lab.

So Zope (and Python), ACS and (Tcl) are both aiming for good things..

But all is not well in paradise...

ACS has to face maturity, just as Zope has to, we all see how complexity can drive any newbie insane. Solid to Oracle is like moving from the suburbia Idaho to NYC. So is simple Python CGIs to your modern day Zope. So we see that due to complexity. All that benefit we seek from both systems in terms of programmer efficiency or learn-ability may diminish as time passes.

The question is what to do?

Both are on a great track, both seek to try all sorts of things to keep things simple. If you don't like big RDBMS, the DB in Zope will do fine and minimize complexity, so will OpenACS's PostgreSQL be simpler for users of Oracle. There are other ways to help. Python is reaching into the classroom in high schools. ACS is carefully maintained in clear crystal tcl no matter how big it gets, and a proper license (GPL) welcomes all newbies to dig in and learn the basic design patterns (written by the best) one would want them to pick up. So things are good, both good.

Also, he admits that his opinion regarding Tcl's being slow, etc, is based on hearsay and guessing.  He weakens his piece by then treating such unsubstantiated opinion as fact.  An objective and intellegent reader won't miss this less-than-subtle source of bias.  A Zope zealot (Zopealot?) won't care, having already made up their mind.

In my mind, a piece like this brings forth a couple of thoughts:

When it comes to toolkit acceptance, aD's dependency on Oracle is a liability.  It would be nice to see aD take a more proactive approach to supporting our efforts (via query abstraction, etc) because it will  be OpenACS, not ACS Classic, that wins the hearts and minds of the masses if there is any chance of this happening.  On the other hand, aD has a very clear business mission and founding a religion isn't one  of them.  I can't disagree with this decision.

From the technical side, the unstructured mess that is today's toolkit  is indeed a weakness, and even though the critic has only read about and not used it, he's managed to wander close to the truth (if he only  knew how buggy it is...).  We should code name the current release "mashed potato", because that's an accurate description of the formlessness of the toolkit as it exists today.

However, I don't believe a switch to an object-oriented paradigm or to  a language other than Tcl is necessary to greatly improve the toolkit  in this regard.  aD is (finally) adopting (at least some of them) the  attitude that there really should be a toolkit architecture rather than a bazillion pieces that aimlessly interact via brownian motion or  some similarly unordered process.  We'll see if they make a significant move in 4.0.  It's crucial that order be built out of the current chaos if the tookit's really going to mature into a truly engineered piece of work.

His praise of Zope in part stems from his belief that the object-oriented model followed by the team has led to a cleaner design.  My spin's a bit different - the design might well be cleaner,  as the ACS toolkit (as opposed to individual components of the toolkit) hasn't been designed but simply grew.  Again, I don't think a  paradigm shift to the OO world is necessary to generate a clean design, but a shift to SOME paradigm is...

Greetings...

Perhaps I should have made it boldface when I said "this comparison is based on things that matter to me". Different people will clearly have different criteria (like ease of learning).

When you get beyond basic document management, Zope is hard to learn. This isn't helped by the fact that the documentation still needs work. The docs I saw for ACS were much better, but I have no idea how good the docs are when you are trying to do really customize things. I didn't put this in my comparison, because I've been using Zope for more than a year. I've gotten past the learning curve.

When I started working on this, the OpenACS folks were still in the process of porting a lot of the pieces of ACS. I remember that the spam module wasn't there yet. At the time, I was worried that OpenACS would always lag behind ACS Classic quite a bit, though it appears that the OpenACS people have worked quite fast. If I had seen more elements that really compelled me toward ACS, I would certainly have put in the effort to install OpenACS or ACS Classic if my concerns about OpenACS had continued. But, I have the same 24 hour days and too much to do that everyone else does. In the end, I didn't see enough to compell me away from the system I already knew.

The original poster here mentioned that I talk about Objects a lot. Objects themselves are not important, but for what we're doing having reusable, easily customizable components is. And, I think Zope excels in this and there are some other things coming into existence now that make it better.

With regards to the "Zope is Evil" article, I'd have to agree with that. I like working on top of the Zope architecture, but I don't think I'd really want to be working on the architecture itself. Getting Zope running within a special Python interpreter inside of ACS sounds like a very big job to me.

If there are factual errors in my document, please let me know. I had initially thought that TCL would be faster than Python, but later heard that TCL is actually much slower due to the data structures used. If someone has done good benchmarks of the two, I'd be curious to see that.

I am a Zope user, but I still believe there is plenty to be learned by looking at how ACS does things. If anyone has any questions about how Zope does things, I'd be happy to shed whatever light I can.

Kevin

Have no fear, I'm familiar with OO and believe it to be a useful paradigm - though not a UNIVERSALLY useful paradigm as the most serious religionists try to argue.

I personally believe that for a large chunk of a web toolkit like the ACS, too much structure just gets in the way.  After all, a big chunk of the toolkit consists of glorified forms handlers and report generators.

The OO paradigm could be useful in the definition of how the core technology shared by modules, i.e. permissions and similar things, is used to build those modules.

But the toolkit's pretty simple, and a uniform and orthogonal API for modules based on any reasonable underlying paradigm  would be so much better than we have today that it doesn't really matter if an OO approach is used.

My impression is that the Zope framework was designed and implemented before a great deal in the way of modules were hung on it.  That's a great approach if you get the design right.  I have to wonder if perhaps it's not overdesigned, though, given comments about its complexity and also the relative immaturity of a bunch of the modules.  Both of these observations are based on comments by users, I've never used it myself.

Also, the basic AOLserver/Tcl/RDBMS paradigm is a very simple one.  There's virtue in keeping things as simple as possible, isolating complexity to necessary areas, like the API between modules and the core technology.  I think the ACS will grow to the point where there's a core which provides services to modules, a well-defined module interface to that core, and a much higher degree of separation of the generation of the UI/presentation from computation.

Do folks in the Zope world talk at all about simplifying their model?

Are you sure you're not describing the ACS? :)

I'm serious, this is a big problem with the ACS, as well.  I suspect in part this is due to the relative newness of the web and the relative immaturity of tools available for site building.  Not to mention the fact that everyone wants their site up YESTERDAY.

<blockquote> Zope's major problem.
</blockquote>

I would agree... for someone who just wants a simple website, Zope is probably not for them.  But I don't think that's out target audience any more than it is ACS'.  HTML designers don't care too much about what's on the back end.

<blockquote> The ACS has lots of parts but is simple. If Zope is as complex and
</blockquote>

<blockquote> hard to understand as you indicate, perhaps the creators, not
</blockquote>

<blockquote> potential users, should be seeking enlightenment...
</blockquote>

I guess the hardest part to get over the hump with is understanding object orientation and some of the finer points of Zope like acquisition.  We're still building the tools that allow people to not have to understand these things.  We are trying to simplify, document and focus on less general problems (ala content management).  I suppose doing these things would be considered "seeking enlightenment."  I'm sort of glad, however, that a lot of time has been spent on the architecture thus far as it sure makes it a lot easier when you have a lot of interfaces you can write to reliably.  Now we just need to expose them.  😊

For the mean time, however, until good, comprehensive documentation is produced, the best I can do is offer my thoughts about how to begin to understand the basics of the architecture, and hope people get interested; thus the article.  It's not really an article that takes a high-handed tone, despite the title.  I'd recommend you read it if you're interested...

This is true.  I've also seen that there are a lot of programmers out there who don't, especially in the field of web development.  I had many responses to that article from people who know Perl, VBScript, and PHP, and never use to a great degree the OO constructs of any of these languages.  Zope makes really heavy (some might say absurd) use of inheritance; not to mention our homebrewed 'acquisition', which is something like inheritance but is containment-based.  This stuff is pretty central to Zope, which takes a little getting used to for non-OO types, and even sometimes for OO types.  The use of these features combined with our hideous documentation is why Zope is hard for people to get cranking on quickly.

In our defense, bringing an end-to-end object model to the web is something of a new and foreign thing, and AFAICT, Zope and Apple's WebObjects are the only two products that honestly try to do so.  I know most of people just want to get something done and not have to worry about what is going on inside.  But I do think that building web apps in terms of objects is a good thing, if only because it frees you from needing to think about webdev stuff in terms of 'pages', and instead lets you think about your site in terms of how pieces of code can interact with each other, how you can build interfaces to applications that let folks use them not from just within the application UI, but via XML-RPC/SOAP/CORBA/RSS, etc without needing to strain yourself by building all the machinery to talk to these things from scratch.

This is something of a religious point.  I certainly do not mean to say that large-scale applications can't be written in terms of dynamic pages or in terms of writing procedural code that goes and grabs stuff out of SQL and displays it to the user.  They are two very different approaches that share parts of the same goal.

<blockquote>      I just keep getting this feeling that you folks are making a
</blockquote>

<blockquote> mountain out of a molehill. ACS-backed websites are by no means
</blockquote>

<blockquote>      "simple websites",
</blockquote>

I didn't claim they were, on the contrary!  My apologies if you thought so, please read the sentence again.

<blockquote> the toolkit's relatively simple because the problem of creating
</blockquote>

<blockquote> complex websites is relatively simple. It's the
</blockquote>

<blockquote> pieces you glue together that are complex. The datamodel's the most
</blockquote>

<blockquote> complex piece of the ACS itself. That's the way it should
</blockquote>

<blockquote> be.
</blockquote>

This seems to be the major point of divide between ACS and Zope... we don't have a datamodel.  Instead we have objects that have interfaces.  You have data that sits in an RDB, then you have code that operates on it.  We have objects that contain both code and data, by way of the ZODB.  Even stuff that's in an RDB external to Zope can be represented by Zope in terms of instances of a class ("pluggable brains").

A little dig, here, my pre-proposed apologies.  I hope I don't get flamed too hard.  You guys have been working like mad to port ACS over to Postgres.  This is a lot of work.  It's a lot of work because there seems to be only a thin layer of abstraction between the code that makes up ACS and the database table structures.  There's a lot of dependencies there, I presume, which is what makes it hard.

OTOH, Zope has a Storage interface that you can back up with whatever serves your purpose.  The "default" storage is a FileStorage, that is one big honking file on the Zope server's HDD.  But one of the other uses of the Storage interface is our failover stuff, ZEO.  It lets us frontend a single "storage server" with multiple Zope clients which serve as webservers.  Despite the complexity of the task, the code that lets us do such a thing is less than 100k (total, with docs).  This is pretty amazing to me.  Solutions like, for instance, Allaire Spectra, have megabytes of code to go do this, and then you need to go make sure your RMBMS is partitioned and synced properly across a number of machines besides.  I'm somewhat attracted to the elegance of the Zope model when it comes to stuff like this.  It just feels right, whereas other solutions feel.. well.. clunky.  This isn't to say they don't work, I'm sure they work fine.  But I like the fact that the haystack is potentially partitioned into 100k, when the needle can be a single byte.

Another point:  Jimmie Houchin referred to a RelationalStorage in the works for Zope.  I am one of the folks writing this beast.  This code will let us store all the ZODB information inside a relational database.  It doesn't much matter which kind, because the whole implementation is less than 8k, and I can rewrite it in about 12 hours.

These sorts of flexibilies are possible because we're using an object model inside Zope and because we're trying desperately (and sometimes succeeding) to write cohesive interfaces to those objects.  The next step is to make more apparent that power to end users of the product by writing applications against Zope and documentation for Zope that exposes it.

We know have a *long* way to go, and it's clear that we can take some pages out of the ACS book when it comes to packaging something that makes people productive quickly.  Parts of Zope are still somewhat of a framework that DC uses for consulting engagements, though most of it has quickly grown into an application server or content management system in its own right.  We need now to concentrate on hardening the interfaces to the less clear parts of the framework and documenting them.  Hopefully, at that time, the time we put into the architecture will pay off.  Maybe not, in that case I'll be out of a job.  😊

<blockquote>      Why invent persistent store (ZODB) when there are proven
</blockquote>

<blockquote> database engines - object-oriented as well as relational -
</blockquote>

<blockquote> available? It's this "we need to build it all" mentality that I
</blockquote>

<blockquote> think leads to a lot of the complexity.
</blockquote>

DC was (and is) a Python company at heart.  AFAIK, at the time it was determined that there needed to be a persistent object database to front end Bobo (that was Zope's name at the time), there were no affortable OODB alternatives that had Python interfaces.  Jim Fulton is something of an OO "zealot", so using an RDBMS to store object data was not an option in his mind.  So... he made his own OODB  😊  Mine is not to question why.  He did it, it's solid, and it's pretty damn useful.

In more general terms than the ZODB, I think you're right, however.  Zope needs to cater more to people's existing skillsets.  This is where we think that applications like the Portal Toolkit, further community contribution, and better documentation will help.

This isn't an intrinsic problem in the ACS, and even less so of the thin-layer paradigm used in its (cough) design.  aD has no motive to abstract out the database queries.  We do.  It will happen.

So I view this as something of a red herring when considering the overall problem.  Just as Zope's documentation problem is a bit of a red herring - there's nothing about the paradigm or approach Zope takes that necessitates poor documentation, it simply hasn't been a priority.

"Jim Fulton is something of an OO "zealot", so using an RDBMS to store
    object data was not an option in his mind. So... he made his own OODB 😊 Mine is not to question why. He did it,
    it's solid, and it's pretty damn useful. "

Zealotry is a sin in engineering.  Your comment nicely illustrates my point that the Zope folks seem to have a need to build mountains out of molehills.

The ACS wasn't designed, it simply grew out of client-driven work.  You might say that aD has had a tendency to ignore the existence of molehills.  I prefer this sin to the sin of inventing needless complexity.

Success in the marketplace has little to do with technical merit.  That's what makes our profession so rewarding, right? :)

This creates a large body of work which previously had only it's developers working on it so it is understood by them but undocumented. It just takes time for the docs and community understanding to catch up. But we would rather have it available and undocumented than to not. This enables the community to use the product and help document. This creates a mutually beneficial relationship.

DC is creating a very nice api and help system for Zope. This will speed up learning Zope. As the api's are cleaned up, published and as what is 'core' Zope becomes more clear it will be easier to build a foundation knowledge of Zope. Once having attained a foundation knowledge the rest will be much easier.

I just don't see any mountains being created out of molehills myself. I see an excellent product which like many in software development the understanding and documentation lag behind the development.

It is apparent that Zope and ACS are approached by different philosophies. One who believes that either is the right way will likely not agree with the views of the other. Such is life.

The fact still remains that a developer who is like-minded with his tools can be very productive with them. If he tries to use tools which diverge significantly from his views and philosophy will be battling his tools and consequently less productive.

Both can be good tools.

For the most part, when you're selecting a tool to make a web application, you should pick what you know best, like best, and maybe even what is most popular and best supported, or even handiest.  I can't really fault a risk-averse Fortune 500 manager for choosing Vignette over Zope or ACS.  Why would he choose them?  He's never heard of them, it's a lot of work to do the research right, and his butt is on the line.

However, when creating the actual framework that allows other folks to create web applications, I don't think these constraints apply.  We know our butts are on the line, and we are consciously taking a path we think suits us and allows us to produce the best software we can.

There is lots of technology in Zope that we created, yes.  Most of these technologies are based on ideas that aren't really new, but that haven't been widely applied to web application development.  Desipte this, we also interface with most popular and commonly-used web technologies (Oracle, Postgres, other SQL DBs, Apache, IIS, soon Perl, DOM, and some various XML technologies including XSLT).  So I think we *do* support a lot of technologies that we didn't create.

In defense of the stuff we did create from scratch, I would also offer that if nobody ever created anything new, we'd still be using rocks to bash our grain to make flat bread.  The folks here are without reserve the smartest people I've ever had the pleasure of working with, and I'm very happy to have the pleasure of seeing the stuff they've created establish a life of its own.

I respect your decision to stand on the shoulders of giants by using proven third-party technology to back ACS.  We've done the same with lots of things in Zope.  Other things we've created ourselves, and FWIW, I think they're fantastic.

Is there something else specific I am supposed to be defending?  OO?  Dude, the *name of the product* is the Zope *Object* Publishing Environment.  It'd be a little tough for me (assuming I like our product) to not defend an OO approach to web development with a name like that.  😊

Is there anything else I should be defending?  My skills?  Perhaps my co-workers' skills?  The paucity of my social interactions?  My handwaving?  (BTW, Your suspicions about Zope being overengineered and over-complex are curious, as you've never used it, but I trust you've heard it from "smart people" on "good faith" and they're grounded in solid reason.)

This exchange is becoming pointless, but its been a lot of fun so far.  I have a strong conviction that we need more guys like you working for/on competing companies and projects.

Because the work is available for all to see.  Download it and find out for yourself what its quality is, read the ZODB UML model and read the article links I gave.  Why should I go through any effort solely for your sake when you're unwilling to expend any energy or thought on it?  You claim to want objectivity, but from your tone and your lack of initiative, I'd be more apt to guess you just want to look like the biggest fish in the smallest pond.

He started it.  😊

"""
What bothers me is that no real arguments have been presented here to make a point about Zope. If you're posting on the OpenACS web site (which you're more than welcome to do!), it behooves you to make a solid point about why you think Zope is good before we go out and take you seriously.
"""

Actually, my original post was in response to Titus' "Why Zope Is Evil" article referenced in the discussion... I am interested in ACS, it's reputed to be very good, and I had hoped to get an answer to a specific question that I asked about ACS' accesibility to new users which was answered (very well) by Robert Mello.  I have no genuine desire for you to take me seriously beyond that, though I've been having quite a good time bickering with Don since then.

"""
In particular, the idea that OpenACS / ACS is not as good as Zope because it includes "too many" differently named elements (Tcl, SQL, ADP) is laughable. So if we called it Qtcl, QDB, Qweb, would it be less confusing?
"""

If someone said this, it wasn't me.  Believe me, we've got our own acronym problems.  😊

"""
Look, I'm perfectly open to the idea that we can learn something from Zope. But let's see some *real* arguments here, objective advantages, not warm-and-fuzzy arguments about what "feels more consistent" or how smart Zope developers are.
"""

OK.  I like the fact you've brought up specific points that I can actually address instead of insulting my mom or something.  😊

"""
Note that OpenACS is *not* willing to compromise on certain things: ACID compliance of the data store.
"""

Nor is Zope.  See http://www.zope.org/Members/jim/ZODB/TransactionsAreImportant.  It's actually just Jim referencing your website (wait, your article personally!).  We know transactions are important.  Every request to a Zope method is conducted within transaction boundaries.  The ZODB does ACID, and SQL transactions are by default encapsulated within requests to the ZODB.  This means that you can modify objects via the same method call within the ZODB and within a transaction SQL datastore (Oracle, Postgres, Sybase, and Solid currently, IIRC) in the same transaction and retain the ACID behavior of both.  Both datastores will be rolled back in step with each other if the containing transaction fails.  Writes to the default storage implementation (FileStorage) are all appends to a single file, and we're very careful about the bits.  I am currently developing a Zope storage that uses Interbase instead of the filesystem (see http://www.zope.org/Members/jim/ZODB/RelationalStorage).  You can see more at the ZODB UML model or you can read the article linked at starship.python.net that I gave earlier.  You can also read Jim Fulton's ZODB3 presentation for the yearly Python conference at
http://www.python.org/workshops/2000-01/proceedings/papers/fulton/zodb3.html

"Efficient calculation of aggregate information"

We interface to SQL if that's your bag, and we have additional cataloging machinery for stuff stored the ZODB that's somewhat more flexible than many SQL engines for full-text searching (I have a rough time with LIKE, I'm no RDB person myself, how does one efficiently full-text search an Oracle or Postgres DB?).  It stores references (path locations) to objects as well as metadata (cached attribute values and method return values of arbitrary objects), and provides more traditional indexing capabilities.  We also have the concept of "pluggable brains" which allows us to wrap return values of SQL data into a class instance to give it additional functionality.  We are hoping to extend the cataloging machinery of the ZODB to handle SQL datastores RSN.

"""
Scalability to millions of hits per day in practice, not just in theory.
"""

I concede this point.  The biggest Zope website I know the actual stats on (Zope.org) gets about a hundred thousand hits a day on a single server.  It's not taxed, but I have no available empirical evidence to present to show that it would go any higher.  We've addressed this considerably with ZEO (Zope Enterprise Option), which used to be a commercially available product packaged along with service but has been open-sourced and is being packaged for general consumption and will be released hopefully within the next few weeks.  It allows you to use mutliple Zope clients (no theoretical maximum limit) on arbitrary machines against a single 'storage server'.  Each client keeps an object cache, so reads are relatively cheap.  Writes are more expensive.  It's well suited to web applications in which most hits are reads.  The storage server invalidates objects in each distributed client's cache when it notices an object has changed in storage.  Invalidating client caches is what makes writes expensive.  More info on ZEO is available on the zope.org website.

"""Quick learning curve"""

I definitely concede this one.  We really fall down here.  We *really* fall down here.

"""and rapid development. """

Once you get past the learning curve, I think we've got a good rapid development story (if that's not an oxymoron 😊.  We obviously use Python, which is a great interpreted scripting language, that makes things a little easier than having a compiled language like Java (I'm sure the same is true of TCL).  We've got ZClasses which are classes that you can create through the web, whose methods can be traditional Python code, DTML methods (a templating and presentation language), SQL methods (methods that return values from SQL datastores), and various other things.  I'm working on a project right now with the development team of a customer using Java to write a web client app, and we're constantly ahead of them, even though IMHO they are very smart, it's just faster to implement in our environment.  I'm sure Don will jump in here and claim that this is not meaningful because I haven't presented their resumes to him nor mine.  Nyaaah.

"""
I'm sure Zope has a few things to teach us. I invite you to take into account these important restrictions and submit a real proposal for how we can benefit from Zope's approach.
"""

This is sort of a heavy task.  It would help if you read some of the articles and documents I've linked, after which I'd be happy to answer any questions you have.  I'm not here to convert anybody.  I've heard very good things about ACS and I hope to find the time to install it and maybe steal a couple ideas from you guys (I think actually I'm going to try to steal this bboard idea from you, it's really very well done, except I'm going to try to make email work both in and out, have you thought about trying that?).  I think that against my better judgment I just let myself be trolled, this explains my extended stay.  😉

An aside:  have you noticed that the email URL generated by bboard doesn't actually point to the discussion forum that the email references, but that it points to the container for the discussions?

"Zope is probably somewhat more complex behind the scenes because it attempts to make the job easier for the 'user' of the Zope web development tool, not necessarily the 'developer'. Zope is great for managing content and users."

Distinguishing between developers of the code and users of the code seems like an odd one to make in the world of Open Source. Not only is ACS (relatively) easy to use; it's also (relatively) easy to see how it's wired together. To my mind, this is a huge benefit for those users who don't like the way a piece of the damned thing works. I haven't worked with Zope, but I have worked with closed-source application servers that are based on a similar idea that the users of the tool didn't need to understand what was going on under the hood. It was a nightmare.

The other side of this argument might be that if you have a good OO system with encapsulation, most developers don't really need to understand how each object works. Perhaps this is different than not knowing how your application server works; I'm not in a position to judge that. Or maybe the argument is that once you understand Zope's OO, then understanding it's source code will be easy. I'm not in a position to judge that either. Regardless, neither of these answers satisfies the underlying aesthetic of ACS. Making the system itself "rat-simple" (in Philip's words) is a central philosophical tenet of ACS, where it is clearly an ancillary (if important) goal for the Zope folks.

In my mind, then, the question is what I get in return for giving up that simplicity. The one argument I have heard so far is superior portability, which the OpenACS team believes can be achieved without sacrificing the simplicity of the system. I won't evaluate this point since I don't have the expertise; I'll just say that it's a point of contention between the two groups. OK, next argument. One of the claims that I've heard in favor of using Python is that it's easy for one programmer to read and maintain another programmer's code. But again, this advantage seems to be nullified by the simplicity (or lack thereof) in the two systems. (And the advantage is usually touted in comparison to Perl, not tcl.) We don't know how development time or scalability compare because Zope apparently doesn't have enough of a track record to provide data. If there are other pros and cons to be considered, I haven't heard them (or understood them) yet.

It may be that you Zope folks believe that OO in general and the Zope implementation in particular will be superior in some or all of these areas (i.e., scalability, reduced development time, portability, ease of maintenance, and simplicity) in the long-run but that it's a theory you're still testing. There's nothing wrong with that. At this point, though, it sounds like your argument is just that--a theory.

I've not used it.  Never said I have, therefore have not contradicted myself.  That doesn't mean I've not explored the Zope site, haven't looked at examples, or am totally clueless about how Zope works.

I've never used mySQL, either, but I have a pretty good understanding of how it works.  Better than many of its users, judging by the arguments those who live in that religious space make to justify the lack of ACIDity, etc, that make it so weak.

"I don't particularly like UML-style models that also serve as conclusive documentation. It's way too much work for
    the average person to ingest. This is an example of the kind of thing we need to fix. "

One thing we can agree on, at least.

As far as the rest of your answer, it's a non-answer.  Your attitude's  strange, I have no problem being objectively critical about the ACS.  A tool's strengths and weaknesses are generally fairly obvious to those who work with them.  I have a difficult time understanding why you can't spit forth a paragraph or two which objectively describes the strengths and/or weaknesses of the Zope approach.  You've found plenty of time to make statements that are irrelevant ("these guys I work with are really smart!") or religious.  You really can't take ten minutes to make a clear and concise statement of Zope's benefits?  Perhaps the philosopher wears no clothes?

There are undoubtably areas in which Zope does a better job than the ACS (since the ACS undeniably sucks in some areas).  One Zope user has deflated one of my expectations in this regard, though:

"In my mind what complicates Zope is the unclear line between what is core and what is added or built upon the
    core. Or in this context what is the framework or what is built on it. There is not a clear delineation of what source
    (code) or knowledge one has to understand or have in order to fix, modify or extend certain parts of Zope. This
    also extends into simple usage of Zope. "

Quoted from an earlier post.  I have to admit I read this with great disappointment, because this is precisely the area where I'd expect Zope to provide an example worth studying.  It is an area where the ACS truly sucks, and where repair work is needed.

So, if Zope doesn't provide a good example in this area, where does Zope provide good examples?  What shines in the design?

I am enjoying this thread a lot and hope it goes on.

About the issue of people not knowing how to program to build websites, this is clear. I can "build" an entire website using my Netscape Composer, or Dreamweaver (brr) or whatever. This is not what's being discussed.

The thing is that it has been noted and dicussed in many places (including this thread) that Zope is difficult to grasp, is difficult to start getting results with. The thread went on to try to find out why from people that know Zope. Same with the ACS approach.

I have stated many times that I think great sites can be developed with either tool. I think both tools provide significant support for a full featured website. They have different flavors. They taste different. Is that better? I didn't mention philosophy. Oops, it slipped. :)

At some point your website will generally need to do something not built into ACS. It may be very specific to your site. At that point your not in ACS but you are still in AOLserver and SQL and the Oracle/PostgreSQL. Your skill set requirements just increased.

With Zope that is not the case unless you choose for it to be. Zope provides a web server and transparent persistent storage (which meets ACID).

The scope of Zope, is the scope of AOLserver and ACS and SQL/RDBMS. This is where the difference in complexity lies.

I have read numerous times of Don banging his head against pg source. Using PG or Oracle or maintainance of either is a simple as ZODB.

So if you include AOLserver/ACS/SQL/RDBMS vs Zope. AOLserver/ACS/SQL/RDBMS isn't as simple or non-complex as only ACS. And that's not saying ACS is without issues. ACS has issues, and aD is addressing them in 4.0.

Basically I'm saying that the scope of learning in Zope is somewhat more than just ACS. It is also a documentation issue of howto and how things interact with each other. But like aD, DC is addressing these issues.

Also when Zope's learning curve is brought up, DTML is a part of that. DTML is integral to Zope. So the assessment of Zope's learning curve and complexity is based on integral capabilities that aD is adding to ACS and that are not in the current assessment of ACS.

None of this in Zope is poorly designed. It isn't the design which makes it complex. It is the scope of functionality and grasping it all without sufficient documentation. Also for me, I don't do this full time. I am learning in my spare time, so the process is slower/longer.

When we each talk, I talk about all Zope is and likewise you speak on what ACS is. So is somewhat an Apple and Oranges issue and can be difficult to do accurately.

Just for grins on this, hmmm, Win95 machine I have at work I looked at a default install of Zope and a download of ACS.

Zope had 474 *.py files and 221 *.dtml
ACS had 2361 *.tcl files and 105 *.adp

This can mean whatever you want. I'm not implying anything. It is just interesting data. And not all of the *.py files are Zope per se, some are a part of the included Python interpreter.

This is untrue.  You can reuse existing elements of the ACS, including  utility modules whose sole purpose is to ease the task of extending a site's functionality beyond that provided "in the box" by the toolkit.

Is this as easy as extending Zope?  It will depend on how closely the desired functionality matches existing functionality in either case.

"  With Zope that is not the case unless you choose for it to be. Zope provides a web server and transparent
    persistent storage (which meets ACID). "

Once you've learned how to use Zope objects which implement persistent storage, sure, you don't have to learn how  to use them.  This statement can be made about any software tool, though.

You imply that learning to use these Zope objects is easier than learning to use SQL.  Given that the SQL needed for most web sites is fairly trivial, do you have any empirical evidence that this is true?

Or is it just another item of faith we're expected to agree with.

"I have read numerous times of Don banging his head against pg source. Using PG or Oracle or maintainance of
    either is a simple as ZODB. "

Something else that's untrue.  If I want to develop objects in Zope that support both Postgres and Oracle, I'll have to deal with exactly the same query differences.  If I knew I wanted to do this in the beginning, I'd take care to build abstractions to isolate differences as much as possible.  I'd use unions instead of outer joins from the beginning.  Etc.

Just as I would do in the AOLserver environment if supporting two DBs was my goal.  In fact, that's one of the appeals of AOLserver's Tcl API.

And even more to the point - the same bugs in Postgres will exist, and  ZODB and Zope, though undoubtably fiendishly clever, aren't capable of dipping into the PG source and fixing bugs.

Now, as it happens, aD chose not to structure the ACS in a way that makes it easy to support multiple databases.  That's a choice that can  (and eventually will) be undone.  If people providing Zope objects transparently support a wide suite of persistent storage engines, my hat's off to them.  I have to wonder if this is really true in practice or merely in theory, though.  If true in practice, be assured that someone worked hard at making it real.

"Also when Zope's learning curve is brought up, DTML is a part of that. DTML is integral to Zope. So the
    assessment of Zope's learning curve and complexity is based on integral capabilities that aD is adding to ACS and
    that are not in the current assessment of ACS. "

I honestly don't understand the above.  If you're speaking of templating via ADP pages as being something that's not in the current assessment of ACS, then the reality is that for many users this will flatten, not steepen, the learning curve.  If you mean something else,  feel free to explain.

"Zope had 474 *.py files and 221 *.dtml ACS had 2361 *.tcl files and 105 *.adp

    This can mean whatever you want."

Not really.  It can only mean one thing: nothing.

The difference in our Zope descriptions was also that I limited it to *.py and *.dtml. In Zope the dtml files are used for management screens and anything you want rendered into html. The py files are the Zope source code. The reason I searched for *.py is because Python bytecode compiles it's source files. Their will be a corresponding *.pyc file for each *.py file.

With Zope you can use the database of your choice. I like the ZODB which comes with Zope. Its most common storage is called FileStorage. ZODB can use various storages to hold the data including PostgreSQL via a new RelationalStorage. Regardless of which backend storage one uses for ZODB it is relatively transparent to usage. The user will not have to create tables/column etc.

Feel free to use any RDBMS of your choice with Zope. ZSQL Methods are an elegant way to interface Zope with any RDBMS. Zope will also cache the RDBMS items as objects. Their are many users of PostgreSQL on the Zope list. Or conversly their are many Zope users on the PostgreSQL list. :)

With the coming Zope 2.2, Zope will be including a new Help System. The Help system will help explain various parts of Zope and it's API.

A couple of different e-commerce products are being written for Zope via some users. Their is even a ZCommerce mailing list. This is an area which will definitely be improved and is as we speak.

There are many areas which Zope's OO framework is paying off nice benefits. There have been some very recent improvements that have been relatively easily implemented because of this.

The Zope community is very friendly and most helpful. Feel free to subscribe to any of the mailing lists and fire away any questions you have.

Hmm, I'm currently reviewing OpenAccess and untarred 3,326 files in 226 folders.

Really ? So you judge one tool's technical aspects by the number of files in it ? Pathetic. And what the heck is OpenAccess ? Let's see how much it means... Here's a list of the ACS modules that are ready off-the-shelf withouth ANY programming, creating of tables, objects or whatever. Please post here which of these modules come with Zope so we can use the number of files in an aspect where it matters.

Adserver, Banner Ideas, Content Sections, Custom Sections, Content Tagging, Display, Dynamic Publishing System (integrated with ACS release 4.0 as of summer 2000), FAQ, General Comments, General Permissions, Graphing, Modules, New Stuff, News, Permissions, Poll, Press, Prototype Builder, Redirects, Robot Detection, Spam, Tools, Curriculum, Customer Relationship Management, Email Handler, Member Value, Portals, User Administration, User Groups, User Profiling and Content Categorization, User Registration and Access Control, User Session Tracking, Address Book, BBoards, Bookmarks, Calendar, Chat, Calendar Widget, Contact Manager, File Storage, Intranet, Ticket, WimpyPoint, Classifieds, E-commerce, Neighbor to Neighbor, Audit, Data Warehouse, Directory, Download, Site-Wide Search, Static.

OK, now we're getting somewhere. Here's a snippet of Python that sits in a configuration file on disk that creates a FileStorage instance (from memory, the spelling might be wrong, the thrust is not):

import ZODB
db = ZODB.FileStorage('/tmp/Data.fs')

Here's a snippet of Python that does the same with a relational storage:

import InterbaseStorage
db = InterbaseStorage('/tmp/zope_storage.gdb', 'localhost', 'user', 'password')

These are the only configuration differences, it is only configured once, and the remainder of the code in Zope is the same and is 100% transparent to the end user. The same operational rules apply when using either storage. One storage is hosted on the filesystem, the other is hosted in an Interbase database. A particular storage format/table structure is defined for either.

The rest is common between storages. For the most part, any valid Python statement can act against the ZODB (doesn't matter which storage type its hosted by). Objects that are not Python builtins must subclass from a Persistence class to participate in the ZODB. There is one other unobvious deviation from the norm that Python programmers need to understand, which is that they must treat mutable attributes of builtin objects immutably (ie. you need to notify the storage separately if you use methods of built-in objects (arrays, hashes, etc) that modify them "in-place", as opposed to using assignment).

Most storages support "versions" and "undo". Undo works on a per-transaction basis, and all transactions are undoable unless objects referenced in the transaction are modified by a subsequent transaction. Versions are long-running transactions used mostly for site "staging", where you can modify objects without having your changes show up in production until an explicit commit (handy for HTML developers) reducing the need for a separate staging server.

Recently, we've added support for Mountable Storages, which means that a single application namespace can host different storages simultaneously. This is desirable in cases that you want to make use of BerekelyStorage (a storage using BerkelelyDB) in situations where undo and versions are not necessary and the "all-writes-are-appends" properties of undoable storages lead to unwanted file growth. You can think of mountable storages somewhat like Unix mounted filesystems, where the application namespace is the root of the filesystem.

Users create objects, whether through the web interface, through DTML, or through Python within either storage. You interact with the ZODB in a manner consistent across them. Transactions begun by a web request or via DTML are automatically committed or aborted at the end of a request. Transactions begun within Python code must be committed explicitly.

""For instance, your users are working on Zcommerce tools. The ACS simply provides you a comprehensive e-commerce module off-the-shelf. Not programming at all is easier than programming, even if the programming environment leads to wet dreams... "

This is true, point conceded. This is an area for improvement, and is one of the things we can learn from the ACS.

One thing that seems clear is that the ACS doesn't seem to delineate as much as Zope does between the developer and the end user. We have catered more historically to developers who want to use the platform to develop customized applications. We're starting now to try to cater more towards the end user that just wants to put something up quickly through things like the Portal Toolkit, which is a huge simplification of the Zope management interface and doesn't require you to think in terms of app dev, while providing community features like news, member-contributed content, workflow, email notifications of updated content, self-cataloging objects, and the like.

The Zope community (which consists primarily of developers, not end users) has beaten us up over and over again over documentation of Zope internals and our templating language. This is the number one thing we need to fix to allow people to contribute meaningful products. Once we do this, hopefully folks will be able to create things more efficiently, and will start to feed their creations back into the Zope community, after which we'll begin to see more stuff that "just works out of the box" ala ACS' ecommerce support. We also have contracts with customers that give us some leeway to open-source and generalize creations they've funded out of consulting, which is clearly our bread and butter at the moment.

ZEO extends this model by reusing it and providing a similar invalidation scheme between distributed processes via IP.

Sorry, I can't spend much more time on this.... For more info, I'd suggest you visit zope.org or any of the links I've given in this thread.

HTH,

Chris

I had a discussion today about this, and I think we concluded that we would partition Zope users into five categories.  In this model, we start with a core group.  The second group consumes the work of the core group.  The third consumes the work of the second and the first, etc.  Here's what I think they are:

1. Core hackers - people who actually evolve Zope internals and provide interfaces to low level stuff

2. Product builders - people who produce generalized reusable modular products for Zope but who don't necessarily hack internals

3. Content managers - people who organize and produce presentation logic for site structure, featured content, and syndication.

4. HTML designers - people who give dynamically-generated things a consistent and attractive "look and feel" using routines created by a content manager

5. Content consumers - people who consume the services created by the prior four groups (this may include contributing content, buy not meaningfyl formatting, layout, or logic)

Historically, we've catered to groups 1 (mostly internal employees), 2 (members of the Zope community like Butch Landingin, creator of Squishdot), and 5 (the customers of our consulting customers).  We've also got a good start in the catering to 3.  Our through the web management story appeals to 3, this is a target market for us, and we're hoping to make it more attractive for these folks though the Portal Toolkit effort and other "content-management-esque" features being added to the Zope core (like historying and revision control).

4 doesn't care what hosts the HTML, and 5 doesn't know nor care what lies underneath.  These are folks that (unless we're doing consulting), are *not* our target market.

We often run across peple trying to be in many of these roles simultaneously who resultingly need to absorb quite a bit of information to become proficient at all of it when using Zope.  I think these are the kinds of people you're talking about.  Unfortunately, our docs cater to *none* of these groups, we don't offer an end-to-end documentation story, and that needs to be fixed badly.  Zope is a very attractive product, and its initial simplicity in installation and intro documentation I think sort of lulls people into a feel-good state.  Then they try to do something that's not in the docs.  Look out!  Anger!

How does the OpenACS community see their userbase?  Would you divide it this finely or would you paint broader strokes and consolidate?  Would you include #4 and #5 as members of your userbase?

"""Odd in the sense that the team seems to put its sense of architectural aesthetics ahead of accessibility of the code. It may be open, but it feels a bit elitist (if unintentionally so)."""

The Zope core definitely does not have as relatively broad a contributors list as something like Linux.  I'd compare Zope to a *BSD-type project in this respect (as opposed to a Linux-type project).  Personally I'd like to see a better system set up so that more people were encouraged to submit core enhancements.

I'm intrigued that people are talking about the complexity of Zope at the level at which I use it (building apps) I don't find it complex. Stumbling across a reference to it in "Learning Python" I downloaded it in my lunch hour and had it talking to my Informix database and performing useful queries by the time I went home. I'm not a Python hacker and I didn't need to be. I gave it to a colleague who worked through the document management docs and we set up some folders for others to manage. In a few days we had mailback forms, data entry, Squishdot (like Slashdot) running as an IT help desk, then we found the Zwiki and set up some wiki webs, then we put up Worldmail for time management and email.

All this without a line of Python and very little complex dtml. Since then I've got more involved in dtml and Python as I've needed to validate and hack around with user input etc using regular expressions but I was impressed that Zope solves many problems I didn't know existed (like the <dtml-sqlvar> which deals with sql quoting). I've implemented a secure login against user tables on the Informix database, I'm storing session cookie data in there as well. It works, I like it.

Cons ? Documentation (as we all know), some difficult syntax in dtml, lots of products still to be developed (Portal toolkit, e-commerce, education systems etc), lack of native Informix drivers - but there's a lot of potential IMHO.

It may be behind ACS in terms of ready available product (I don't know ACS though I'm going to try it out) but from my perspective I think Zope has a huge amount to offer.

I've just spent a few days careful reading in Zopeland after a few days careful reading in OpenACS. As a complete newcomer to both, still not having DONE anything in either, my understanding is very limited. Still, most people who are busy doing things in one or the other don't have time to carefully read what's going on elsewhere, and are also more likely to have preconceptions about it.

For what it's worth here are some observations.

1. Zope has LOTS of documentation. Just very hard to find your way through it. Still immature but likely to be a great platform.

2. For access to RDBMs databases via SQL, Zope provides pretty much exactly the sort of data abstraction facilities that Ben was talking about in:

https://openacs.org/doc/sql-abstraction.html

This keeps getting confused (at least to me) with the fact that Zope can ALSO use an RDBMs as the "storage" for its OODBMS instead of using an append only flat file. The Zope sql-abstraction facilities are EASIER to use than Tcl and DO NOT require an understanding of ZODB and the core internals of Zope.

Note: This does not imply that porting SQL code from Oracle to Postgresql would itself be any easier, just that it would not be entangled with presentation.

3. I still haven't found out how Zope handles connection pooling with external SQL queries.

4. Using an OODBMs for persistence has MAJOR advantages over using an RDBMs for MANY things and DOES include full support for transactions.
ZODB is "aggressively optimized" for many reads, few writes. That is exactly what is required for MANY web applications.

5. I haven't come across anything that indicates an appreciation that RDBMs also have MAJOR advantages for MANY OTHER things. I remain convinced that for OnLine Transaction Processing an RDBMs is inherently more scalable and deals with concurrent writes better (as well as being inherently less flexible, adaptable and harder to develop for and maintain than Zope).

6. As Kevin pointed out in the article that started this thread:

"Ecommerce:

ACS: ArsDigita has developed an e-commerce module that does many of the things that Amazon.com does! Professional and customer reviews, gift certificates, discounts for certain groups of users, discounts for users with a coupon code and more. Plus, they have customer service management (an email handler that makes it easy to track email), and order management. The e-commerce module does not handle payment by check, but this should be relatively straightforward to code.

Zope: There is a product called EMarket, but it is not fully featured. We have our own home grown code. This code does, IMHO, a good job of product display. Zope doesn't (yet) have good, standardized support for members/users. This is coming very soon, though.

Advantage: ACS. There's no comparison in this category. ACS has great commerce features out of the box."

7. Ecommerce happens to be one of the areas where an RDBMs is a REQUIREMENT. I see nothing in in the Zope architecture that would prevent somebody competent in both RDBMs design and Zope from re-implementing the ACS ecommerce module in Zope (the same may also be true of other modules but I haven't looked).

8. Unfortunately there seems to be little overlap and little appreciation of the importance of an RDBMs for ecommerce apps in Zopeland so I am doubtful that this will happen there soon.

9. Since I'm neither interested in nor competent at building such a substantial application, but just need some of those facilities to be there, it looks like I have to use the ACS ecommerce, despite preferring the Zope platform.

10. Since ACS classic apparantly has little interest in an sql abstraction layer and OpenACS is primarily focussed on the porting of SQL code from Oracle to Postgresql, it occurs to me that OpenACS ought to be very interested in carefully studying the data abstraction layer in Zope and considering how to make that SQL code available to both platforms.

As I lack the skills to do that myself, but have an urgent need for a small part of the ACS ecommerce module and a future need for various things that Zope offers, I'm seriously contemplating trying to just run the two together, much like shunting users off to another site to handle the credit card processing.

Is that as brain damaged as it is inelegant?

Anyway, I have an immediate question which people here familiar with AOLserver should be able to answer easily. Will there be any hassle running Zope behind it on the same http port and IP address?

Zopeserver, like AOLserver is a single process. To allow flexibility, it is commonly installed behind Apache with a Persistent CGI or Fast CGI or a proxy pass through, using Apache for SSL support and URL re-write rules as described in the links below.

Is it reasonable to assume one can do pretty much the same with running Zopeserver behind AOLserver instead of Apache? (In particular a pointer to the AOLserver module for rewriting URLs would be helpful, I had a quick look but couldn't find it. Ditto for Persistent or Fast CGI support, presumably less common in AOLserver than in Apache since CGI just isn't the way it would otherwise be normally used).

http://www.zope.org/Members/guy_davis/install_routes

http://www.zope.org/Members/cavnit/apachevirt

http://www.zope.org/Members/anser/apache_zserver

http://www.zope.org/Members/kedai/apache_zope_fcgi

It has struck me many times and I have commented on this in zope mailing lists - Zope's interface to RDBMS is so good, yet so incomplete. You have a wonderful abstraction layer which easily allows you to move a zope application from Oracle to PostgreSQL (or write support for both in the same applciation) - so good, yet support for different RDBMS is so bad, Zope provides 'official' support for Oracle, Sybase and ODBC (Win32 only), relying on third party products for PostgreSQL, MySQL. No Linux ODBC, no Informix, no DB2, no Interbase ... It seems to me that Zope could distinguish itself by supporting 'all' the RDBMS's likely to be used. Then you could write a Zope app which was portable across any environment.

" 8. Unfortunately there seems to be little overlap and little appreciation of the importance of an RDBMs for ecommerce apps in Zopeland so I am doubtful that this will happen there soon."

There are Zopers with RDBMS background (like me) but we are in a minority. It is hard to believe that people would seriously try to build an ecommerce application using the Zope ODBMS but they have. Whether the idea of mapping the Zope ODBMS onto an RDBMS ( someone has just releases this with the ODBMS running in Interbase) is the best or worst of all worlds I'm not sure.

I have been working with a client who has gone for ACS over Zope mainly because of the lack of ecommerce on RDBMS in Zope. Yet it seems to me that Zope has so much potential, and the Zope products which don't need RDBMS are so attractive, that it would be an ideal platform to incorporate both.

I have done some work with Zope and RDBMS and I've found it powerful and effective.

Perhaps after I have worked with the ACS ecommerce product I may be able to comment more about implementing it in Zope.

2) A significant volume of transactions that have a relatively high ratio of writes to reads. Any OODBMs is better at a high ratio of reads to writes and the ZODB is "aggressively optimized" for that situation. This makes Zope very good for combining "dynamic" (but read only) web pages with decentralized administration and maintenance of the site, including product catalogs unless they are volatile and large. The writes required for such ongoing administration and maintenance are relatively low volume and the transactional support provided by ZODB should be adequate, with much easier and more flexible customization through Zope. However I can't see it working for any significant volume of "shopping cart" and payment transactions, or even a reasonably volatile user base, let alone the individual page tracking and correlations that ACS ecommerce provides. These are fairly static applications so ease of development and customization is less important, but the high volume of actual writes is more important. Given that ACS has already done the main development and OpenACS has ported it to a viable open source RDBMS, there should be no need to duplicate those major efforts. As far as I can see the ZODB would still be navigating via pointers as an OODBMs and the fact that its "storage" happens to be within an RDBMs would not change the fact that each navigation would still require at least one full disk seek for every write. How would any benefit be obtained from RDBM indexing, clustering etc if the ZODB is just appending each object to a single RDBM table?

[RM]
I have been working with a client who has gone for ACS over Zope mainly because
of the lack of ecommerce on RDBMS in Zope. Yet it seems to me that Zope has so
much potential, and the Zope products which don't need RDBMS are so attractive,
that it would be an ideal platform to incorporate both.

[AL]
This sounds similar to my situation. I'm actually recommending use of OpenACS ecommerce module in parallel with separate development of other aspects of a site in Zope. Still not sure whether THAT will be the best or worst of both worlds 😉

Glad to find at least one other person caught between the two worlds who might be interested in figuring out how to minimize the pain in the bum that one gets from trying to ride two horses or sit astride a sharp fence!

Seems to me that OpenACS faces related problems just from needing to keep in sync with ACS while also needing a data abstraction layer, but not being particular interested in Zope as such.

The way I see it:

ACS has a body of expert knowledge of the problems of RDBMs based web sites but is not interested in any RDBMs platform except Oracle. It also adopted a sound architecture getting away from CGI by using the web server as the RDBMS client. It is already running into the limitations of non-OO large scale development but has no real understanding of OO design. I have the impression most RDBM people think the OO stuff is just an overcomplication for web related stuff that can be done more easily without it. (The fact that they actually did build ACS without it and Zope has nothing comparable in important areas such as ecommerce confirms that view, but says nothing about what happens when the much larger and more complex systems made possible by what they have already achieved just keep on growing and becoming less and less maintainable).

OpenACS understands the importance of that body of expert knowledge and needs to stay in sync with ACS to continue benefiting from and contributing to it, but also needs at least a data abstraction layer while not having much interest in anything more OO than that. OpenACS is likely to have the greatest appreciation of the need for a solid data abstraction layer.

Zope has a similar architecture to ACS as regards getting away from CGI and using the web server as the database client. It has a thorough understanding of OO design but only a minority that would appreciate the importance of the body of expertize ACS has made available on RDBMs based web sites. (In particular the very specific issues for ecommerce which ACS achieved an understanding of through hard experience are not yet understood). I have the impression most Zopers think that just because the OO stuff completely abstracts the database from the viewpoint of application developers and content managers, the body of expertize ACS has provided is simply irrelevant. (In particular ecommerce looks like just another app). Their concept of a data abstraction layer seems to be limited to a data abstraction layer for talking to Zope.

I'm hoping that there might be some interest among OpenACS people in working out how to decrease the coupling between the RDBMs based modules of ACS by a separate data abstraction layer that would ALSO make it easier to use those modules with Zope (or any other application platform) AS WELL AS their primary concern of making it easier to use them with Postgresql and other RDBMs as well as Oracle.

If that is possible, it strikes me as a better solution than simply migrating the modules to Zope or any other particular platform. As "stand alone" modules they could be kept in sync with their original development as part of ACS instead of forking off and duplicating effort.

Something like an XML-RPC interface to ecommerce application domain objects stored in the RDBMS?

[RM]
I have done some work with Zope and RDBMS and I've found it powerful and
effective.

Perhaps after I have worked with the ACS ecommerce product I may be able to
comment more about implementing it in Zope.

[AL]
Sounds like you could be ideally placed to take the initiative in getting people interested in making it "stand alone" so that it could keep in sync with ACS as well as being available to Zope. Any interest in that cf "forking"?

I am cross posting this to the Zcommerce list:

http://lists.codeit.com/mailman/listinfo/zcommerce

as well as to the OpenACS bboard below.

Will also be posting correspondence with Paul Everitt, ChrisMcDonough and Kevin Dangoor to Zcommerce for discussion there as promised.

Will be tracking any discussion in either place but without any further cross-posting, so anyone else interested in both would need to be subscribed to the list above and also use the "notify" facility on the bboard below.

[robot]-----------------

To post a response, come back to the bulletin board at

https://openacs.org/bboard/q-and-a.tcl?topic_id=8&topic=OpenACS%20compared%20to%20other%20toolkits%20and%20technologies

I wish you had a link to this article on the OpenACS. At least I didn't find one. I had to search all over the aD site to find it. I couldn't remember where I saw it. But here is where I found it on the aD site. http://acs40.arsdigita.com/doc/acs40/

It would be nice for the Tcl to be able to call the query appropriate to the db in use. The SQL could still be optimized for each db, using the features if available and working around where not.

This would help open up the potential db pool and potential user pool. This would allow other issues which determine database choice to permit using ACS/OpenACS. I know aD believes in Oracle but other organizations have made other choices based their criteria. aD opened up the server choice some while keeping the SQL hardcoded to Oracle. I would have preferred the opposite. What was the purpose of opening up the server choice? Was it so that clients could choose the server based on their criteria. I think the db choice can be opened up without major compromise. Hopefully aD will listen to Ben and open up to making a change. If not hopefully it can happen here in OpenACS.

It seems this would be the easiest way to open up to InterBase and other future OpenSource databases. Who knows who will open up what in the future.

I also believe this could help make the code less fragile to changes in the database's version of SQL as they add or change features or syntax.

I am sure if I've made in errors in thought someone will help me out here. :)

3. I still haven't found out how Zope handles connection pooling with external SQL queries.

Jimmie writes:

I believe here is where some of the confusion is. In number 2 above it is mentioned that Zope abstracts out SQL like Ben talks in his article. From my understanding this is not quite accurate. Zope has no SQL. Let me repeat, Zope has no SQL. There is no relational data model in Zope. All SQL and RDBMS development is done solely by the app writer or the user of Zope. All SQL used in Zope is custom for the specific app, for the specific db, by the specific user. Zope has what is called ZSQL methods which are method bindings for queries which integrate the Queries into Zopes object structure and ZODB. It provides some syntactic sugar to make incorporation of a RDBMS into Zope's object world easier. It is very nice, however, I think were talking apples and oranges.

Concerning ZODB's capability of using 'RelationalStorage'. ZODB is Zope's object storage model. It can use a variety of containers to store it's object data. Each storage has different characteristics.

Up to very recently the only usable storage available was FileStorage. It is a single monolithic file. Because of Zope's versioning and undo capabilities a ZODB can growing very rapidly. This is due to store multiple versions of a changed object until the ZODB is packed removing extra versions. On certain filesystems this created a problem due to the 2gb file size limitation. Thus your entire dataset could not exceed 2gb unless you went with a RDBMS to store your data.

A RelationalStorage would help with this, as most RDBMSes get around the 2gb problem. The RelationalStorage is easily abstractable do to the fact that it is creating a single table and storing rows of 8 byte binary data. I could be wrong on this, but this is what I remember. So there is no complex SQL to worry about.

Zope's connection pooling isn't probably any different than AOLservers. You just configure Zope to talk to your db and it'll handle the rest. I believe you can configure threads or handles, but there is not a whole lot to it.

Hopefully this can clear this up some. Zope SQL abstraction and ACS SQL abstraction are two different beast. Zope itself has no SQL to abstract.

So regarding which environment provides a superior database abstraction, the answer is "neither".  But the ACS per se flunks in this regard, something the OpenACS folk bitch and moan about daily.

Ideally, in the Zope world, you deal with Zope objects, in which case you needn't concern yourself with how stuff's stored.  That's good.

The direction the ACS is going is to split presentation and computation issues in such a way that for a large percentage of sites programming won't be needed at all.  At this surface level, I suspect DHTML and Adp pages are going to look a lot more alike, than different.  Most users won't need to poke "under the hood".

It's different for us OpenACS porting folk, of course.  As it would be for a Zope implementor porting Zope for use with a brand-new RDBMS.

Is the OO paradigm and the set of available Zope objects better for the "under the hood" design that should mostly be the realm of the developer, rather than user of the toolkit?

Well ... the RDBMS/thin-layer approach taken by the ACS has certainly led to the development of a large set of modules, many quite comprehensive and all of the useful.  I'm in a results-oriented mood at the moment ...

I'm kinda tired of comments like this:

"OpenACS (and ACS) people know far more about RDBMs than most Zopers ever will...[SNIP]...
    Zopers and other OO experts know far more about abstraction than most RDBM experts ever will. "

There's an implication here that perhaps OpenACS folks don't know much about the OO paradigm because we're RDBMS experts.

For starters, I'm no RDBMS expert.  Picked up "SQL for Smarties"
about 15 months ago, that's pretty much the extent of my expertise though I must say I've gotten rather good at writing queries.  For seconds, I'm hardly unaware of  OO principles and of the value of this paradigm for decomposing a large set of problems.  The fact that I'm working on a toolkit which wasn't designed using OO principles doesn't  mean that I'm ignorant of, or unskilled in, that paradigm.

This broad hinting that those who don't necessarily buy the notion that the OO paradigm is the best paradigm for web site development do so out of ignorance is a cheap substitute for substance.

Concerning ZODB's capability of using 'RelationalStorage'. ZODB is Zope's
object storage model. It can use a variety of containers to store it's object
data. Each storage has different characteristics.

Up to very recently the only usable storage available was FileStorage. It is a
single monolithic file. Because of Zope's versioning and undo capabilities a
ZODB can growing very rapidly. This is due to store multiple versions of a
changed object until the ZODB is packed removing extra versions. On certain
filesystems this created a problem due to the 2gb file size limitation. Thus
your entire dataset could not exceed 2gb unless you went with a RDBMS to store
your data.

A RelationalStorage would help with this, as most RDBMSes get around the 2gb
problem. The RelationalStorage is easily abstractable do to the fact that it is
creating a single table and storing rows of 8 byte binary data. I could be
wrong on this, but this is what I remember. So there is no complex SQL to worry
about.

[AL]
Using an RDBM is a rather odd way to get around a 2GB file system file system limit.
I suspect there is more to it than that. But anyway, your account confirms my impression that the use of an RDBM for ZODB storage has no relevance whatever to the question of integrating Zope with RDBM SQL based OLTP applications like Ecommerce.

[JH]
Zope's connection pooling isn't probably any different than AOLservers. You
just configure Zope to talk to your db and it'll handle the rest. I believe you
can configure threads or handles, but there is not a whole lot to it.

[...]

[AL] I understand that Zope application developers can just use db handles in much the way that ACS application developers can just use those provided by AOLserver. My concern is whether Zope  really is pooling them properly like AOLserver or whether there is some interaction between the ZODB handles used by Zope and the RDBM handles used by Zope that could result in some limitation in the performance of an RDBM application with Zope cf a similar application with AOLserver.
I guess this is a matter of "Zope internals" that I'll have to pursue in Zopeland.

The ZPatterns stuff is the brainchild of Phillip Eby, a developer at Verio (the hosting provider).  It (among other things) is a mechanism to provide medium-independent "propertysheet" support.  "Propertysheets" in Zope are rectangular sets of typed data that can be attached to Zope objects arbitrarily, and as such lend themselves very well to storage in an RDB table.  And I think this was probably what Philip had in mind in providing Dynamic Data Objects.  Although to be honest, I might be totally wrong... I can't really tell what the intent is now.  I've heard it's a good set of ideas, but personally I'm stumped most of the time when I read his stuff because he names things very opaquely and seems to explain things in such a way that you *do* need to community college C++ degree to begin to grasp it.  I think it's one of those projects that needs to gain some traction and obtain a critical mass of real-world examples in order to make its ultimate intent clear to mortals like me.  Until then, I can't speak much for it, although I do recommend you continue looking at it.  (Maybe you can write some code using it that would explain it to me!)

ZPatterns is not part of the Zope distribution.

I think Ben had in mind at least in his most recent posting an abstraction layer that allowed RDB-savvy people to write SQL-like queries that would automagically be translated into their equivalent optimized Oracle- or Postgres-specific SQL dialect at runtime.  I don't think anybody in Zopeland has the intent of writing such a beast.

You're probably right in assuming that the ZPatterns stuff is about as close as it gets to wanting to do something like that.  But Zope propertysheets are generally by nature pretty small fixed sets of data (maybe 5 - 12 properties per object).  You would need to declare some sort of table structure for a particular object type, create the tables to store the propertysheet data for those kinds of objects, then do the right voodoo to tell the objects to obtain their properties out of SQL instead of out of the ZODB.  This could probably be abstracted in such a way that people don't need to write any SQL, but it would never approach the sort of complexity that I think Ben is talking about because it would probably practically necessitate an approach something along the lines of defining a table to hold propertysheet data for each different object type.  If you wanted to do ad hoc queries against an existing set of data in multiple tables (ones that might require unions, outer joins, or insert selects) would need to be (just as painfully) manually constructed in the SQL dialect of your choice.  Personally, I'd probably try to keep it simple and create views on existing tables that would let me operate as if I were doing so on a single table.

Somehow I get the feeling that in this conversation we're all talking an entirely different language than one another.  I assume that Ben's concerned about complicated SQL abstraction between Oracle and Postgres because he wants to get rid of Oracle dependencies in ACS.  I think Albert's talking about being able to abstract the SQL out enough to not have to think about it at all when constructing an application.  I'm probably just plain not thinking about it at all.

I looked at Ben's sql-abstraction page... I don't know any tcl, but I think I get the gist.

It would seem to me to make sense to abstract out both 1) the access mechanism for querying and the 2) resultset that comes back from the query.  In Zope we do the first part by creating a "method" that contains the actual query (which can be as DB-specific or generic as you like), connecting it to a database connection (a pool of database handles for a specific DB type).  You can then pass in arguments to the method that have counterpart template definitions within the query itself (ala CUSTID = <dtml-sqlvar abc>), and the method passes the query in to the DB and obtains its results.

The second part (returning the results of the query to the caller) is handled in Zope by wrapping the resultset in a class instance that lets us process those results generically.  It would probably be good to do something like this in ACS by defining a datatype that could hold arbitrary common elements that could be processed in tcl code generically.

Though it's not a trivial engineering task, it seems like the biggest problem isn't implementing it, but encouraging people to use it.  From what I understand there's a large body of existing code that does not use any sort of abstraction like this.  Convincing folks of the usefulness of writing against your interface instead of yanking the stuff right out of the tables in their code is probably the hardest task.

1. Is there any problem with the third party Zope Postgresql client driver that would make it more difficult to use the OpenACS Postgresql code with Zope? (I just assumed it "works" and will be more suitable for specific Postgresql facilities than going via ODBC, but have no knowledge).

I've used it on a small scale project and it worked fine. It survived the upgrade to PostgreSQL 7.02 as well. I don't know of any specific problems with it - I'd just like it to be part of the standard Zope distribution and treated as a core part of Zope.

2. Is there some difficulty implementing Linux (and FreeBSD etc) ODBC client drivers for Zope that explains why there is only a Win32 ODBC driver?

I really don't know. I asked on zope lists about why the lack of database drivers and was told that DC were supporting Oracle, Sybase and ODBC only. I asked why ODBC was only WIN32 but I didn't get any reply. This was before Chris McDonough joined them 😊 Chris - any news ?

Albert also said -
[AL] Sounds like you could be ideally placed to take the initiative in getting people interested in making it "stand alone" so that it could keep in sync with ACS as well as being available to Zope. Any interest in that cf "forking"?

Like others on this list I'm proceeding slowly down the maze of web development, hoping to avoid dead ends and sometimes walking on top of the hedges to have a better view. I will have hands on ACS (not Open ACS) soon and will be able to see what the capabilities of the system are (in the areas of ecommerce and education mainly). I also intend to keep on with Zope if I can because I think its going to be really, really good ...

Chris McDonough has outlined the constructs in Zope which let you treat the data source in abstraction from the presentation layer. It actually goes further than he mentions - the data returned by a <dtml> tag could be coming from anywhere. The fact that it is coming from a PostgreSQL database (or a Python list) has no impact at all on the presentation of that data.

The clever thing about Zope is that using this approach is really easy and doing it any other way would be more difficult so any Zope application has this abstraction built in.

For example the General User Folder product which is a simple login manager is used to validate user logins and passwords. As supplied these are contained in lists - so the software calls a dtml method called "UserAuthenticate" which just contains the list of valid users
Fred
Joe
Sarah

To change this so that it validate this against an SQL database all you do is to replace the physical list of users with a dtml tag which refers to an SQL method which returns a list of users.

The software which calls "UserAuthenticate" neither knows nor cares whence the data cometh.

So as far as abstraction is concerned as you know I wasn't suggesting that Zope can automagcally optimise SQL requests for various databases. However the application itself needs no knowledge of how to get the data, that can be contained in the method which does the retrieving.

Moving an app from Oracle to PostgreSQL would involve, for example, spoofing OUTER joins wherever they occur, but it would then be easy to have an attribute which you set to say which database was in use, the SQL method would generate the correct code based on the value of the attribute.

Thinking about it you could have a set of attributes for example "outer join supported", "scroll cursors supported","row level locking supported". The correct code could then be generated depending on how those attributes were set. Perhaps 😊

There may be more you can do to make the abstraction more complete, but that would still have no impact on the presentation layer (which only ever needs to call the same method to get, insert, update or delete the data it needs). Therefore you could add better abstraction "underneath" at any time in the future, once the technology is available. In the meantime, hand-optimised SQL code would work well enough.

As to whether I can be of any use, well once I get hands on ACS I'll let you know 😊

There are reliable solutions to this problem.  We had floated the idea of using middleware from Openlink Software (http://www.openlinksw.com) for all our relational database adapters, writing to an interface they provide that abstracts out the connection-layer differences.  But it's not open source, and using more than five connections against any particular database requires a license from Openlink.  I don't exactly know what happened to this plan.  It just sort of fizzled.  We don't want to be in the business of maintaining our existing database adapters every time Oracle or Sybase spurts out a new release.  It's just not a good use of time here.  It would be much better for us to throw this job over the wall to Openlink and write to their interface.  But for now, we're stuck maintaining the ones we've written.

In the meantime (assuming that plan still exists), writing an ODBC DA for Zope on Linux is not high on DC's to-do list, and nobody from the community has stepped up to the plate to make it available.  This is an excellent opportunity for somebody from the community to contribute a piece of software that people ask for from time to time.  It's probably not going to come from DC if somebody else doesn't provide it.

When they don't work with the new version, yes (eg. Oracle 8 --> Oracle 8i).

As far as dealing with a third-party closed-source solution, it's either that or continue to write and maintain lots of them ourselves.  As these sorts of things are driven by consulting engagements, it's only once in a while that we write a new one.  Maintaining existing ones takes time that we don't make any money from.  And as much as we champion open source, we are in business to make money.

As far as depending on open source goes, people from the community don't seem to be flocking to Zope to write quality third-party database adapters (although many folks have already ala MySQL and Postgres, there are some serious holes like DB/2 and Informix).  And when folks like Richard Moon ask me when an ODBC adapter for Linux would be available, if we were using Openlink, I could say "right now" and point him to the Openlink adapter instead of saying "as soon as you write one".

The article also supports my belief that "Z Patterns" is highly relevant both in the Zope ZODB/Z SQL context and in the context of data abstraction for ports of an RDBM based application platform such as ACS between different SQL dialects. I can't imagine how Z Patterns could possibly provide a useful isolation of application issues from fundamentally different persistent storage mechanisms such as ZODB, and a *specific* SQL RDBM (and also LDAP etc) without *also* being useful for managing multiple SQL dialects. (Note the reference to easy porting from ZODB to "Oracle or Sybase").

This of course does not resolve issues about whether "Z patterns" is ready for prime time yet, but whether it is or not, a project such as OpenACS, where multiple SQL dialects is a *fundamental* issue, could only benefit from whatever effort it takes to *very* closely study Z Patterns - if only in the expectation of learning from their mistakes.

BTW the references to "relational storage" below are about use of ZODB stored in an RDBM instead of a flat file or simple dbm - often confused with the entirely different approach of using SQL to a separate RDBM for persistence without ZODB (the article is advocating the latter and explaining how Z Patterns allows easy common application development for either or both).

Seeya, Albert

[reply context snipped]

[Ty Sarna mailto:tsarna@endicor.com ]

Unfortunately, this doesn't deal with cases where the conflicting state
is contained in many objects (see note by PJE in the ZODB Wiki).

Also, there is a whole other area of difficulty for high-write-volume
ZODBs, which is the ammount of IO that needs to be done.  First, by
nature ZODB can't rewrite a single attribute of an object, it has to
rewrite the entire thing.

Indexing is also a bear from an IO perspective.  First, BTrees currently
keep a count at each level, so every change to a btree changes a node at
each level of the BTree.  For a ZCatalog, there are a lot of btrees
(something like 2n+4 for n indexes, I think -- don't quote me on that,
it's been a while), and each one changes (last I looked, every index was
updated even if the value indexed in a particular one hadn't changed.
This may have been improved since).  Not only is this bad from a hotspot
point of view (always a conflict on the root node of the tree), but you
end up doing a *lot* of IO.  During my experiments that led to
BerkeleyStorage, I was watching the Data.fs grow by 47K per transaction
for adding indexed objects of ~1K in size.  Watching this with
tranalyzer, this turns out to be 1K of object, and 46K of updated btree
pages :).  Note that BerkeleyStorage only prevents the file from growing
that much -- it still has to do all that IO (in fact, it has to do ~2-3
times that much IO, due to the nature of BerkeleyDB.  A relational
storage would have similar issues.  For ammount of IO done, FileStorage
is about as efficient as you can possibly be -- it's just that it trades
that off against space reclamation).

Also, with any kind of Berkeley or Relational storage, there is a second
hidden IO and storage penalty: you're storing a btree inside a btree. In
other words, the lower-level DB uses btrees to store your objects,
including interior nodes of the higher-level ZODB btree. Every interior
node of the ZODB Btree needs a leaf node (and supporting interior nodes)
in the DB's btrees. so you get taxed twice, on both I/O and storage
space used.

Not to discourage anyone from using ZODB, necessarily.  There are a lot
of things it's fantastic for, and without a doubt ZODB is getting better
at handling higher write ratios. Over time there will be more and
more applications that previously would have required an external SQL or
other kind of database that can be done in ZODB instead.  However, there
will also IMHO always be applications that ZODB just isn't as suitable
for. You have to thing long and hard before committing to one or ther
other. And then there's the worry of what happens if you chose wrong.

We were faced with exactly these issues, and the extremes of them, to
boot.  We have a *large*, *very* high write ratio, lots of indexes type
of application based on ZPublisher/DTML that we'd like to port
to/replace with something Zope based.  Yet we might need to make another
instance of this same type of application used by only a few people with
a small ammount of data -- it would really suck to have to have to have
another instance of the same expensive database system to support a
miniscule ammount of data, because everything was coded only with SQL in
mind).

This is what led ultimately to ZPatterns -- you can write applications
and not have to decide up front on ZODB or SQL.  And you can change your
mind later (Seen that TV commercial? suddenly your online store is
selling a zillion items per month instead of the 1000 you planned for.
oops!).  You can even decide on an instance by instance basis.  You
configure with ZODB for a small department or client, and Oracle or
Sybase for a huge one -- and the small guy doesn't have to pay for the
DB license and DBA!). Since then, we've discovered a number of other
benefits to the model.

Hmmm... I didn't intend to write a ZPatterns advertisement when I
started, honest! But this seems to have turned into one nonetheless :^)

_______________________________________________
Zope maillist  -  mailto:Zope@zope.org
http://lists.zope.org/mailman/listinfo/zope
**  No cross posts or HTML encoding!  **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope-dev )

Wow ... an interesting thread ... We are building a collaborative website for an engineering firm, and have completed many features already in Zope. However we are now considering trashing everything we've done, for "Other Options" and this week we are reviewing them in depth. I think Zope is an amazing piece of work, but here at least are the reasons so far why I like AOLServer and aD.

• A framework with a security model we can understand without drinking diesel oil and nitroglycerine cocktails.
• A security model that doesn't break so easily (even if we do sacrifice the depth of functionality provided by Zope)
• My files are (and can be without effort!) in folders on a disk
• Everything else is in a ORDBMS which is a.Documented well and b.Already pretty well understood within our team.
• I can still use Python (My favourite language)
• Many ready built modules already in use (i.e. higher version numbers that 0.0.0.0.1 beta alpha zeta z.z release)
• I can use java servlets with Tomcat

Again I think Zope is fantastic but we have just spent so much time trying to figure it all out. Believe me we have have our own custom file system, an online file manager and are also playing with distributing stock prices through it ... Its a big decision coming up.

Our other options under review are Enhydra, Locomotive, hand coded in python or java. I can post the results if anyone is interested. Regards, Paul Gresham

One of the themes of this thread, as I understand it, is that some
of the ACS partisans felt (at the time) that it was better to have a
relatively simple core architecture that is easily understood by
newbies than a complex core architecture that may accomplish
more but is much harder to learn. At least on this specific
philosophical issue, OpenACS 4.x seems to take one or several
steps away from this philosophy and closer to the Zope
philosophy. So the question I'm raising now is not so much
about specific architectural differences between Zope and
OpenACS as it is about general trade-offs between learnability
and the benefits of a relatively complex core.

I am certainly the last person to effectively evaluate this question.
However it is an important one that is closely related to the
branding and marketing issues the community is currently
discussing. Who is this toolkit for? What would be the most
useful to them? Which parts of the architecture need to be easily
learnable, and which parts are OK to make more complex in
exchange for more power or flexibility? Is the best trade-off to
make the core architecture complex but keep the APIs necessary
to create modules simple? Are there parts of the core
architecture that need to be easier to learn than others? Are any
parts of the core architecture in danger of becoming too hard to
learn? These questions are critical to answer if we want to
increase the adoption rate by developers and convince clients
that OpenACS will make it cost-effective for them to train their
staff to maintain and improve a web app built with it.

http:// webware.sourceforge.net

Webware has some nice features, particularly:

• java servlet-esque appserver
• python server pages (copy of .jsp, much like .adp)
• Task Scheduler ( much like ns_schedule_daily)

In the true spirit of open source software, the documentation is not very helpful. If anyone runs into any problems setting this up, feel free to email me about it.

Meanwhile, according to this page at Amazon, Zope has 4 books in print and another 2 expected in 2002 (one of which in Feb).
In a related vein, "Slash", the code behind Slashdot, has a book coming out from O'Reilly--read about it here

I agree learning zope is tough. Not for weak heart, if you are a good python programmer you will master it quickly and appreciate the product.

Zope is envy to other scripting language products. Like any good products zope too is getting lot of criticism from people who don't use it.

-- Yoma