>>! In T66214#1854415, @GWicke wrote:
> Based on the earlier discussion with @brion (especially T66214#1743938), @BGerstle-WMF, @Tgr and others, I extended the task description with a section describing a possible stable thumb API layout that lets clients dynamically select thumb size and format/quality.

> * `/2fd4e1c67a2d28fced849ee1bb76e7391b93eb12;p=22/500`: 500px thumb of page 22 in a multi-page document.
> * `/2fd4e1c67a2d28fced849ee1bb76e7391b93eb12;t=2m30s﻿/220`: Thumb of a video at 2m30s.
> * `/2fd4e1c67a2d28fced849ee1bb76e7391b93eb12;lang=fr﻿/220`: Thumb of an SVG, rendered to a PNG using French texts.

What if you have a format that supports both animated/pagination and i18n (e.g. an animated SVG or a multi-language PDF)? At that point, why have the size as "/200" instead of ";size=200"?

>>! In T66214#1855231, @Nemo_bis wrote:
>>>! In T66214#1854334, @ori wrote:
>>>>! In T66214#1854329, @Nemo_bis wrote:
>>> How would permalinks work in such a scenario? It's very important for URLs to keep functioning forever, unless the file (or file revision) is deleted.
>> 
>> There would be a mapping of old URLs to content-based URLs, which we'd just keep around forever.
> 
> Yes, but content of an image can vary and so will the hash-based URL. Will every single hash-based URL keep working forever?

It appears that the hash-based URL would always be a permalink to the version of the image at the time. To use a newly-uploaded version of an image, the page would have to be reparsed to reference the hash of the newly-uploaded version. In other words, it would be the equivalent of all page links including "?oldid=12345".

>>! In T66214#1856662, @GWicke wrote:
> @ciencia_al_poder: An issue with offering different ways to constrain image dimensions is cache dilution. Ideally, there should be only a single URL for each thumbnail.

OTOH, that doesn't mean that two different URLs cannot have the same content if the semantic intent of the thumbnail differs. For example, if a video is at 1 frame per second, t=1s and t=1.5s are semantically different but in practice identical.

BTW, I note in your proposed scheme, it's either easily possible to specify `t=2m30s` and `t=150s`, or else it stupidly throws an error for the latter, or else it 301 redirects one to the other and you forgot to mention that.

> The alternative proposed here is to specify a bounding box, limiting both width and height at the same time.

Why do you only want to support //square// bounding boxes? It doesn't seem particularly unlikely that a client has a rectangular bounding box to fill. If you only support square boxes, the client has to separately query the image's dimensions to decide what square bounding box to supply to the thumbnailer.

If you really want one canonical URL and are willing to expend network round-trips to achieve it, the thumbnailer could easily enough redirect `size=200`, `size=200x300`, and `size=266x150` to the canonical `size=200x150` for a 1024×768 image.

> I should also mention the earlier discussion about changing wikitext thumb semantics to use square bounding boxes in T351.

I note that that change was actually tried and then reverted, and T351#1649303 has some analysis proposing more flexibility for that feature.