Topic on Extension talk:MobileFrontend

John Du Hart has embarked on a rewrite of MobileFrontend with the primary aim of reducing the extension's Wikimedia-specific dependencies (am I getting that right, John?). It's currently in the Subversion repository as "MobileFrontend2" -- see his recent work.

Patrick Reilly, the current maintainer of MobileFrontend, disagrees with John (and with other MediaWiki developers, including Chad Horohoe) on the need for a rewrite. Some conversation on the topic:

<preilly> ^demon: I just think we should refactor the current implementation not start fresh

<^demon> Well the current version gets deployed rather often.

<^demon> So forking it's not a bad idea.

<preilly> ^demon: I'm not sure I follow?

<JeroenDeDauw> wmf-cenrtic MediaWiki stuff is evil :/

<preilly> JeroenDeDauw: ha ha

<^demon> preilly: Well if it's getting majorly refactored to not be so wmf-centric, we don't want to make the current version unstable.

<^demon> So you can continue iterating & deploying.

<preilly> ^demon: yeah, that makes sense

<^demon> JeroenDeDauw: Agreed. And when possible, it should be configured.

<^demon> *configurable

<preilly> ^demon: yeah, totally

<^demon> Preferably not $wgIsWikimediaHack ;-)

<preilly> ^demon: yeah

Sumana asked:

other than making the extension less Wikimedia-specific, what other improvements are you planning, johnduhart, and what are (as you see it) the flaws in the current implementation?

Patrick agreed:

So we should put together a concrete list of what it's missing in its current form and start to work from there

What would you put in that list? Please comment.

Wiki[pm]edia centric

This is a no-brainer, but specifically:

• Relying on X-Device headers
• Squid cache hacks
• Wikipedia mobile hacks
• Wikimedia templates (sopa)
• Domain handling

CSS is a mess

The current CSS setup is a huge mess. Lots of duplicate rules in device specific files.

Everything in one file

Until very recently 90% the code was in one file.

Login form and templates

These should be implemented as SpecialPages, really

That's just off the top of my head. Along with fixing the above issues, I intend to do the following

• Make use of anonymous squid cache for the main site when the parser cache isn't available (Requested by Tim)
• Take a structured, OOP approach to the extension
• Take steps for automatically configuring WURFL caching so it doesn't kill your wiki when you use the extension
• Add hooks for doing Wikimedia things
• More configuration for the post-parse output mangling
• Instead of doing a mobile front page by manipulating it, use a custom mobile page

That's most of, there'll be a few more tweaks and features.

I'd like to se the horrid output buffer based hack replaced with implementation via a custom skin.

Oh yeah, I forgot. I already am doing it as a skin.

As I understand it, a lot of thought and discussion went into the decision to use the 'output buffer based hack' rather than a custom skin. I'll let others more knowledgeable comment on this, but I believe using the 'hack' is way more performant (which is a major consideration particularly when dealing with mobile devices) as well as offers a lot more flexibility.

• This "hack" causes the extension to completely break when you have a wiki using a custom skin. This is absolutely unacceptable for implementation.
• There is absolutely no way that implementation as an output buffer can be more performant than implementation as a skin.
  • Either way MediaWiki still has to render a skin. So an output buffer only adds to the work, it doesn't reduce it.
  • Our normal skins end up doing work rendering things that only end up getting stripped away by the output buffer. Hence a custom skin would be more performant than an output buffer since it wouldn't be wasting time rendering things uselessly.
  • This "hack" we have actually lets MediaWiki execute the ENTIRE actions of whatever non-mobileaction url it's on when you're on a &mobileaction=, render the entire page, and then discard everything that's done, all the work, all the rendering, and then do more work replacing all of that with new content generated for the mobile action. There is no way that is code that is written to have good performance.

Is this an either/or question? If John is excited about a rewrite, why not have a go at it and then gradually make similar changes to the mainline code to the extent that the other devs agree they make sense? Replacing an extension in bulk is not really less scary than continuously refactoring/deploying an existing one, AFAICT. But I can see the lure of starting with more of a green field, so if that's what John wants to do, then obviously he should do it.

I agree that it would be preferable to rename the rewrite for now to avoid confusion (the current name suggests that it's the versioning of the MobileFrontend extension).

Heads up that most of the Wiki[pm]edia centric bits are already getting taken care of by Arthur. He's removing a lot of the WMF related bits and you can keep track of his development updates by following the bugs in : http://lists.wikimedia.org/pipermail/wikitech-l/2012-February/057936.html . Any ideas/implementation bits are always appreciated.

The CSS bits are getting cleaned up by Jon (just joined) so feel free to message him on IRC to coordinate.

Eager to see your take on the other bits and please do join us and chat about it on IRC. We'd love to hear from you as you go rather then just when you have a release reader.

Shouldn't things like the login form simply (re-)use core code?

I agree with that, though we might need to extend that special page if we need to make modifications to the form itself.

I don't really understand why this warrants a complete rewrite - the issues you outlined will need to be addressed in MobileFrontend anyway as we continue moving forward with it. Ultimately I think it would be more positive to continue refactoring and de-mediawiki-afying MobileFrontend - this is something we can totally do in cooperation together. I'm not against a rewrite per se, but if you really want to do a rewrite, I suggest creating a branch and make your changes there.

Just as a note I've made a reply on the mailing list on this.

Many thanks for working on this, John. We've worked incredibly hard on our independent wiki, and it is very exciting to hear that there may be a mobile frontend in the pipeline that is designed to be more general.