Forum .LRN Q&A: Re: interesting chat about moodle / .LRN

Hy guys. I know this topic is a little bit old, but it's a very interesting discussion. Our framework (.LRN) is very difficult to install. It took me one week just to learn how to do it.

However we, from Tekne Digital in Brasil, developed some kind of installer, were you can select everything you want to install. You can choose some of the libs and even the aolserver. Well, it's quite simple, and if you guys want, I can put it here for you to see. It's a shell-based code made mostly for Debian, but I'm sure it works on most Linux versions.

If you want, post here and I can put it for Download.

Greetings!

First off, after looking around at a number of CMS / CLMSs (Moodle, drupal, openACS/DotLRN, Centre, webgui), I believe that openACS/DotLRN is worth the hassle to install. So, I will plow through the problems necessary to do so. Just from the aspect of security alone it is worth the cost.

But, I am here to tell you, it should not be as difficult as it is. Each and every flavor of linux has some sort of package manager. My favorite distro is gentoo, and if I ever figure out what works with what, I will generate the ebuilds required to install openACS, and then dotLRN. Then, my install is as complicated as this:

emerge -uvDN www-servers/aolserver
emerge -uvDN www-misc/nscache
emerge -uvDN www-misc/nsopenssl
emerge -uvDN www-misc/nssha1
emerge -uvDN www-misc/nsxml
emerge -uvDN www-servers/aolserver
emerge -uvDN dev-db/postgresql
emerge -uvDN www-apps/openACS
emerge -uvDN www-apps/dotLRN

I have built aolserver and all it's modules, openACS, and dotLRN from source, it's not too terribly complicated, it is just time consuming. The problem I ran into over and over again had to do with compatiblity, and the lack of clear, concise, and accurate documentation. What works with what?
I have found the compatibilty matrix for openACS, but not dotlrn...

As it stands now, it appears that the latest release of dotLRN only runs on OpenACS Core 5.1.5, which will not run
on postgresql 8.x, only 7.4.X.

I believe that part of the problem comes from the programming style used in openACS. If the database calls were abstracted, it wouldn't matter which db, or version of db I have installed. db calls would be generic, and the db handler would handle specific calls to specific databases.
That would also speed development. Instead of coding, testing, debugging to both postgres & oracle, most code would make calls to the db handler.

...and as long as I am rambling, the same concept could be (should be?) used for all ns_ and nsv_ function calls. Every single one of those calls ties OpenACS specifically to the aolserver. I guess the real question there is would it kill performance to abstract those function calls and then build server specific modules to translate?

-al