Forum OpenACS Q&A: Synchronicity
Like just four days ago, I sent this message to Ben:
I am currently running an OpenACS 3.2.5/ACS 3.4.10 hybrid.Anyway, based on a two day trial, I would choose Plan 1. It appeared to be relatively easy to get 3.4.10 stuff working on 3.2.Yes, I've ignored warnings from concerned scientists around the world, and I've been busy implanting the DNA from ACS 3.4.10 in an attempt to make a superior OpenACS 3.2.6 progeny.
Okay strike that last bit. But, I've got OpenACS 3.2.5 to use the newer forms of proc_doc, ad_proc, and ad_page_contract. It boots from a combination of /tcl files and /package/acs-core/*proc files
Random notes:
- I started this as I wanted to make use of ad_html_security_check, and the port of one function led to another.... I also wanted to use ad_page_contract and it's data validation and filtering system and newer forms of ad_proc that support boolean switches and things like that. All of this is currently working, and I am quite pleased with the effort.
- There was some nastiness in the ad_scope stuff. Man, folks that gratuitously uplevel to level 1 for side effects should be given a kick upvar their butt. Worse: pukes that gratuitously uplevel to a magic stack level that they had to determine at runtime was the right stack level and therefore ensuring that it is virtually impossible to add new code paths (Oh, let's just uplevel to level 2 without a single comment explaining why 2 and not 1, or 4 or 84). The ad_scope code relied on aD's version of ns_sourceproc which in 3.4.10 was much worse than AOL's version. AOL's version of ns_sourceproc cached tcl bytes, aD version did not. In doing so though, the AOL version added another level to the stack frame, thereby breaking ad_scope. Fixed with some ugliness that crawls up the stack looking for one of a number of known routines -- when it finds ns_sourceproc or ad_handle_filter on the stack, it then determines which level to uplevel to. Excuse while I empty this barf bag.
- I ported (presumably) but haven't tested the db_ interface.
- Between 3.2.5 and 3.4.10 there were about a dozen or so functions that have the same names but different interfaces (involving the removal of a db handle or substitution of a sql name for the db handle.) This means you have to make a decision for a variety of functions: use the 3.2.5 forms throughout your system, use the 3.4.10 form, or change the names of one of the forms and migrate those changes throughout.
- Similarly, there are a variety of functions bt_mergepiece, and ad_dateentrywidget for example that in 3.2.5 liked to create form fields with names that started with "ColValue". By 3.4.10, that was changed. So you have to decide which version to use, and you need to be consistent througout.
- Emacs, TAGS, egrep, and tags-query-replace are your friends.
- I didn't touch/use the APM system, and so my system won't load 3.4.10 packages. That's my big regret at the moment.
- My system boots from the packages/acs-core directory, mostly, and I don't use the older
.preload files. This choice was made, mainly for laziness (I mean forward thinking), so I could finally get emacs to read the "equivalent" file, already named .tcl and switch to tcl mode. I know, I know, I could've munged my .emacs years ago. - You should consider porting your package to OpenACS 4.
If you are interested, I could probably just tar /tcl and /packages/acs-core/tcl for you. That should give you a good starting point.
And of course, as an independent consultant, I am available to help you further with your efforts.
