Type (optional)

[bndw]

Type (optional)

Similar to filenames, since files are identified by their hash, media hosts can implement on-the-fly type conversion, if they wish.

I interpreted (and implemented) this as meaning the file type (e.g. extension) is optional, since file names are optional and content type can be detected.

e.g. this request:

GET /70327f48469f541ccafcd82f8204d3b797c8e36790cd431adcaeea048ee/_.jpg

is the same as this request:

GET /70327f48469f541ccafcd82f8204d3b797c8e36790cd431adcaeea048ee

While I see the appeal for a client to offload this work to the media server, I do think it's leaking application-level concerns into the data layer. There are a lot of digital media formats, and on-the-fly transcoding could easily eat into resources that may otherwise be serving static content.

[michaelhall923]

Close, it's more like
GET /70327f48469f541ccafcd82f8204d3b797c8e36790cd431adcaeea048ee/filename.png
will convert
/70327f48469f541ccafcd82f8204d3b797c8e36790cd431adcaeea048ee/_.jpg
into a png, then return the png.

The png is cached at
/70327f48469f541ccafcd82f8204d3b797c8e36790cd431adcaeea048ee/_.png
for say, 30 days to reduce repeats of the same conversion.

The specific architecture I was imagining when I thought this up was a Lambda@Edge function handling conversions, resizing, etc., which I think would solve the performance problem. I agree it shouldn't be done on a standalone server.

One example benefit of this would be a client requesting gifs as animated webps to reduce egress from the media server. I think you mentioned just doing all the conversions on upload, but that could lead to the creation of image variants that are never used, wasting storage space. It also wouldn't involve having a TTL on the variants which is even more wasted storage.

The server would also be able to limit the kind of transcodings it supports.

Of course this is all theory and I don't really have a good idea of how it would play out in reality.