W3C home > Mailing lists > Public > public-bpwg@w3.org > March 2009

RE: New Draft of MWABP uploaded (13th March) / Comments

From: Rotan Hanrahan <rotan.hanrahan@mobileaware.com>
Date: Thu, 19 Mar 2009 10:15:02 -0000
Message-ID: <D5306DC72D165F488F56A9E43F2045D301EA019C@FTO.mobileaware.com>
To: "Eduardo Casais" <casays@yahoo.com>, <public-bpwg@w3.org>
> There also seems to be groups devoted to AJAX (e.g. www.openajax.org); maybe the
> W3C could establish a liaison with them to tap their wisdom.

The W3C MWI already has a relationship with the OpenAjax Alliance and previously held a joint workshop [1] to cover issues of mutual concern. While the current work within the OAA's mobile space is mainly BONDI-related, the historical [2] work is relevant to mobile best practices. As a contributor to the OAA's work, I would also like to draw your attention to a white paper [3] we wrote some time ago, wherein we made a point of referencing the MWI's work amongst others.

---Rotan.

[1] http://www.w3.org/2007/06/mobile-ajax/

[2] http://www.openajax.org/member/wiki/Mobile_TF#Historical

[3] http://www.openajax.org/whitepapers/Introduction%20to%20Mobile%20Ajax%20for%20Developers.php



-----Original Message-----
From: public-bpwg-request@w3.org [mailto:public-bpwg-request@w3.org] On Behalf Of Eduardo Casais
Sent: 19 March 2009 09:57
To: public-bpwg@w3.org
Subject: Re: New Draft of MWABP uploaded (13th March) / Comments


> Does that mean you think we should avoid the word "minify" ? 

Minify is a specific tool, and using minify as a verb is bound to generate some
confusion. Furthermore, it is not clear what exact category of optimization 
is being covered. Lexical simplification comprises not only the elimination of
redundant white space (lexical separators) and of comments, but also the 
reduction of identifiers (what obfuscating tools often do, e.g. "currentAction" 
becomes "zz1"), or the substitution of named and character entities with actual
characters.


> Inlining resources has a performance benefit because it reduces HTTP
> requests. This is definitely a useful technique that we use in a number of
> applications.
>
> Of course, it's not a required technique since the app won't be
> pathologically bad without it.

The formulation in the document and general recommendations for mobile 
applications out there tend towards stating that the best practice is actually
to modularize pages and keep shared resources separate -- inlining thus 
constitutes more an exceptional practice.

However, with the proper context, it can become a best practice: what are the 
characteristics of the applications and target run-time environments that make
inlining more suitable? Is this confirmed by sufficient experience?


> Many of the BPs mentioned are a summary of practical experiences (what we 
> are actually doing internally at Google right now) but this isn't backed up 
> by structured research across a range of platforms to ensure it really 
> qualifies as a best-practice.

Many of the issues dealt with in the document concern fairly recent technology.
Mobile AJAX is really two years old; I do not know whether stable, recommended 
practices have had the time to emerge for that sort of environment.

A first step would be to collect published documentation on the actual practices
and experiences -- the current list of references in the BP document relate more
to traditional browsing. The following might be relevant as a starting point:

	Mikko Pervilš, Jussi Kangasharju
	Department of Computer Science, University of Helsinki
	Performance of Ajax Applications on Mobile Devices
	PERMID & IMUx Joint Workshop
	Pervasive 2008, Sydney
	19th May 2008
	http://www.cs.helsinki.fi/u/pervila/Gradu/Gradu_final.pdf

There also seems to be groups devoted to AJAX (e.g. www.openajax.org); maybe the
W3C could establish a liaison with them to tap their wisdom.

Since I am myself not into AJAX or widgets, I am afraid that I cannot concretely
help much further here.


E.Casais


      
Received on Thursday, 19 March 2009 10:15:46 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:43:00 UTC