RE: (MOB)HTML - Merge on browser HTML (was SDPML)

Hi Tom, thanks for your measured response. I really appreciate this kind of 

Yes, JavaScript is a concern and needs some further thought to be inclusive 
of the browsers and address accessibility concerns. I'm particularly aware 
Of MOBHTMLs need for a fallback to meet DDA requirements. I'm not keen on
down the route of writing browser extensions as that would have limited the
browser compatibility.

There are certainly solutions that perform the transformation server side 
and there is no reason not to develop MOBHTML to coexist with these in fall 
back situations rather than add extra processing. MOBHTML doesn't 
in itself require any server side scripting.

I didn't want to get drawn into the bandwidth discussion as document
structure in MOBHTML is no different to images. The questions 
about bandwidth question the whole concept of HTML and the web - which 
seems a fruitless exercise.

The JavaScript presented is verbose for proof of concept so that anyone who
to can read and critique the code. For production I'd want to
the JavaScript and strip all comments which should bring the size down to 
15K (for safe obfuscation) or 8K( when compressed).  

Since bandwidth is being debated , with advertising scripting and flash ,
Streaming, animations, PDF, etc the web today typically doesn't have a good 
user experience towards dialup connections. Its a pre existing issue that is

beyond the scope of what MOBHTML should address. EBay for example has a home

page weight of around 160-180K+ with 171 images that need to be loaded to 
display the page. And this is not the heaviest page around.

Thanks for the other tips I'll take some time to address the points 
raised by the various people and add responses here and to 
to the MOBHTML project.

Thanks again and take care


-----Original Message-----
From: Tom Molesworth [] 
Sent: 25 January 2007 10:13
To: sunil vanmullem
Subject: Re: (MOB)HTML - Merge on browser HTML (was SDPML)

Hi Sunil,

First, thank you for sharing the idea with the forum. The example is
certainly interesting, and could have some useful applications. I hope you
understand that any negative points raised are intended to help you to
refine the approach further and to target it appropriately, rather than
being personal attacks.

I've had a look at the example page, and I believe there's one obvious issue
with your proposed approach which will prevent it from becoming the de-facto
standard for web pages as you seem to be hoping:

It relies on Javascript.

There's no graceful fallback, there's no mechanism to show content to people
who are using noscript, restricted IE settings, lynx / w3m / screen readers
/ built-in Nokia web browser. Assuming a fallback can be implemented, this
effectively means the work will have to be duplicated, as with many Ajax
approaches: once for the intended client-side approach, and again for the
server-side fallback. This may not be a dealbreaker but should be taken into
account as a potential disadvantage.

There's a 23 Kb script file that has to be loaded before anything starts to
happen. At dialup speeds, this exceeds the standard 4-second page wait time

You haven't made a convincing case for processing on the client side, and
heavily loaded sites aim to cache data as much as possible - as you should
know. Even the extra memory usage required to load PHP / Java / Perl is
something to be avoided if possible - better to have a web accelerator such
as Squid with ~1Mb footprint than ~64Mb of scripting language that does
nothing but "echo file_get_contents($cache_file)".

You could argue that the static parts of the page can be cached serverside
and clientside, and explain how you'd go about that, rather than making
sweeping claims like "(MOB)HTML threatens app servers". Most approaches
nowadays are not strictly client-side or server-side only, so "app server"
as a term is something of an anachronism.

Numbers are more effective than unsupported assertions: instead of "this in
no way increases bandwidth", give some hard figures based on real code. Your
example page is 37 Kb in total, of which 203 bytes are stylesheet content.
Saving the generated result results in a 5Kb HTML file, so even with the
stylesheet added back in, that's about an order of magnitude *smaller* for
the static page.

Overall, I think there's plenty of potential in your idea for intranets and
other controlled projects, but I don't believe this is suitable for open web

If you can construct an example which shows bandwidth, speed and/or other
advantages over the static approach, perhaps the idea might get a better
reception? I'd also recommend contrasting the pure-client approach against
pure-server or blended options, using a standard framework such as
Template::Toolkit or smarty. What does your approach offer that is not
already available in the alternatives?

Throwing around terms such as "revolutionary" is not going to impress people
unless backed up with facts and details. Your approach may have a lot going
for it, but the presentation is important - a good idea is 1% inspiration,
99% perspiration, as the saying goes.

Finally, putting some words IN CAPITALS is not a breach of email etiquette,
it serves to highlight the point in the same way *this
does* or _this does_, and is a consequence of using plain text.

best regards,


Received on Friday, 26 January 2007 00:14:59 UTC