Mobile Plugin

Goals

 * Reduce page weight
 * Reduce number of HTTP calls
 * Group devices
 * Reduce/Remove non-vital information

Grouping
Try to identify, then group devices that support certain features. Intended to be used as a guideline. Create a mini-table for pluginisation.


 * XHTML MP 1.0, 1.1, or 1.2
 * CSS
 * JavaScript
 * JavaScript

Plugin

 * WAP 2.0
 * XHTML MP
 * Break it down based on general grouping


 * cHTML/i-Mode

Dev Tools
I would recommend using Firefox add ons "XHTML/MP" & Modify Headers during development. For final testing nothing has the unpredictable foibles quite like a real handset.

Logic
Pseudo-code

If user on mobile site give them the mobile version

Else If they prefer a mobile mimetype give them the mobile version Else Sniff browser If they are a mobile give them the mobile version

If they want the mobile version and the site has a mobile server Redirect there

Headers
Some relevant headers


 * HTTP_USER_AGENT
 * HTTP_ACCEPT
 * HTTP_ACCEPT_CHARSET
 * HTTP_ACCEPT_ENCODING
 * HTTP_X_OPERAMINI_FEATURES
 * HTTP_X_OPERAMINI_PHONE
 * HTTP_X_OPERAMINI_PHONE_UA
 * HTTP_X_NOKIA_???
 * HTTP_X_WAP_PROFILE
 * HTTP_COOKIE

Resources

 * http://johnex.se/header_accept.php?cmd=list
 * http://emulator.mtld.mobi/emulator.php
 * http://mobiforge.com/designing/story/comparison-xhtml-mobile-profile-and-xhtml-basic
 * http://learnthemobileweb.com/2009/07/mobile-mime-types/
 * http://www.openmobilealliance.org/Technical/wapindex.aspx
 * http://www.quirksmode.org/webkit.html
 * http://developer.android.com/
 * http://www.opera.com/mini/demo

Observations
[Martin Higham's notes]

After a discussion with Sarven I agreed to document the problems I ran into while developing a plugin to generate an xhtml/mp version of a laconica site. My aim is to produce a site that would be xhtml/mp 1.0 & 1.1 compliant and works on low to mid end handsets. Working on top of the range handsets is a bonus and much easier because they have less restrictions.

I decided on a plugin as the best way of creating the variant site because it would allow me to use as much of the existing code base as possible without re-coding or copying critical functional logic. Even though I have run into a number of problems I am still convinced this is the correct way forward. Getting this working well will allow people who want to heavily customise the standard look and feel to do so.

1) Writing the plugin has required that I add additional Events into the laconica code base. These changes are in merge requests 1671

2) Laconica makes extensive use of Forms. Actions such as Leave, Join, Subscribe, Unsubscribe, Block etc. are all submit buttons within there own forms. Many handsets do not support more than one form per page. In order to display group lists, profile lists or notice lists where each item has some of these as an option then these Actions must be GET'able. For most (but not all) the code handler checks that a POST is being processed. I have had to implement my own set of actions duplicating code. This is not something I have been comfortable doing but I didn't want to remove the check from the main code. Does the POST check have to be present? What purpose is served by including it?

3) In order to pass variables between Event processors I have added entries to the $arg array in the Action. This works fine until an error occurs. Error Actions are created without reference to the $arg list. While I have coded round this others will have to discover it the hard way.

Page Size
One of the important elements of supporting low-mid range handsets is keeping the page size small. This is for three reasons, GPRS isnt exactly quick, many phones have a limited amount of memory for page processing and rendering & scrolling speeds on these phones is slow. In order to do this there were several changes I would suggest need addressing in the laconica core.

1) The standard laconica pages makes extensive use of CSS to create the look and feel. While this is fine for the desktop this approach leads to a larger than necessary page size and increass the number and size of downloads. In order to minimise page sizes and to layout the contents for narrow screens I have used simple markup and limited CSS.

2) Pagination By writing a plugin I had hoped to be able to reduce the number of entries per list page and avoid having to manage my own page counts. Unfortunately the pagination code relies on code defined constants (not even config entries). The plugin therefore has to live with the global settings for these values. While investigating pagination I also discovered that there are parts of the caching code that assumes the values for NOTICES_PER_PAGE etc without directly using the constants. I'm not convinced that we need three different values for lists and that they could all be replaced by one configurable value. In order to allow plugins to change the page size to deliver smaller pages to less capable devices Action could have an $itemsperpage variable that is initialised to this value.

3) Pagination event I'd like to add a pagination event so that I can override the markup output but the current pagination function takes a few too many params. Once the previous pagination change is made then the pagination signature could be simplified and just the action passed to a Pagination Event.

4) Relative URLs All the URLs in a laconica page are absolute. I believe this is unnecessary and have implemented a config option to use relative URLs and a BASE tag. My only concern before submitting this change is that there may be a reason I don't know why this is unwise or wont work.

5) Excess white space The output markup has a lot of excess white space. It would be good if laconica could be easily configured to remove this.

6) All output should be gzipped or deflated as appropriate This is easily configurable through Apache but would be worth adding to the documentation