Add support for Media Library metadata

[wintercms]

Add support for Media Library metadata

[bennothommo]

I have a couple of ideas for this:

• We could store a lot of "common" metadata in this fashion, for example size and last modified date. I'd also like to see dimensions for images too. If we wanted to be clever, we could even leverage this library to provide support for durations for audio and video files, and resolutions for videos. The upshot of this is that we would no longer need to make any filesystem calls for these values, which should considerably increase performance especially with remote filesystems.
• We could have metadata scanned, retrieved and stored on upload, deletion or move through the normal media manager functions, so the only place we'd fall out of sync is if people make changes to the filesystem directly. To help with this, perhaps an Artisan command could be created to re-scan all metadata.
• Further to the above, we could generate thumbnails for the images at the same point in time, as opposed to having them generated on-the-fly as it does currently.
• Ideally, I would like to store the entire media structure in the database and rely on the database being the single source of truth for media. By using the database, we have full control over the delivery, sorting and filtering of media items, which again should increase performance.
• By having the metadata in the database, extensibility potential would be increased, as mentioned in the OP.

[LukeTowers]

Fair enough re: having the functionality as a plugin. That would probably work better for the company's interests anyways as the feature is a selling point with the existing product.

[LukeTowers]

@bennothommo further thoughts from @jaxwilko and myself regarding the potential for a "version replacement / management system" for individual files.

We could provide the ability to upload new versions of a given file which must match the filetype of the current file, when a file is replaced with a new version; it is replaced in place on disk and the metadata remains the same; the original file is them moved to a .version-history/123/456/789/hash_of_original.ext folder structure at the root level and that path or hash or identifier is stored on the replacing file's metadata regarding the version history along with other information such as when the swap occurred, ability for custom metadata on the version history, user that made the swap, etc.

Any thoughts on the above?

[bennothommo]

It's a cool idea, but I think it might be better as a plugin.

I would assume it would only be able to version track files managed through the manager, and so wouldn't cover cases of people manipulating the files directly or through another plugin. It would also have storage implications and require people to keep on top of cleaning out old versions if they're on space-restricted setups, or perhaps using external hosting where storage = money.