Forum OpenACS Q&A: Re: Will Dr. OpenACS survive? Or why I stopped worrying and learned to love the .LRN consortium?

"But to get to the point of using the framework to solve problems that generally arise we encounter a learning curve of the framework. Although Openacs provides a certain degree of abstraction IMHO its not enough."

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.

I guess I would be dissatisfied with Ruby/Python as well as frameworks based on them at some point of time 😉 as I am with TCL in Openacs land but in general I have been very impressed with what Openacs can do for me. At the end of the day I see it as cool toolkit which enables me to solve problems quite effectively.

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.

Collapse
Posted by Andrew Piskorski on
Don, if PostgreSQL 8.0 had been released 4+ years ago I probably wouldn't be using Oracle at all, either. And, probably, if 8 or 9 years ago Illustra (PostgreSQL's uncle?) had worked half as well as PostgreSQL does now, Philip would never have even tried Oracle, and ACS and OpenACS never would have used it all!

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?