>>! In T66214#2772934, @Tgr wrote:
> Projects which can get away with being Wikimedia-only (such as the mobile apps) could just use the Thumbor API directly, though. That seems like a much less ambitious project than replacing the MediaWiki thumb API.

That depends on what you want the caching and storage strategy to be. If you want to achieve reusing the same Varnish entries, as suggested in the current version of the task description, the URL translation that has to be done in Varnish becomes more complex. Furthermore, given that in the current state of affairs Thumbor is responsible for storing the resulting thumbnails in Swift, it needs Swift sharding awareness.

Currently I've written an URL adapter for Thumbor for it to take care of that translation, this way Thumbor can take Wikimedia URLs directly, like so:

http://127.0.0.1:8888/images/wikipedia/commons/thumb/a/a6/Chamarel_Falls_Mauritius_2.JPG/qlow-300px-Chamarel_Falls_Mauritius_2.JPG

Now, you could achieve the same image by requesting this, going through the standard Thumbor URL handler:

http://127.0.0.1:8888/unsafe/300x/filters:quality(10):conditional_sharpen(0.0,0.8,1.0,0.0,0.85):format(jpg)/upload.wikimedia.org/wikipedia/commons/a/a6/Chamarel_Falls_Mauritius_2.JPG

But that wouldn't save the end result in Swift. Granted, we could reconstruct the Wikimedia URL from the Thumbor URL, or parse the same information from it, and make it save the output to Swift. But I felt that it was better not to mess with default Thumbor behavior because people have expressed the need to want to use Thumbor without saving the results in Swift.

I would like a new service to replace what rewrite.py currently does and would be responsible for coordinating the various services involved in thumbnailing (currently Thumbor, Swift and the Mediawiki API). It would basically combine all that URL parsing/translating logic + swift sharding currently found in rewrite.py and thumbor, keeping Thumbor and Swift dumb. Thumbor would only care about returning a thumbnail, not where it gets stored. And Swift would only care about writing and reading content and Swift locations, without the need to rewrite URLs and proxy requests itself. This doesn't solve the Varnish side of things, though. If you want Varnish to support two URL schemes pointing to the same Varnish entry, there's no escaping writing some VCL or a vmod.

Now, regarding the current plan of this task. It seems to me like the goal is to simplify what's currently available, with no plan to add new features, since the "limited choice" property ensure that a new URL scheme would be as efficient cache-wise as the old one. The deployment plan, if the Varnish side of things can be done, looks ok. But what I dislike about this plan is that it's not a migration plan. You're basically solving your own problem and leaving a considerable technical debt project on mediawiki's doorstep for someone to be determined to care about. I.e. it will be some future person's job to migrate mediawiki, its extensions, etc. to use the new URL scheme. Creating that much technical debt without an owner shouldn't be allowed. I would support this plan if it was a full migration one and the project included upgrading mediawiki's built-in URL scheme to a cleaner, more extensible one.

Furthermore, the value of a migration aiming for 1-to-1 mapping between two URL schemes is questionable. It's a lot of work, potentially a dual URL scheme for the foreseeable future due to the lack of plan to get rid of the old one, a new service to support. What do we get out of it that's new? A few minutes of developer time saved figuring out the existing URL scheme? These URLs will be consumed by programs that don't care about their beauty.

Re-reading the older parts of the task description mentioning imageinfo, you don't need to call imageinfo to generate a thumbnail URL. It's just a convenience to have it made for you and to have the fallback to the original when a width that's too large is requested. The newly proposed URL scheme doesn't solve that. You still can't know the dimensions of the original in advance if you only have the filename and you are susceptible to requesting a size that can't be rendered. Just like you would be if you constructed a thumbnail URL manually without using imageinfo.