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. Many of these are in merge requests 1185 and I will be submitting the rest shortly. I don't think there's anything contentious here. 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) Unless I want to maintain complex feature set/handset mappings I need to assume no javascript on the handset. For most of the time this is inconvenient (e.g. no character count) but with Reply it is slightly more. At the moment it is Javascript that inserts the thread id and replyto nickname into the new notice form. A small code change in the main codebase is required to add the the inreplyto parameter to the URL. I'd like to submit this, but don't know if there is a reason I shouldn't 4) 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. 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. This is generally OK but times when tags I don't want are output before events (e.g. StartPrimaryNav where a dl, dt, dd and ul are output before the event). Either PreAmble/PostAmble events could be added or the markup could be moved to after the event. 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) Token In my implementation of the Get versions of icons I have added the token to the param list to maintain CSRF defense. The current token is huge and on a list page can contribute significantly to total page size. Should I abandon tokens for this purpose or perhaps uses a truncated version? 5) 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. 6) 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. 7) All output should be gzipped or deflated as appropriate This is easily configurable through Apache but would be worth adding to the documentation Martin
_______________________________________________ Laconica-dev mailing list [email protected] http://mail.laconi.ca/mailman/listinfo/laconica-dev
