@Esanders thoughts?

I'd like to see the concept of section editing be replaced by "DOM subtree editing", since sections are just one DOM tag we could subtree.

Then there's the broader question of how character indexing should be done: JS (UCS-2), unicode codepoint, vs PHP (UTF-8 byte offsets). We were using JS offsets originally without thinking too hard about it, but we should probably think a bit.

Is this a dupe of T211461: Section edit endpoints in RESTBase: Still needed? ?

In T216636#5085344, @ssastry wrote:

Is this a dupe of T211461: Section edit endpoints in RESTBase: Still needed? ?

Hehe, indeed, it seems so, but @Esanders wasn't clear on that ticket. @Esanders would VisualEditor be ok without section editing support from RESTBase / Parsoid?

I read both tickets closely now and here are my thoughts.

I think there will be some form of subtree ( not just section ) editing support in Parsoid (and a corresponding endpoint) in RESTBase which Ed affirms in T211461: Section edit endpoints in RESTBase: Still needed?. I anticipate two endpoints: one to get, and another to save.

The question more is about what those endpoints would look like. Will the GET endpoint rely on HTML offsets that Parsoid provides and RESTBase doing a substring operation to fetch the subtree? Or will RB go back to Parsoid to fetch the relevent subtree AND postprocess it to ensure there is adequate references support. If the latter, then the HTML offsets are not relevant, which is what this ticket is asking about.

So, the only confirmation we need from Ed is that fast substring operations to fetch a subtree from RESTBase storage is not going to be useful since it would still need postprocessing for references (and any other global state because of other such extensions).

No blockers from Readers Engineering to deprecating/removing this.

Seems like we have a consensus on the backend. @Esanders could you please confirm that VE will not need this in future?

In T211461#4810219, @Esanders wrote:

We had a nearly-working implementation, however it was blocked by references. With references support being moved into Parsoid we would be able to bring this back. This feature would make saving a lot quicker on long articles. It is unlikely to be a priority in the next few quarters.

Basically this is a nice-to-have but we are unlikely to come back to it any time soon. Ideally this will be possible in the future, but doesn't need to be kept available it the current form.

Thank you for the info, @Esanders . I propose we deprecate and remove it in that case. @Pchelolo @ssastry thoughts?

+1 to "DOM subtree editing" from me as well.

Mentioned in SAL (#wikimedia-operations) [2019-04-25T19:25:35Z] <mobrovac@deploy1001> Started deploy [restbase/deploy@7187e0c]: Bump HTML content version in docs, remove Parsoid stash fall-back and start logging all sections requests - T221432 T215956 T216636

Mentioned in SAL (#wikimedia-operations) [2019-04-25T19:45:39Z] <mobrovac@deploy1001> Finished deploy [restbase/deploy@7187e0c]: Bump HTML content version in docs, remove Parsoid stash fall-back and start logging all sections requests - T221432 T215956 T216636 (duration: 20m 04s)

After adding the warn logging, there were 15 requests recorded for getSections all in a span of a few minutes, from a browser, so I believe that was someone playing with it from the docs UI. I think we can safely remove the endpoints and the code.

Indeed, the calls were for /en.wikipedia.org/v1/page/html/List_of_Nintendo_Switch_games_(M-Z)?sections=header&stash=false (and footer respectively), so they are not legitimate (as in, there are no such sections in the Parsoid HTML). I propose to leave the logging on for the rest of the week. If we see the same picture Friday we can safely remove it.

Mentioned in SAL (#wikimedia-operations) [2019-05-07T07:26:38Z] <mobrovac@deploy1001> Started deploy [restbase/deploy@d91ee4c]: Remove section functionality from the REST API - T216636

Mentioned in SAL (#wikimedia-operations) [2019-05-07T07:51:24Z] <mobrovac@deploy1001> Finished deploy [restbase/deploy@d91ee4c]: Remove section functionality from the REST API - T216636 (duration: 24m 46s)