[go: up one dir, main page]

Page MenuHomePhabricator

Consider allowing local Data pages to be used as a fallback if fetching from the remote fails
Open, Needs TriagePublic

Description

T371924: Allow chart definitions and tabular data to be loaded from Commons enabled us to configure a wiki such that Data:.chart pages or Data:.tab pages (or both) are loaded from a remote wiki. In production, we intend to use this to load these pages from Commons.

However, we don't currently have fallback functionality: if the wiki is configured to load .chart pages from Commons, and the requested .chart page doesn't exist on Commons, we'll display an error, even if a .chart page by that name does exist on the local wiki. This is in contrast to how images work, where both remote images from Commons and local images on the wiki itself can be used (and if both exist, the local image takes precedence).

We should consider whether we want to implement that behavior for charts, or whether we want to stick with the current behavior (where each wiki can either load .chart/.tab files locally, or remotely, but not both).

Product questions to consider:

  • Does it make sense to even allow local .chart/.tab page to be created on non-Commons wikis?
  • If both a local .chart/.tab page and one on Commons exist with the same name, which one should be used?

Engineering questions to consider:

  • How would we implement this behavior? Would we have to change things in the JsonConfig extension to make this work?
  • If a page refers to a remote .chart/.tab page, but then a local page is created by that same name, would we re-render that page to reflect the fact that it now points to the local page instead of the remote page? How would we find out that that needs to happen?

Event Timeline

My opinion is that it probably doesn't make sense to allow local chart/tab pages to be created. I think it would be confusing, would discourage sharing them on Commons (which is something we want to encourage, not discourage), and I think it wouldn't be worth the engineering effort (which is likely significant, because I don't think the JsonConfig extension wants to be set up this way).

My opinion is that it probably doesn't make sense to allow local chart/tab pages to be created. I think it would be confusing, would discourage sharing them on Commons (which is something we want to encourage, not discourage), and I think it wouldn't be worth the engineering effort (which is likely significant, because I don't think the JsonConfig extension wants to be set up this way).

(1) Many wiki has some internal workflow (such as number of open unblocks), which local wiki may hopes to be managed locally. A more extreme case is private wikis - which may contain charts with NDA-protected data.
(2) I suggest we should use how currently we handle files (local ones take priority). Alternatively we can prefix all Commons data file with some prefix such as shared:test.tab so each chart and tab title will always refers to one of local or shared tab/chart page.

It is orders of magnitude harder to move graphs from the original wiki to commons, than to have them in the data namespace on the original wiki. This is especially true if the move is done with a bot. This mostly effects the datapoints, the design is often shared between hundreds or thousands of graphs.

One of future solution is T91162: RFC: Shadow namespaces, but it is a long way to go.