Page MenuHomePhabricator

[Task] Investigation: Remove wbentity blob on mobile
Closed, ResolvedPublic


From T119078#1965648: Remove the wbEntity blob on mobile, because it does not allow editing at all.

Related: T125899: Spike: Should the mobile site vary the ParserOutput cache?

Event Timeline

Tobi_WMDE_SW raised the priority of this task from to Medium.
Tobi_WMDE_SW updated the task description. (Show Details)

Open questions: are parser cache and web cache split on mobile vs. desktop?

Tobi_WMDE_SW renamed this task from [Task] Remove wbentity blob on mobile to [Task] Investigation: Remove wbentity blob on mobile.Feb 2 2016, 2:16 PM
Tobi_WMDE_SW set Security to None.

@daniel I think you said you wanted to write an email to relevant folks about that?

oh, right. ok, did that now. I put wikidata-tech in cc.

daniel added a subscriber: Jdlrobson.

@Jdlrobson replied:

Hah! Very timely.

I'm pondering the same question. We are keen to lazy load content (references and images) in the mobile web experience for mediawiki.

So it looks like I was right: mobile uses a separate web cache, but shares a parser cache. That makes it tricky to serve a different representation of the content for mobile. See T125899: Spike: Should the mobile site vary the ParserOutput cache?

@daniel (not to blame anyone) but recently mobile was corrupting the parser cache (T124356) so it's definitely shared parser cache for now.

not sure about splitting it in the future, but perhaps a possibility?

Quick summary of the investigation:

  • mobile uses separate web cache keys, so no problem there.
  • mobile shares the parser cache with the desktop version
  • if we remove the blob from the cached ParserOutput for mobile, we need to split the parser cache. That may be doable, but isn't great, see T125899.
  • it would be nicer to never put the serialized entity into the ParserCache, but add it on the fly when serving the editable (desktop) interface.

@daniel I think the blob could be added in OutputPage, since it's a JS variable. (we already add other, user-specific JS vars there like wbUserCanEdit and wbUserIsBlocked)

but yes we should have some caching for the blob.

I suggest to put any data we want to optionally serve into the ParserOutput's extension data slots. That way, the info is cached, but won't get served to the client, unless we explicitly splice it in via an OutputPage hook. We can do the splicing as appropriate for the specific type of client.

We have to be careful though that any distinction we make when constructing the OutputPage from the ParserOutput has to be consistent with how the web cache is split.