Please read this [1] and this [2]. I think we are on to something here.

[1] http://openacs.org/bboard/q-and-a-fetch-msg.tcl?msg_id=0001ox&topic_id=12&topic=OpenACS%204%2e0%20Design

[2] http://openacs.org/new-file-storage/one-file?file_id=122

It would be good, but I don't see it mentioned that when a page is published, a current version could be written to the filesystem to reduce database lookups. That way revisions aren't read out of the database except when they are changed.

With regard to comments, they could either be retrieved from the database or written to the published file.

With this type of system the pages could actually be rendered into HTML if there were no parts that needed to be queried from the database on each page read.

Comments should be managed by general comments regardless of where the actual paper's stored.

I don't have time to go back and look at the paper at the moment, but when I did read it I had the impression that the edited pages were stored in the filesystem, with auditing provided by CVS.

A "Render to HTML" feature isn't possible because the whole design hinges on the site itself being used as its own editing interface.  So at a minimum the page has to determine whether or not to present the "Edit this page" link.

The final requirement (for performance) says that there needs to be some caching, so that if you request the same page multiple times, we're not sending many identical queries to the database to get the content for that page.  That probably involves writing a scheduled proc that goes through the cache and culls anything that has expired - we don't want all the content requested in the lifetime of the server process hanging around in memory.

With cached content from the db for each page, performance benchmarks should be competitive with any other templated page.  And since the templating system compiles ADPs into bytecode, they perform pretty well.

I see, my misunderstanding, then.  I confused the description of the existing client-driven piece with your plans for the more general piece.

You should probably be using the content repository, no?

We've been encouraging use of the CR in part to keep the differences between RDBMS engines in regard to their handling of large binary and text data buried in one place.
<p>
It also allows storage in the file system rather than in the db, and packages might want to (optionally) expose that choice to system administrators when the package is mounted, etc.
<p>
And we'll be building our sitewide search facility on top of the CR (in PG's case), so clients will get that for free.
<p>
Arguments against:
<ul>
<li>Complexity.  As you've mentioned, the CR comes complete with folders and the like.  Not sure I would've made that decision myself.<p>
<li>Unknown Scalability.  In theory, indexing helps a lot here, i.e. every time you double the number of items the cost of accessing an item goes  up by a factor of log2.  For large binary content the cost of delivering it is high regardless of any overhead in accessing it.  The  LRU cache employed by any reasonable RDBMS should keep localized references in RAM, and if the usage pattern is such that you start getting disk I/O this would be true even if various packages were rolling their own.
<p>So, I don't see any particular reason why the CR won't scale reasonably.
</ul>
So at this point the CR seems to be a win rather than a lose.  As time  goes on we may learn otherwise, but that's the current thinking.