So what's the scoop? Will ACS keep up? Will it ever have the easy access to seeing all the available components? Is ACS ten times faster?
So what's the scoop? Will ACS keep up? Will it ever have the easy access to seeing all the available components? Is ACS ten times faster?
Easier to setup? I don't really think so. Don't believe everything you read.
Oh, did I mention, one big security nightmare (even Mandrake stopped distributing it).
Jon, please stop spreading FUD.
Security hole ridden? You call something like that because it gets it's security problems fixed? Zope's authors have done a great job in finding, fixing, and distributing hot fixes for their product. Can you say that (Open)ACS is 100% safe with no holes just because no security advisories are issued? Need I remember that day in July 2000, when all aD ACS sites needed to be patched because a really basic security hole?
I will hold my comments about how relevant for a web toolkit's quality is it's inclusion in Mandrake. But, ummm, forgot to ask, is ACS included in Mandrake? No? Whoa, it must suck then...
Van: you picked the wrong place to ask about Zope... I doubt you will get any positive response, and if you do get one, it will likely be the start of a flame war... (do a bboard search for "Zope" and you will see what I mean).
With this backdrop, there's no meaningful comparison to anything: ACS-vs-Zope, ACS-vs-Vignette, ACS-vs-grilled-salmon-sandwich. There are a number of interesting comparisons that could be developed in ACS-vs-Zope, eg, Zope's included OODB vs ACS's RDBMS dependence (better theoretical framework, easy corp integration, etc). You could cover language choice, UI design, and data models; but I don't think you're here for any of that.
There's nothing stopping you from 'getting your feet wet' with either one. We are actively making more pools, and trying to document them - I assure you you won't drown. I see from an earlier post of yours that you have some anxiety about developing on EoL alpha code - I have to assert that general CS skills are more important than preserving first-round code. Besides, you always have to throw the first one away...
No, this was not a troll - I have enough to read without generating new flamewars.
I didn't assume that Zope was better, although the "Will ACS keep up?" comment may have sounded like it. Looking at www.zope.org just shows an incredible amount of product, and though I see references to a lot of components for ACS there isn't anything resembling http://www.zope.org/Products in terms of quickly finding those pieces. (http://www.zope.org/Documentation shows a similar depth to the accessible documentation.) It's a lot harder to find a place to get started with OpenACS.
I asked "Is ACS ten times faster?" because one of the first things I read was from Philip (in Web Whore) talking about the inherent speed advantage of AOLServer. Performance is one of the reasons a developer would choose a more arcane or expensive system over a more easily deployed one. (It's certainly why I'm struggling with Linux after years of Macintosh and Windows use.)
Incidentally, I do expect to get a positive response here. Reading messages here over the last year makes it very clear that this is one of the more civilized and forthcoming environments in which to ask questions, including those that get right down to questioning the use of ACS itself.
And one point I didn't raise before: the impetus behind ACS was Philip Greenspun, where is he now? I haven't seen anything lately regarding his departure from AD and have to wonder what effect that will have on ACS and OpenACS over the next few months to years.
I've just become aware of the buzz around Zope. My personal style is that I'm slow to get going, slow moving once going, a bit lazy, but I tend to overcome this with tenacity. Which means it's really, really bad when I get started on a dead end.
I will address one question directly, "will ACS keep up?". I don't believe this is a valid question as OpenACS and Zope are vastly different beasts. Zope is an application server that, to me, does provide a good environment for building database-backed websites. However, I do believe that the volume of products listed on the Zope site is somewhat misleading. When I looked at Zope 12 months ago, most of the "products" were very tightly focused utility type programs as opposed to fully functional products.
OpenACS is a pre-built application for implementing community-based websites. Out of the box, it provides 90 % of the functionality that I needed to implement the site for the news publication. The only major modification that I made was to implement an edition/time-based model for the the news module. I haven't looked at Zope in 12 months, so I can't say what it can do now, but at the time I would have been building most of the functionality of the website from scratch.
Also, as I recall, Zope was no easier to install and get running than OpenACS. And remember, the truly valid metric is not how quickly and easily the base platform/tool is to set-up, but rather how soon do you have a production site that meets your requirements.
I am unclear about the differences. ACS has a data model built *precisely* for collaborative and community web applications. 4.X is a major upgrade from 3.X and will provide a great deal of modularity and functionality that was not or could not be provided elegantly in 3.X. It is built for RDBMS's to ensure that it is absolutely suitable for enterprise class systems. The entire focus is on providing transparency among users to enable collaboration in ways that are fast, intelligent and robust. AOLserver is used mainly, but there are strong efforts to update mod_aolserver to mod_nsd so that it can use Apache, either 1.3.X or 2.X.
As far as Zope, I must admit that I know next to nothing about it. From what I know of it, it's primarily a content management system that can do other cool stuff as well. Also, I've heard is that it has a wealth of "utilities" that let it do reasonably cool things (easy server side PDF generation, Outlook synchronization, etc .. but nothing that can't be built into openacs reasonably quickly) and a large user base. It has it's own OODB, which seems to be pretty cool if you are doing some limited website where you just need content management. For real DB applications, you can connect it to a true RDBMS (from Oracle to Postgres). It has a built in server, but it also can use Apache.
In terms of comparison, if you want a good system for content management then Zope is a better choice for now (CMS in the ACS is horrible, at least what aD put out initially and what will be available in OpenACS4.x for its release, but stay tuned, that will change shortly...).
However, it would take *a lot* of work to build into Zope the kind of attention to user interaction and collaboration that is available in the ACS. From our initial research, for instance, there is no equivalent to the bboards system and the being able to view a user's total postings and history in Zope like ACS has out of the box. Also, the ACS has major systems built into like a workflow engine which has been out for a year while Zope just released the specs for theirs in the past few weeks.
So if you're looking for a system for massive DB applications that rely on particular attention to the user's participation, then there really isn't anything that beats the ACS. We think that this is the major win for the ACS and why something like CMS isn't too important for us. A reasonable CMS can be built relatively painlessly, and if you want a CMS with a workflow engine than you spend a lot more money and get somebody that understands what aD did and he'll kludge something for you ;).
As far as the user and developer community, Zope has a much larger one. I can't comment on the quality of it, but I know that Petru (who posted earlier) is involved there and I am very confident in his capabilities. If he says they are pretty good, then I believe him to the degree that I will admit I am agnostic.
However, I *know* the ACS developer community is *outstanding*. There are a lot of really committed and intelligent, albeit a bit surly sometimes, developers here that are doing an amazing job porting the system to Postgres. I fully expect that OpenACS4.X will be a better system than ACS Java for at least a year, given the energy and process it takes to port a system to a knew language.
Also, some of the best ACS developers have always been on this side, rather in the belly of the beast. Not that it's so bad to be at aD, not at all. Just that the kind of development that has gone on over here has been incredible considering we don't have near the amount of resources aD has. As far as Philip's involvement, sometimes it's best that the shepard let's his flock wander away. He was never actively involved on this side anyway.
So I think the basic point is that ACS and Zope have very different core competencies. Zope is a good content management system for which you can build DB applications with (from what I hear because I have no experience with the system). ACS is a great RAD for enterprise class DB applications that require detailed information on how, why, what and where participants used the system. I'm not sure if that is available in Zope, and if not how long it would take to build it into the system.
Hope this helps. If somebody with experience with Zope development wants to chime in, I'd really appreciate it.
ACS classic will never be included because it depends on Oracle.
Zope was such a problem Mandrake stopped distributing it because every other week there was another "hot fix".
I don't think they do it nearly as well as we do hear. If there are ways of doing it better in Zope, I don't think they make a very striking case since they don't use it themselves. Although they do give you a link to eGroups (ech).
If I may volunteer them, I would ask Petru Paler and Kapil Thangavelu to comment a little in this thread about some of the differences, strengths and weaknesses between Zope and ACS. I know they are both familiar with these systems.
Also, Jon, can you elaborate some on the security flaws in Zope?
here it is:
Here's the page with the complete listing of Zope hotfixes: http://www.zope.org/Products/Zope/hotfixes.
ACS and Zope come from two very different schools of thought. ACS is more of an evolution of the "page-centric" philosophy most web applications are built on, i.e. most of the stuff done with php, mod_perl etc. AOLserver, php, mod_perl and others all essentially all provide the same essential things, i.e. an in-process script interpreter and db connection pooling. What really makes ACS stand out from these is the sheer number of features it has, and it's all integrated. Certainly you can find some webmail package, some other bulletin board package and a news package in say php which may have some advantages over the corresponding module in ACS. Integrate them with each other? Get prepared for a _veery_ long hacking session.
Zope, on the other hand, is rather different. I have the impression zope really started as an experiment on how to publish objects on the web. What zope essentially is then, is a container for a special kind of objects (I'm not that familiar with Zope, but I think this is the famous ZClass class..). When you request an URL zope checks security etc. and then calls the publish (or whatever it's called) method on the object identified by the URL.
As for Zope Products, they are similar in concept to ACS modules. But as ACS already contains all the modules, it's not really fair to say that there are lots of add-on modules on the Zope site -> Zope must be better. When you do a clean install of Zope you get only the container itself and the security framework.
Last summer I made an intranet site for a medium sized company (about 200 persons) and some web based reporting applications for a couple of db-based applications they had. I had enough independency to be able to choose how I implemented stuff myself, so I evaluated a few of the things available. After some quick looks at php, perl and enhydra (a java app server) I looked a little more closely at ACS and Zope. I ended up with OpenACS primarily because the intranet module had pretty much what I wanted, and I think the RDBMS api of AOLserver/ACS is much better than that of Zope. Granted, Zope has some rather cool features, but I got quite annoyed at the web interface and having to use the integrated object database (yes you can export most of it with ftp/webdav but it's somewhat kludgy, imho, and I like to bang around with emacs, grep and other "classic" unix tools).
This winter I got involved in a startup, and I was tasked with choosing the technology platform. After a rather lot of reading, evaluating and discussing with the other people at the company, I chose Java. Before you dismiss me as another guy-in-a-suit-who-reads-those-really-stupid-magazines let me point out the reasons.
-Everybody at the company knows Java. Recruiting also seems good because most universities teach Java at least in their introductory courses. -Broad industry support. For web applications, Java and MS ASP (and soon .NET) are the two technologies most unlikely to go away in the near future. -Name recognition. If we tell out customer we use Java, the guy in the suit might get that warm fuzzy feeling. If we tell him we use AOLserver + ACS, he's not going to know what it is. -Lots of documentation -Lots of infrastructure. Look at all the stuff included in a J2EE app server. While most of it may be overkill for many web applications, it's reassuring to know that the stuff is there if you need it. -At the time, the future of ACS looked uncertain with Phil evidently leaving Ars Digita. Also the fact that Ars Digita were (and still are) on the way to convert to Java boosted the feeling that Java would be the right choice (and I still feel I made the right choice, btw). -While developing plain servlets or JSP:s is slow compared to php/perl/tcl things like JSP taglibs coupled with the "Model 2" architecture (see for example the Jakarta Struts project / alternatively a plethora of alternatives to JSP exist) provide speed of development, and a clean separation of presentation and logic (important if we bring in html people who don't know sh*t about programming).