Make a plan to rescue use.perl content
Chris Nandor is changing employers, so he won't have access to the machine that hosts use.perl after Friday. He's going to take a database dump with him and turn the site into a static site so the content will still be there for a bit, but eventually it's going to disappear. This might mean that a reboot, power outage, disk failure, or something else might means the current use.perl doesn't come back to life.
The Perl community was very fortunate that Geeknet (and all the other names they went by) allowed Chris to host the site. Use.perl was a test bed for slashcode, so whatever Slashdot did or wanted to do, that's what use.perl did. It was a good thing going for a long time, and many of us owe Chris a lot of beer for use.perl, even if we didn't always like slashcode.
Now it's time to figure out what to do without use.perl and all the links to various posts in there. The main goals are:
- Links to URLs within use.perl continue to serve the same content
- People get to keep their use.perl content if they'd like to do something else with it.
Since its slash, a lot of the stuff is dynamic. Since use.perl basically ran on autopilot, Chris doesn't have the bandwidth. Since use.perl won't be connected to his new employer's tasks, he'll have even less time for it. Maybe there's someone who has the bandwidth for it.
Some possible solutions we talked about:
- Set up slashcode and serves the site dynamically. If hosting is a problem, talk to me. :)
- Set up slashcode and serves the site statically. This might mean a caching layer that stores the computed page for every URL. I'm not sure if that will handle the Ajax stuff properly though.
- Take the database dump and recreate the pages somehow.
- Crawl the entire site and store the results as static pages.
One idea was to inject everything into blogs.perl.org. I don't know how that would work or if the blogs.perl.org team want to do that. It would require a very large URL rewriting component.