Forum OpenACS Development: Is ArsDigita forking the ACS?
decided to copy the text of the question here because I am very
curious about the OpenACS community's thoughts on this issue.
Given that the move from ACS 3.x to ACS 4.0 is quite clearly a move
towards tighter integration with Oracle, I am particular curious to
know what people within the OpenACS movement think the benefits of
following ArsDigita on this path would be.
Here is a copy of my posting:
I am concerned with the possibility that ArsDigita may have forked
their own code. Over the last 6 months I have been working on the
www.infoconomy.com project at Runtime Collective and so have become
intimately familiar with the ACS 3.2 system. I was and remain very
inspired and grateful for the open source movement and ArsDigita's
commitment to it. I have been working rather head down on the project,
but now that things are calming down I am looking to get more actively
involved in the ACS open source communities. However a number of the
technology choices made by ArsDigita have rather perplexed me.
In constructing ACS 4.0 it appears as if ArsDigita are moving to
re-write the code base in a more object oriented (ish) way by using
the programming environment provided by Oracle's PL/SQL. I've looked
through a fair amount of the on-line documentation and in general the
growing level of integration with Oracle concerns me deeply. What was
the reasoning behind tighter integration with Oracle rather than a
functional, (potentially cached) interface to the database ?
As a founder of an open source community I would have thought that
ArsDigita would be interested in a layered architecture built on open
standards. Such an architecture would allow OpenACS to easily swap
Postgres instead of Oracle for example. It would also enable some
members of the community to make a cleaner movement away from the
AOLServer onto Apache.
Furthermore, tighter integration with the database makes it harder to
treat different services as being provided by different physical
servers. In ACS 4.0 how easy would it be to have a separate `content
repository' server which delivers the content to both an intranet
workflow server and a public web site? Most of the live content should
end up cached on the public server anyway, so there is little need for
the public server to have a complete replica of the whole
database (indeed if any database at all). My impression is that with
ACS 4.0 a 3 server architecture as I have just described would
probably need 3 Oracle licenses - a fair cost for most projects
(especially if ACS 4.0 requires EE Oracle).
I completely understand the desire to have rationalised the ACS code,
most especially I like the basic thinking behind the request processor
and having a single content repository for all site wide content.
Indeed if we lived in a world where there was only AOLserver, Oracle
PL/SQL and tcl then the developments that ArsDigita have made are
impressive.
What concerns me is that the jump between ACS 3.x and ACS 4.0 is too
big and too Oracle specific for there to be much incentive to
follow. This is especially true as there are other ways to rationalise
the code that would solve some design concerns regarding ACS 3.x.
Indeed if we have to re-write the whole code base in an object
oriented (ish) way in a new language (PL/SQL), why not put the effort
into a different language - a lot of the knowledge could transfer
quite simply and there would be some significant advantages to using
the Apache web server.
So have ArsDigita potentially forked their own code? Why should the
rest of the ACS community follow ArsDigita down this Oracle dependant
route? Won't the effort to re-write everything into ACS 4.0 be much
greater than the cost of rationalising an open standards functional
tcl interface to the database and web server?
Why should we upgrade from 3.x to ACS 2000?
Please ArsDigita, convince me to sign up to ACS 4.0
<p>
<i>"As a founder of an open source community I would have thought that ArsDigita would be interested in a layered
architecture built on open standards. Such an architecture would allow OpenACS to easily swap Postgres instead of
Oracle for example. " </i>
<p>This would be nice, but perhaps not doable right now.
<p><i>"It would also enable some members of the community to make a cleaner movement away from the AOLServer onto Apache. "</i>
<p>You don't have to use AOLserver anymore. If you are tied to Apache or IIS, (Open)ACS will run just fine on these web servers with the appropriate module. AOLserver is still much more efficient so that's the way ArsDigita went.
<p><i>"What concerns me is that the jump between ACS 3.x and ACS 4.0 is too big and too Oracle specific for there to be much
incentive to follow."</i>
<p>The jump is big but IMHO it's way worth it. I wish we all had an open source database of the caliber of Oracle too and then everything could be built on an open standard. Join the OpenACS project and help us port ACS 4 to PostgreSQL (and possibly InterBase).
a) like to give something back to the community, and
b) raise the profile of the ACS (which is, I guess, a case of enlightened self-interest.)
Our issue, though, is with Ars Digita's increasingly close integration with Oracle. We would like to produce communities for non profit organizations who can't afford to buy (or even host) Enterprise Oracle. We'd like to have the option of using Apache instead of AOLserver. Etc, etc.
Now the OpenACS project looks like the obvious place to go. But, and I know I'm going to maybe get myself into trouble here, I'd like to ask a couple of impolite questions :
What are OpenACS's intentions?
And how viable a community is it?
(Ouch! That felt like the community just asked for my daughter's hand in marriage 😊
What I mean is, originally it looked as though OpenACS might provide a viable community around a version 3.x of the ACS (which we were looking for because our code is for 3.x). More recently it seems that the OpenACS project is commited to implementing ACS 4. From the questions I've been reading here, and the slightly wistful answers Ben and other have been giving, I get the impression that the OpenACS community is not particularly happy with the way Ars Digita are going - let's face it, it's just making extra work - but don't feel any option but to trail along after it because
a) AD don't care enough about OpenACS to give up the benefits of closer Oracle integration to support them
and
b) because OpenACS don't feel they command enough support within the wider ACS developer community to try to persuade AD against this move.
So instead OpenACS is going to try to "emulate" the core of ACS 4. But with all due respect, this seems like a game OpenACS can't possibly win, playing catch-up with, not only Ars Digita, but Oracle as well. I understand perfectly the motivations for AD's increasing Oracle dependency. As Karl Goldstein puts it in the ACS guide to working with XML : "the ArsDigita philosophy is not to put stuff into our toolkit that is part of the core Oracle RDBMS. Oracle Corporation has thousands of programmers, their most reliable product is the core
RDBMS server, they have documentation, training, support, etc."
In other words, AD are symbiotically dependent on Oracle, and will delegate as much to it as possible. Presumably, whatever new services Oracle add will end up as part of the ACS too. Great! But Oracle has no motive to make things easier for an Open Source rival. They may even be able to subtly "embrace and extend" the ACS.
My aim here, though, is not to criticise AD, or even Oracle, to but to start a discussion to guage how important the OpenACS is within the larger community of ACS developers. Is my characterization of the relationship between AD and OpenACS correct or not? I don't wish to disparage OpenACS, rather, I wonder whether OpenACS is the nearest thing there is to an independent coalition of developers interested in the ACS who, together, have the authority to talk to and negotiate with AD on some of these issues.
>>>>> "phil" == bboardwrites: phil> I think one of the reasons that Oli forwarded the above phil> message to OpenACS is that we (I'm from the same company) phil> are very seriously considering joining and contributing to phil> the OpenACS project, not just on a personal basis but as a phil> company policy. We've now delivered a couple of systems phil> using ACS code and would More help is always welcome. phil> What I mean is, originally it looked as though OpenACS might phil> provide a viable community around a version 3.x of the ACS phil> (which we were looking for because our code is for phil> 3.x). More recently it seems that the OpenACS project is phil> commited to implementing ACS 4. From the questions I've been phil> reading here, and the slightly wistful answers Ben and other phil> have been giving, I get the impression that the OpenACS phil> community is not particularly happy with the way Ars Digita phil> are going - let's face it, it's just making extra work - but phil> don't feel any option but to trail along after it because I can't speak for everybody, but I'm actually quite happy with the direction that aD has taken with the acs 4.0 version. They have addressed a lot of the shortcomings of the 3.x series, and they have actually added some features that make porting much simpler - take a look at the new db api. The new db api provides a common point for all db queries which allows us to intercept and rewrite queries to conform to a postgresql format. phil> a) AD don't care enough about OpenACS to give up the phil> benefits of closer Oracle integration to support them They've actually made an effort to help us make the porting effort easier. aD has also been considering an interbase port, so it's in their best interest to make it easier to use different databases. phil> So instead OpenACS is going to try to "emulate" the core of phil> ACS 4. But with all due respect, this seems like a game phil> OpenACS can't possibly win, playing catch-up with, not only phil> Ars Digita, but Oracle as well. I disagree. Porting is much easier than development, and there are no show-stoppers in the acs 4.0 code that prevent us from porting it to postgresql. Postgresql also has some object-oriented features which make the implementation of objects much easier in postgresql than in oracle. phil> In other words, AD are symbiotically dependent on Oracle, phil> and will delegate as much to it as possible. Presumably, phil> whatever new services Oracle add will end up as part of the phil> ACS too. Great! But Oracle has no motive to make things phil> easier for an Open Source rival. They may even be able to phil> subtly "embrace and extend" the ACS. If that were their strategy, they could just make acs closed-source - end of story. phil> My aim here, though, is not to criticise AD, or even Oracle, phil> to but to start a discussion to guage how important the phil> OpenACS is within the larger community of ACS developers. Is phil> my characterization of the relationship between AD and phil> OpenACS correct or not? I don't think that you're seeing everything clearly. For the most part, acs 4.0 seems to be a huge improvement over the 3.x series, and I think it's in our best interest to port this new version.
OpenACS' intention is to bring the butt-kicking ACS to a completely open source environment. That means porting it to Free (speech) databases such as PostgreSQL and Interbase.
How viable a community OpenACS is? Just look at the download numbers... thousands in every release. Hundreds of postings in our bboards. Lots of bug reports and community assistance in porting the code. I'd say it's a pretty good community.
On "aD doesn't care about OpenACS" issue, I don't think it is that way. I met with Adam Farkas (Developer Relations for aD) in September and we had long talks about ACS 4 and OpenACS and aD is supporting it and making moves toward making things better and easier for us. Look for postings by Adam here at this bboard and you'll find that more than once he requested OpenACS developers and users to give feedback on ACS 4's design prior to release.
I agree with Dan that porting is much easier than developing. The problems that ACS is out to solve are not trivial, and there are dozens of bloated, hyped, and/or closed-source similars out there. I am glad that we have an enterprise-level piece of software to port.
of ACS for quite a while. They just released a brand new version
(4.0!) which involved significant developer resources. The Java
version is also quite immature in comparison. I think that for the
next year and possibly the next 2 years, the Tcl version will be
alive and well. As for what will be in 2 years.... who can tell for any
company?
I also want to confirm what's been mentioned by the rest of the
team: ACS 4.0 is indeed a complete rewrite, and that is a good
thing. While I have been frustrated in the past with aD's
approach, they have significantly changed their ways: a public
CVS tree, meetings with OpenACS members to discuss design,
a better level of DB abstraction. aD's attitude today is not perfect
with respect to the open-source community, but it has improved
significantly, and they "get it" more and more every day.
As much as I can speak for the "community's intent," I'll say that
we want to port ACS 4.0, because it is a good system. Yes, it
makes use of Oracle-specific features like PL/SQL packages,
but did you really expect aD to ignore all Oracle-specific
features? Should we, members of the OpenACS team, not use
PostgreSQL's object-relational features because other RDBMS's
don't have them?
Why should you upgrade to 4.0? Because it's a significantly
better, well thought-out, extensible, and powerful web toolkit. But
don't take my word for it. Join the team, by all means, contribute,
and watch the system progress. I'm excited to see the result we'll
come up with.
I agree strongly that aD seem to be 'getting it' more and more, though perhaps still with a little way to go. And the redesign of 4.0 so far looks really good. I still think they could have gone a little further in putting Oracle specific stuff behind an interface (as they did with (e.g. db_sysdate, db_nextval) - see my other posts.
On aD and Java: (from Lars)
Why do we work in Java at all? Bottom line is that potential clients laugh at us when we say Tcl. They want to see Java. Also, there are lot more libraries and a lot more Java developers than there are Tcl, and, most importantly, Java is improving at a much faster pace than Tcl is. We've had to escape into Java at times, to get to the libraries we need (e.g. email MIME parsing, LDAP client). We'll most likely never have to go the other way around: escape into Tcl to get things done from Java.