Recently, more bugs with dynamic sections resurfaced. Here is the
current situation:

* We mangle HTML in beta and alpha, removing all sections but 0 and
  relying on JS to provide the rest.
* The former approach does not work with non-JS user-agents and when
  JS is disabled or simply didn't get loaded (we're on mobile after
  all).
* Pure-HTML fallback with links to separate sections doesn't sound
promising due to performance concerns.
** Because there's no sane way to purge the cached sections.
** And because we'll have to either spend more CPU time on every
   mobile section view than on whole desktop view OR cache aggressively
   and compete with parser cache, thus reducing overall cluster
   performance anyway.

This is very broken and because there's no chance that it will be
moved into core in its present state it fails the beta inclusion
criteria (for final testing of features that will soon be exposed to
everyone).

Therefore, I propose to do away with it and if we still want dynamic
section views in the foreseeable future, use plan B that I proposed
before:
* Leave HTML as it is.
* Load subsequent pages dynamically.
** While the first page load may seem much heavier than just section 0
   + section headings, due to the amount of JS we serve, the
   percentage of bandwidth saved by stripping sections is reasonably
   low except for a few really huge pages.
** Subsequent page views work as before.
** All fallbacks work magically.
** Implementation is straightforward and requires much less work to
   make it production-quality.
** No performance bells ringing.


-- 
Best regards,
  Max Semenik ([[User:MaxSem]])


_______________________________________________
Mobile-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Reply via email to