This would allow storing arbitrary binary objects and make it easier to handle them in a consisntent way. For example, file-storage could be fixed.

We already have acs-subsite/www/file.vuh which will allow downloading an file stored in the content repository consistently.

This will allow us to deal with files uploaded with the oacs-attach widget for xinha or tinymce to be correctly handled and indexed for search etc.

The problem is if you enable search of generic content_revisions you could get any object which may or may not be interesting or searchable.

From years of experience it has occured to me that only subtypes of content revision should actually implement the search callbacks (or service contracts in legacy installs). There should be a way to create a non-searchable content_revision.

Does anyone care to discuss this?

I wasn't sure why you need a new type but I understand it's basically to enable search only on "searchable" content.

Thinking aloud:

So the diference between generic content and the one you need is its visibility. But really you're talking about "generic content".

I wonder if creating a new type is the right thing to do to solve the "searchable" thing. A type should remain a type and not a way to store a property of the object (searchable).

The idea here is to handle uploaded files consistently throughout the site.

This is the most important piece of information

"This would allow storing arbitrary binary objects and make it easier to handle them in a consisntent way. For example, file-storage could be fixed. We already have acs-subsite/www/file.vuh which will allow downloading an file stored in the content repository consistently.

This will allow us to deal with files uploaded with the oacs-attach widget for xinha or tinymce to be correctly handled and indexed for search etc."

So in this case the search isn't that I want to exclude generic content revisions so much, but that I want to be able to treat all uploaded files similarly. I want to be able to search ONLY uploaded files. For example, in an improved file attachment feature, we could search all the files a user has uploaded in addition to allowing them to browse folders. To do this we need to restrict the search by content_type. Having a searchability flag does not help here.

On HUB at MGH we are using the saved list template feature quite a bit. This feature uses generic content_revision to save the state of the filters.

This appears to be the ONLY place that uses generic content reviisions that I can find.

So, if I fix this limited case to use a specific content type, that solves the problem of presenting a list of generic revisions. Preseumably the remaining generic revisions will be uploaded files.

Otherwise I don't have a better idea, it seems like this proposal is not approved of, but I don't see a clear way forward to deal with files.

Note of course, this would ideally replace file storage, in which case we would replace file_storage_object content type, which has no specific attributes, except that they _are_ files created by file storage (except images which get image content_type), so the only real way to distinguish them is which folder they are in.

Maybe looking at folders is the best way? Limiting to results to specific folders? See the wiki proposal which does use folders to store uploaded files. Of course this leaves a question of identifying the correct folder, which seems at least, a smaller problem, since the number of root folders will be less than the number of files in the folders.

Content -> Text -> Uploaded|Generated
Content -> Binary -> ...

or something along those lines. Haven't given the tree any thought but clearly you could imply quite a lot by selecting a category from a well-organized tree. The subsite could use this information to act appropriately on new content.