"Additionally the 1:n relationship between cr_items and cr_revisions
has to be amended to support a n:m relationship (one revision can belong to
multiple items)."
How do you propose to do this without breaking everything that already exists?
Simpler would be to allow multiple revisions to point to the same file (if LOBs are stored in the file system). The PG BLOB hack already allows for multiple columns to point to the same BLOB ... not sure whether Oracle's LOBs support this.
I still question whether this functionality is useful enough for enough people for us to implement it as part of our core functionality. File systems the world over for a large variety of operating systems manage without it, and indeed, if this were of high importance I would think the file system would be the place to implement it. If the application layer, not filesystem, is the "right" place to implement it because it is of limited use, then the same argument applies to our core "file system" (content repository) service, doesn't it???
An additional point:
"The calculation shall happen while uploading and should be possible to be
done on only part of the file. This shall prevent a 5MB file to be uploaded
by the user just to realize the whole bandwidth was not necessary as the
file was already there."
Wouldn't this require support for partial file upload from AOLserver? AFAIK when you push "submit" on a file upload form, AOLserver slurps the entire file onto your server before OpenACS can intervene.
