Here's one possible way to solve that problem:
(1) Program a package, let's call it "ID Remapper". The package uses
a .vuh to respond to any URL comming in and uses a lookup table
to figure out the appropriate redirector. ID Remapper should be
configurable so you can make it respond to bboard URLs, news URLS
etc. You should be able to specify the last part of the URL as
well as the name of the relevant form variable to look at.
(2) Mount an instance of URL Remapper to every site_node you used to
have on the old site.
(3) Migrate the old site in such a way that you never use the same
URLs as in the old site. Store the id-to-id mapping that will be
used as a lookup tible for the "URL Remapper"
BTW it has occured to me on a several occasions before that although
it is a nice idea to have just one site-wide sequence of objects
for internal use (although I am one of those who would largely
reduce number of things we call objects), it is perhaps a bad idea to expose that sequence
to the outside world. Lars's painful experience proves that. As
OpenACS sites mature it will be increasingly important to be able
to move things around - merge two sites into one, split a site into
two etc. Scripts that upgrade from one version to another won't
solve this problem.
Maybe it wouldn't be a bad idea to use one sequence per app. instance
solely for the purpose of URLs for referencing content - a composite
candidate key consisting of package_id and the "local" object_id.
As new
pieces of content don't get created so often, we don't really need
database sequences for that, just a database cell storing the last
used ID per app. instance and object type.
That way, if I create a new forum and post a message in it it will
become the message_id number 1 in that forum and will be retrievable
with /forums/foo/one-thread?message_id=1
If the whole forum has to be migrated to another instance of ACS 4
it would be trivial to write a redirector that wouldn't need an
id-to-id lookup table.
On a related note, alternative to upgrade scripts would be a convention that every application has to have
an export and import feature (to XML I suppose). That could be used
both for migrations (possibly even to and from other systems) and
upgrades.
