Forum OpenACS Q&A: stupid newbie question
anyway as I am confused. We just installed ACS 4, and I must say, I
realy like what I see. Although I don't understand to much of the
datamodel after a few hours playing around and activating the modules
I realize the concept is different. I like the simplified approach
and the enhancements but...
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?
3.4, and I'd also like to take advantage of OACS 4.x based
functionality. If there was a way we could use both while I ported
each module, it would be so much easier for me.
I really haven't thought about this too much, but could you install
3.x to listen on one port, and 4.x to listen on another, and then
modify the registration system to use 4.x on both? It would take
some customization, because as far as I understand, the user
data model is totally different, so it would take some
basterdization of your 3.x system...
I guess you'd probably need two different Aolservers running,
each one with its own set of procs and so on.
Anybody else thought about this very much? Would this be
easier than just biting the bullet and porting everything to 4.x?
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?
package, which would offer older packages (for ACS 3.4.x and
OACS 3.x) a very close approximation to the API they use. They
could be different, but just close enough that porting to the
compatibility package would be less effort than porting the entire
thing over outright. Is this at all feasible? I don't know the OACS
4.5 toolkit enough to know.
So for example, they would provide wrappers to the
authentication routines, and so on. Maybe they could be called
the backwards compatibility API, or something like that..
BTW, which are the packages left to port that you feel are most needed?
I don't know Postgres that well, but in Oracle you can have separate users for your tablespaces (I believe). Is that what you did here?
Besides internal, proprietary stuff, the biggest thing I see missing from OACS 4.x is the Intranet module.
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...
This is one thing that someone new to the BBoards may miss, because naturally, developers here want to "do it right" for 4.x. But in many ways, the older simpler 3.x style, while less powerful, offered an easier learning curve. Personally, if I was reviving the old training Bootcamps, I'd probably have the first couple exercises focus solely on building database-backed web apps in general, using the simpler ACS 3.x style, then use transforming those apps to use the more sophisticated OpenACS 4.x services as the next exercise. I think the same approach to buidling your own apps could work nicely as well, for folks new to OpenACS who just really want to something working quickly.
Of course, once you're already familiar with OpenACS 4.x than using its services doesn't slow you down, and is definitely the better way to go. But when porting old code, converting it cleanly to the 4.x style is probably always going to be more work than just shoe-horning the old stuff in with minimal changes, no matter how much of an OpenACS guru you are.
port the old Ecommerce to OACS 4? That could be valuable for
us who will eventually be upgrading.