Forum OpenACS Q&A: Re: Will Dr. OpenACS survive? Or why I stopped worrying and learned to love the .LRN consortium?
OpenACS is a far too much a grab bag of things. In some areas our abstractions aren't orthoganal therefore less useful than they should be (a bunch of things that only apply to the content repository, rather than all objects, for historical reasons, being the primary example).
This has more to do with a messy implementation and design history than the choice of implementation language. If a modern OO language had been used, we'd still have a system with a content repository built by aD folks on the west coast who made no effort to work with their peers at aD on the east cost, glued to the side of the ACS kernel developed by those east coast aD'ers.
That was due to poor software project (or software company) management ... not programming paradigm. Or, more fairly perhaps, it was simply a reflection of the fact that aD had a bunch of high-visibility clients demanding that complex projects get done in a short period of time.
We can't shed our history, though. That's why I fundamentally find these discussions not very interesting.
We'd make different choices if we were to start over ... but unless we're willing to start over, we're stuck with the history.
One example has to do with RDBMS support. If we were starting the project today, we'd ignore Oracle, I'm sure of it. Many of us would jettison Oracle today if it weren't for legacy users. It would greatly decrease our maintenance efforts and would simplify new development if we only had to develop for Postgres.
Yet, when we made the decision to support PG and Oracle equally when we took over the code base from aD, it was undoubtably the right decision. Malte had an early success story, being able to support a client's ACS 4.x packages on an early OpenACS core seamlessly, others had similar experiences. It gave our project legitimacy and led to a steady trickle of ex-aD'ers becoming part of our project.
But viewed from today's perspective ... man, it sucks having to support two RDBMS's. Imagine a toolkit without a single .XQL file!
History is like that.
My experiences with other frameworks made me really appreciate the openacs community , the focus and quality of the contributors.
This particular thing got me started to ask my programmer friends to take a look at openacs and its possibilities. The intial reaction was the "TCLing" feeling and the difficulty they faced firing up an instance without going through a lot of technical hazzles. My exploration is in the direction of making openacs interesting enough for increasing adoption among developers. Most need simple and quick way of demonstrating the development of an application like how Rails provides ( without having to go through the learning curve). I believe this is a very potent approach.
But I guess we are getting there partly with the installer.
But, fundamentally, why is supporting multiple databases so costly in OpenACS? And must it necessarily be so? (I suspect the answer is "mostly yes", but I am not at all sure.)
ACS 4.0 added the first hooks for multi-db support, but at the same time also made multi-db support harder by moving so much functionality into PL/SQL code. That seems rather ironic.
Lots of other projects claim to support every database under the sun, and even that doing so is easy. My impression however, is that most of those do so via dead-simple data models, and generally making trivial demands on the RDBMS. And thus presumably many of those applications pay an extremely heavy price for their "multi-RDBMS support", whether their authors realize that or not. (The cost is merely hidden under other accounts, like "can't scale" and "general suckiness".)
Considering alternate realities can be educational, sometimes. So, what I'm wondering about, is or was there some middle ground? Some way that, if you were hypothetically starting from scratch, you could get 80 to 90% of the RDBMS power goodness of OpenACS, while reducing the cost of multi-db support down to, say, 10% of what it is now?