pinging @Jayprakash12345 as somewhat per its documentation: Primarily developed for use in the Indic Language Wikipedias. (In your opinion, what's the expected future of those Shortting-URLs extensions?)

See T107188: Sunset ShortUrl extension in favour of UrlShortener extension - we do need to ensure no matter what that the ShortUrl URL's keep working.

We should probably also have a look at how widely used this actually is in production

In T187045#3966817, @Liuxinyu970226 wrote:

pinging @Jayprakash12345 as somewhat per its documentation: Primarily developed for use in the Indic Language Wikipedias. (In your opinion, what's the expected future of those Shortting-URLs extensions?)

Thanks Sir Pinging me, I will look at this.

In T122708#5088471, @Ladsgroup wrote:

Can we just deprecate ShortUrl in favor of UrlShotener?

Sounds good to me, but what do we do about Cool URIs don't change?

Ideally we'd end up with an outcome where the maintenance cost is near-zero for ShortUrl-compat, which a read-only extension is not (there's lots of churn through unmaintained repos, and lots of hard-to-measure cost during development from isolating issues, log spam, on-going performance issues, etc.)

Some ideas:

• We could add read-only decoding support to the UrlShortener extension, as @Legoktm proposed at T107188.
• We could add a basic "this to that" config option to the UrlShortener extension. E.g. wgUrlShortenerMapFile which could be set to a static array file containing the one-time export of the ShortUrl database. This would mean we only have to maintain the data on disk (e.g. wmf-config) and the redirection. With no database tables or complex PHP code remaining.
• We could export the existing redirects and load into a separate light-weight redirect service, or as Apache rewrite-redirects.

In T187045#5113233, @Krinkle wrote:

In T122708#5088471, @Ladsgroup wrote:

Can we just deprecate ShortUrl in favor of UrlShotener?

Sounds good to me, but what do we do about Cool URIs don't change?

To be clear, any proposal that does not support /s/ style short URLs forever is not acceptable.

Examples of just some of the avoidable/wasted engineering costs that have delayed other goals due to this extension still being in production 5 years later:

• T252917: Drop support for SkinTemplateToolboxEnd in Vector, with suitable replacement
  • rESURb9c683b50ac5: Remove SkinTemplateToolboxEnd hook workaround for legacy skins / https://gerrit.wikimedia.org/r/599753
  • rESURa0a69749b3db: Avoid losing Vector support / https://gerrit.wikimedia.org/r/596759
  • rESURb9c683b50ac5: Remove SkinTemplateToolboxEnd hook workaround for legacy skins/ https://gerrit.wikimedia.org/r/599753
• T160813: Deprecate and remove $wgMemc in MediaWiki Core and bundled extensions
  • rESURe5d0ccc7d749: Convert $wgMemc use to WANObjectCache / https://gerrit.wikimedia.org/r/570781
• ESLint migration T210365 / T220036
  • rESUR706b3ebb001e: build: Use ESLint instead of JSHint and JSONLint / https://gerrit.wikimedia.org/r/566084

@eprodromou I'd like to help push this forward by doing T256993 with your team (in Lego's absence), and thus remove the need for fixing T122708 which is blocking multi-dc.

Concretely that means moral support and code review for a handful of simple patches.

OK, I'll take a look at this. I'm all for reducing complexity in production.

@Krinkle is there a possibility to integrate this with urlshortener or vice versa?

In T187045#6519795, @WDoranWMF wrote:

@Krinkle is there a possibility to integrate this with urlshortener or vice versa?

ICYMI, we have been discussing this on T107188#6275214 onward.

I think the people involved here generally agree that there is no need to provide the ability to produce new short URLs through the old ShortURL extension, nor is there a need for any other user interface. It is no longer being deployed on new wikis. The UrlShortener service is more sustainable and generic long-term.

That would reduce this stewardship request to resourcing the identification and migration of any programmatic usage, outreach with communities and inform them, and to decide and implement how and where to maintain the existing entries in the ShortURL database. Keeping these is required for compatibility with the Internet and existing URLs out there in the wild.

Mapping those keys to a URL is a super simple piece of code. Moving that code to UrlShortener could work, and was proposed in 2015 at T107188. It seems the code would be be unrelated to anything else in that service, and might be "in the way" long-term for other users of that extension. It would also not save us time or resources from what I can see, so taking on the extra work to move it across might not be worth the risk and complexity involved with transferring such contract between two live-deployed extension that are quite different in nature (one is Meta/global, the other is locally bound on select wikis). Kunal elaborated on this at T107188.

For everyone's info, currently no Code-Stewardship-Reviews are taking place as there is no clear path forward and as this is not prioritized work.
(Entirely personal opinion: I also assume lack of decision authority due to WMF not having a CTO currently. However, discussing this is off-topic for this task.)