It doesn't look like Linker could make any use of a FileIdentity type. It seems to basically use File for methods that wouldn't be in such a type, like: exists(), getUrl(), allowInlineDisplay(), isVectorized(), getWidth(), mustRender(), transform().

In T214321#5111160, @Simetrical wrote:

It doesn't look like Linker could make any use of a FileIdentity type. It seems to basically use File for methods that wouldn't be in such a type, like: exists(), getUrl(), allowInlineDisplay(), isVectorized(), getWidth(), mustRender(), transform().

Ok then... where should these live? In FileRepo?

exists() seems reasonable for a FileIdentity class (although remote repos make it more complex, but in some sense that issue exists with Title/PageIdentity as well). getUrl() (and getDescriptionUrl() which is fairly different in terms of systems involved) should live in the Repo as that's the class that deals with the local / shared DB / API split (although caching the results in a value object like FileIdentity does not seem unreasonable). allowInlineDisplay() (aka canRender()), mustRender() and isVectorized() should be in MediaHandler (they mostly are, we just need to deprecate handlerless files). getWidth() should probably be moved to a FileMetadata value object (where FileIdentity represents DB state and FileMetadata represents the file on disk, although in practice metadata is also cached in the DB). transform() probably merits its own service.

FileIdentity should eventually be subsumed into PageIdentity, something worth keeping in mind.