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

Why is it that client-side includes wouldn't be as effective as the
current style of javascript includes that do document.write() calls?

Ex: <div clas='center' src='/content/welcome_body.txt' />
There would be just as many extra network requests as a javascript
based composition approach.

On 1/25/07, sunil vanmullem <sunil.vanmullem@btopenworld.com> wrote:
>
> 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:tetra604@gmail.com]
> 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
>
>
>

Received on Friday, 26 January 2007 22:15:55 UTC