This is a master ticket for new shiny vector hieroglyphs!
A few links:
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T3007 Cartouche ends do not scale to fit the enclosed hieroglyphs | |||
| Open | None | T33000 WikiHiero's handling of parentheses is broken | |||
| Declined | None | T93787 Switch WikiHiero to Hierator | |||
| Invalid | None | T93808 Zero: prepare for WikiHiero changes | |||
| Invalid | None | T93803 PDF generation: be prepared for WikiHiero changes | |||
| Invalid | None | T93802 Apps: estimate the impact of WikiHiero switch to Hierator | |||
| Invalid | None | T93847 Make Hierator available via RESTBase | |||
| Resolved | • GWicke | T95551 Create a generic cached service module | |||
| Invalid | • csteipp | T98921 WikiHiero/Hierator security review |
We have turned this down multiple times and it seems it keeps coming back, so for the record: to my knowledge, Hierator is a service written in Java and Java (& JVM) is not one of the production platforms we support. Therefore, this cannot go forward.
So far, node.js has been the only one we do support, alongside our PHP monolith (that said, rules can always have exceptions, if a valid case is made). Also note that this is obviously not the rule for the third-party software that we use — usually these are backed by their upstreams, which we often judge by their responsiveness and size, plus usually a team involved to integrate with such software and deploy it.
In my opinion, we cannot simply support nor encourage services written in arbitrary languages, as chosen by individual developers or even teams. There are non-trivial maintenance costs into adding languages and frameworks into our mix, both from an operational and from an organizational point of view (domain expertise, standardization, silos, bus factors etc.), a danger that was even acknowledged in the initial SOA RFC.
Even large and more diverse organizations enforce a choice between 2-3 languages and develop common infrastructure for it. We can certainly discuss adding Java and/or JVM into the mix and that would be a valid conversation, in my opinion. We'd still have to weight this against its initial & running costs, as well as other choices for languages that we may have (others have proposed Go, Rust, Erlang and Haskell in the past). Even though my team has stakes in that conversation, I believe it's a conversation that we should be having both as an organization-with-a-budget, and as a community, as it cuts through multiple different requirements across the board.
In any case, even if Java was accepted, it currently requires an investment in preparing a "Java cluster" among other things, which I'm not sure we should be making just for the benefit of better hieroglyphics. It seems like a big price to pay for a small benefit and does not, in mind, fit with my understanding of WMF's annual plan.
(I'm honestly very sorry to be a negative force — I'm sure you've invested a lot into this and would like to see it move foward.)
I realize this is not very clear, but the RFC decision is not binding for deploying this. The architecture committee is not a foundation body, does not have a budget and does not/cannot control resources. It can advise and provide direction but cannot assign work to people nor allocate resources. Plus, it's the MediaWiki archcom; having something accepted for MediaWiki does not necessarily mean having it accepted for running in Wikimedia's production.
I'm also surprised to hear about Gabriel — he cannot offer such a thing, as what runs and does not run on SCA is not his call. Perhaps you may have misunderstood his offer (which could have been e.g. helping you run it and deploy it on SCA). Nevertheless, I wasn't referring specifically to the hardware resources for this; I do realize it's a small service with little HW requirements.
As to your second point, I think I've sufficiently addressed the difference with third-party Java apps vs. in-house software.
Regarding @faidon's objections in T93787#1384436
If MaxSem contributed Hierator ("a Java servlet that renders Ancient Egyptian texts into images", sounds generic) back to the JSesh project and they adopted it, it seems it would then be "third-party software that we use" backed by its upstream, and thus similar to all the other Java (Elasticsearch, Hadoop, Gerrit, Jenkins, etc.) that WMF operates. Would the blocker then be identifying "the team involved to integrate with such software and deploy it"?
I'm not arguing, just seeking clarification. (Plus, I was confused about a project named JSesh that isn't JavaScript :-/ )
How will the RFC be put into effect then? Hieroglyphics are being neglected and people may lose interest in them.
The whole Hierator thingie was rejected by the ops team. I'm not working on it anymore.