For the record: I'm very interested in the discussion, but have no resources to invest into implementing any kind of decision. My intention with this RFC is to give guidance to other RFCs such as T589 and future discussions.

One way to think about this is to have multiple "content blobs" associated with each revision (currently we only have one blob, identified rev_text_id). Edits may change one or more of them. If a blob isn't changed between revisions, both revisions point to the same blob (we already have this kind of "empty" revision for recording page moves in the page history).

We could associate additional content blobs with revisions using an additional table (or by adding a column to the text table that points "back" to the revision it "belongs" to).

Notes from the IRC meeting (in no particular order):

Daniel: Proposal: multiple blobs per revision, with a role, model, and hash associated. may be a good time to move to timeuuid revision ids. unify content handler with media handler, and file repo with external store / RESTBase.
Daniel: i'm thinking splitting the revision table into two, one for the actual revision (timestamp, user, id) and one for the blobs( blob-id, url, content-model, format, hash, rev-id )

Daniel: UI questions: file description page, upload page, history view, undo/revert, diff pages
Daniel: unify ContentHandler with MediaHandler, and FileRepository with ExternalStore.
Gabriel: This is similar to what RESTBase is doing:

• http://en.wikipedia.org/api/rest_v1/page/ -- listing of content types
• https://en.wikipedia.org/api/rest_v1/page/html/Foobar/ -- listing of history of one content type

<DanielK_WMDE> The XML format would need to change to accomodate multiple content blobs per revision.

Tim: need to have more of a product, UI-focused discussion, with user involvement, mockups, then requirements and then architecture

Daniel: "upload" revissions can be identified using a revision tagging mechanism
<bawolff> The scope on this proposal seems humungous...
<gwicke> I see history more as a timeline of events associated with a logical bit of content; it would be nice to store events by something like a timeuuid and then merge them in a history view. Can even select events to show dynamically, add new types of events later.
<bawolff> Altering description on upload would be a lot easier (in terms of presenting a sane UI) when/if wikidata for images actually happens

<TimStarling> I mean the creating/deleting/moving file revisions, there is a lot of code to do that
<TimStarling> mostly it will just go away
<TimStarling> which is nice

One of the main question is where and how to store the necessary info (blob-id, url, content-model, format, hash, rev-id) to associate multiple revision content data blobs with an entry in the revision table (and edit event).

Tim: encode it in the text table, kind of like what we do for ES
Daniel: have a new revision_blob table split off from the revision table
Gabriel: have a REST service associate blobs with the revision id / uuid.

Moved to "draft" state, because this needs more thought in order to become a concrete proposal. It also needs splitting up into manageable tasks, and some sense of resourcing. Right now this is an idea for a major restructuring, with no concrete need to go forward with it. Although the "media meta data" effort could benefit from this.

@GWicke: it just occurred to me that hash based addressing of blobs would be very nice for this, especially for uploaded files. That would make it very easy to "rename" files without having to do anything on the file system.

@daniel: Indeed. Another benefit is that we don't need to invalidate caches, and stored content using the older version remains consistent without a need to re-render the HTML. See also T66214 and T1210.

<spam>https://gerrit.wikimedia.org/r/179402 aims to make both page and file revisions implement a common interface.</spam>

For the record, this would be pretty easy to to with MCR. Outline:

• define a "media" slot
• define a "media" content model
• the media content model is a (JSON?) data structure that contains the following:
  • the name or path of the file, as used by FileRepo
  • basic meta data, like the file size and mime type
  • more advanced meta data extracted from the file, such as image dimensions, video duration, EXIF data, etc.
• the media content model does not support direct editing. Instead, the editing interface for this model (and slot) is the upload API/UI.
• old dummy revisions that represent uploads could have a new slot added retroactively (NOTE: this changes the revision hash and size!)
• older uploads that don't have a dummy revision associated with them would need to have a new revising injected into the page history.
• The image table would be kept but would no longer serve as a source of truth. It would instead be secondary data for querying files by meta data extracted from their latest revision.
• The oldimage table could go away entirely.