Hi Tom, thanks for your measured response. I really appreciate this kind of input.
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 going down the route of writing browser extensions as that would have limited the cross 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 cares to can read and critique the code. For production I'd want to obfuscate/compress 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 , video 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 Sunil -----Original Message----- From: Tom Molesworth [mailto:[EMAIL PROTECTED] Sent: 25 January 2007 10:13 To: sunil vanmullem Cc: www-talk@w3.org 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 - http://www.akamai.com/html/about/press/releases/2006/press_110606.html 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 exposure. 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? http://www.jemplate.net/ http://trimpath.com/project/wiki/JavaScriptTemplates http://sxoop.wordpress.com/2006/08/30/javascript-templating-with-sxooptempla te/ 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, Tom
