Forum OpenACS Q&A: Fast move from ACS to OpenACS

Collapse
1: Fast move from ACS to OpenACS
Posted by philip jones on 10/02/01 12:32 PM
Hi everyone.

I have a quick question. We've built a system using the ACS 3.4. But
we suddenly, and urgently need to port it to run on PostgreSQL.

We can think of two strategies for this :

1) is to install an OpenACS. Take our system additions, and tweak them
to run on OpenACS. Unfortunately our system was written for ACS 3.4 so
uses functions that aren't in OpenACS 3.2.

2) To take our whole ACS 3.4 based system, and try to port it to
working on PostgreSQL.

So which which do people think would be less work. Porting ACS 3.4 to
run on PostgreSQL or porting an application written for ACS 3.4, back
to OpenACS?

What gotchas are there with either of these two approaches?

Collapse
2: Synchronicity (response to 1)
Posted by Jerry Asher on 10/02/01 01:08 PM
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.

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

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.

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.
Jeez, accoring to NPR, Sting is 50 today

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.

Collapse
3: Response to Fast move from ACS to OpenACS (response to 1)
Posted by Jonathan Ellis on 10/02/01 04:51 PM
re: I ported (presumably) but haven't tested the db_ interface

I've ported and tested and uploaded it as a patch to 3.2.5. (patches 60 and 68).