Forum OpenACS Q&A: stupid newbie question

I would like to have the best of both worlds. Some of the ACS 3.25
modules offer functionality I realy would like to make available to
my clients (intranet, homepage, chat, classifieds etc., however 2
diffrent registration processes don't make sense. Is there any way to
create a kind of dual boot, using one registration process?

I also noticed a number of modules have been ported to ACS 4 without
much change. Are there plans to migrate other standard 3.25 modules
to ACS 4 so functionality will be available? It looks like we are
caught in a 'funny'intrim period that creates an additional migration
problem. ACS 4 offers superior solutions on the one hand, but we
still need the traditional approach untill everything is migrated.
Ie. is it possible to create a shortcut to old modules, using the
registration fucntionality of ACS 4?

OACS 4.5 offers compelling reasons to move quickly (eg bind variables, improved security, modular construction). But there are nifty 3.2.5 modules that haven't yet been ported (despite the heroic hard work by the OACS team), and many of us have written other special purpose modules (that lack general interest to the OACS community but nevertheless occupied us to the exclusion of being able to help with porting--mea culpa) that have all sorts of intrinsic 3.2.5isms.

So how are people out there handling this in-between time in their production sites? Who has successfully moved from 3.2.5 to 4.5 and what lessons did you learn that the rest of us should know? Who has decided not to move and what factors did you find most important in that decision? And has anyone experiemented with a "dual" context?

BTW, which are the packages left to port that you feel are most needed?

If you do e search on this forum (as well as on design, I think) you will see that Intranet seems to be one of the most-wanted things that were left out in the porting process (it is also one of the bigger modules, I believe). You will also see that there were a number of claims made about porting it (ranging between "yeah, I played around with it, maybe I can try and port" and "we are very interested in it, we will port it"). Nothing definite has been committed yet anywhere.

Another option (refered to as dotWRK sometimes) mentioned was to use part of dotLRN functionality and build up new Intranet using that. Still just a concept (and I cannot comment any further on it as I had not had a chance to play with dotLRN).

Trying to run 3.x and 4.x side-by-side would, probably, be quite tricky, even on db level. I have not checked, but am pretty sure that quite a few table names will clash, e.g. users, but won't contain the same data. It could be possible to do something like this:

• run AOLServer for 3.x and 4.x on different ports
• have 2 different databases oac3 and oac4 on the back-end
• use 4.x as the main server, automatically register each user that was created in 4.x instance on 3.x instance (will need to create extra db pool on 4.x instance for that, yet remove it from available pools so that NSD does not pick it up automatically)
• if you want intranet -- also make registration of these new users as "intranet" members
• redirect requests for 3.x services to 3.x instance

Not quite a compatibility package, but could allow to run both instances side-by-side. However, future migration may be tricky -- moving all those projects, calendars, comments and forums from 3.x instance would be paaaaaaaainful...