Forum OpenACS Q&A: Response to Planning a migration from ACS 3.4.x to OpenACS?

Collapse
8: Response to Planning a migration from ACS 3.4.x to OpenACS? (response to 1)
Posted by Malte Sussdorff on 10/25/01 11:02 PM
Okay, sorry for stepping in a little bit late on that issue. Nonetheless:
  1. We run on ACES. One strong reason we picked it was my conviction that MIT wants to migraate their current data into .LRN which will be OpenACS based. Which leads to
  2. yes, and we should work together with OpenForce, if they want to.
  3. We will keep an ACES 3.x version running and integration all the code we get from people. The current problem is time on our side. The way I see it, we have an improved ACES version from Sloan. Add to this bugfixes made on our ACES installation. Plug in Jade's intranet and Carolines other improvements. Should make a decent package. There are problems though, which I'll come too.
  4. In my opinion OpenACS is the way to go in the long run. At the current moment the only reason for sticking with 3.4.x is that it is running in so many different places realiably, why change. Just make sure you can migrate your data. And if I'm not mistaken, not only Sloan is migrating data to OpenACS but some other company starting with an A is working on it too.
  5. Hand over your intranet module. I'm more than happy to integrate it with the ACES package to ship it around.
Okay, now for the problems:
  • Our ACES version is geared towards performance. Permission model sucks big donkey balls, Subgroups work more or less. We run at 40.000 users with 6000 groups and an average participation of 10 groups per person. So we were forced to get rid of everything which looked remotly like "sophisticated" permissioning and group system. Bringing this back into the main trunck is a little bit more work down the road.
  • ACES Sloan does not install out of the box.
  • Who is to decide, what package version will stay in the distribution. IMHO I'd use improved ACES/Sloan as a basis, drop the old bboard (though we still use it), take the munich file storage (we have it), add general alerts and survey, take the new intranet and integrate Carolines source codes. But why should this be the wisest thing to do 😉.
  • Who is going to test this, where is it going to run live with users. My idea is to setup ACES for german universities to test it out. Like an ASP approach. But see my problem. ACES does not support multilinguality (well, with out patch yes, but who is going to wrap TRN tags around every english paragraph in the ACES). A fork (again) for a german version (oh, I forgot, I have a germanised version made by my students, this is I guess the 5th version of ACS 3.4.x we talk about)
So, where does this leave us? well, my current motivation goes into the direction of hiring an ACS developer in India, have him integrate all the ACES code into one package running out of the box and deliver it as a christmas gift to the community.

Still, I would love to see this stay an open process. So what I will do is upload the latest CVS checkout from the AIESEC.NET source as well as the ACES / Sloan package to www.sussdorff.org. Download it from there and play around with it. I can even start to host the CVS repository if you want. This would first consist of the ACES / Sloan package and further additions could be checked in by the various parties interested.