The first feature I'd love to see added to scoop is straightforward enough: support for OAI-PMH. This really shouldn't even be that hard: we start with one of the perl tools for building interfaces listed on the OAI page. Map sections from /u/l/i to OAI sections. Make some choices about granularity of time periods. Reuse the RSS bits that use DC already to generate the metadata. And badaboom, badabing, scoop speaks OAI! Has anybody tried this yet? It would be a great two-hour project for someone with some perl, scoop, and OAI proficiency, and I bet the scoop maintainers would consider adding it in before 1.0 (especially considering there isn't yet a timeline or roadmap for 1.0).
I see two main benefits for OAI support in scoop. First, it would sort-of elevate a site like /u/l/i to the status of the status of the many e-print servers out there. These days if you want your content to flow around into new-generation indexes and such, OAI's the best way to get it there. Second, while RSS has been very successful tying weblogs together, the strength of the OAI protocol is still missing from mainstream blog integration efforts, RSS integration included. Adding OAI support to scoop would help promote OAI within the blogging community, and would perhaps help make rectify the perception of ephemeralness (especially as seen by scholars) of the many high quality weblogs out there. Not to mention providing a practical means to get a leg up on preserving them over the long term.
The second feature I'd like to add to scoop is a little more obtuse: a print version.
Yeah, okay, pick your jaws back up, you heard correctly. :) I'd love to see a print version of a scoop site. A group at my institution recently spent a year analyzing issues related to web journal archiving, and although we didn't come to any grand new conclusions (other than that "it's hard!") I couldn't help coming back around over and over to the "if you can just print it all out, why don't you?" solution.
Let me try to walk through it from a technical approach: we use something like FOP or axkit and map stories and sections to some print frequency (monthly?), then generate an xml dump of the site's new content during that period. We write some nifty XSL stylesheets to make a cover page, and ToC, and author index, etc., and every month we generate a new print issue of /usr/lib/info!
Is this starting to make any sense?
The cool prospect I can't help salivating over is that since the tools are efficient enough, we could allow individual users to specify their own frequencies, comment type and rating thresholds, and sections, and then generate their own pdfs through some ad hoc server process. Wouldn't that be great?
Okay, so it's a little silly, and it presupposes that this is going to be a successful site. But it can't hurt to dream a little. If nothing else, we'd be pushing the web/print blending envelope pretty hard, and it would be a fun way to build up XSL chops.