Re: (MOB)HTML - Merge on browser HTML (was SDPML)
brings efficiency improvements to the server side. I am not clear how it will improve the server side efficiency. I am more interested in this part as a web server admin. Thanks Hakan http://dominor.com
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 [EMAIL PROTECTED] 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:[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
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-sxooptemplate/ 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
RE: (MOB)HTML - Merge on browser HTML (was SDPML)
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
Re: (MOB)HTML - Merge on browser HTML (was SDPML)
rendering part has always been the job of the client, well designed website(application) already caches completed pages or parts of them on the server, so there is no processing on the server with each request, just HTML files saved on the hard drive. what you are doing is rather than design efficient website(application) on the server, you add overhead both to the client and bandwidth, in addition you complicate the client requirements and in some cases make the website invisible(googlebot and other bots will never process javascript, it's just not feasible) can you give an example of a simple web server? any chance you could also give an example of a more complicated one that might be required if someone is not using your idea so after all this to make sure we can use a simple server, you now propose to expand the server side for the purpose of satisfying the googlebot? won't that change the requirement from the simple server to the more complicated one? why not just use current standards and focus on developing a better website(application) that can better cache and manage content so it is more efficient handling requests without adding to complexity of the client code, amount of bandwidth and making the content invisible to googlebot and other such desirable automated visitors. I'm not a cynic, just always looking for better more efficient ways of doing things, this definitely is not. -ark - Original Message - From: sunil vanmullem [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: www-talk@w3.org Sent: Tuesday, January 23, 2007 4:02 PM Subject: RE: (MOB)HTML - Merge on browser HTML (was SDPML) Hi Hannes, thanks for your message. The application would still continue to do what it does, in sending only the content appropriate to the user and their context Within the application. That doesn't change. What (MOB)HTML says is 'hey application server, you don't need to know how the data is displayed, just give me the content, give me a link to a template and I'll put them together at the client side. so *the application server doesn't have to do as much as it did before as the rendering part of the web page production pipeline is moved to the client and this brings efficiencies. * As the template is not going to change, this can be served by a just a simple web server * and now that the application server and how the page looks are separated, The two can changed almost independently of each other. Agreed about Google, that's why I'm writing a server side rendering piece which brings the rendering back to the app server for browsers that don't support This new way of doing things and present regular HTML to them. In time, with adoption of MOBHTML, I'd like to think that search engines would be able to Do the rendering at their end. I'd certainly be happy to write a plug-in for google. Thanks for the constructive comments, I was beginning to think this forum was dead, or worse full of cynics. Sunil Vanmullem www.paglis.co.uk -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hannes Ledl / LEDL PARTNER Sent: 22 January 2007 22:38 To: www-talk@w3.org Subject: RE: (MOB)HTML - Merge on browser HTML (was SDPML) Hi sunil For my understanding - you / your application serves pages an you let the client decide what to do - what to show. But why you leave the decision to the end of the line (the client / the browser) what about the way keep this decision at lowest level. The server - an keep the content submitted with a lowest as possible logic. Let the server handle the content for the appropriate browser and only serve content really needed. How do you think about SEO? I think, the 'googles' will not handle your content as you want to have. Regards from Austria - Velden Hannes Ledl http://www.ledl.at
Re: (MOB)HTML - Merge on browser HTML (was SDPML)
you are not really answering my points, and if in the future you replace php with something else, won't that have to maintain the content somewhere, match request to the maintained content and then respond, isn't that a lot more complicated than a simple .HTML file sent in response to request? that's what creates the load on the server, I can guarantee you right now, this idea isn't going anywhere simply because it makes no sense whatsoever it does not threaten the server... it uses and it can't exist without it, and that's the problem I guess that about covers it ty - Original Message - From: sunil vanmullem [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: www-talk@w3.org Sent: Wednesday, January 24, 2007 8:41 PM Subject: RE: (MOB)HTML - Merge on browser HTML (was SDPML) Again can I emphasise this is a proof of concept and not a finished project - its an invitation to make this better. Breaking email etiquette ark, by shouting , for example, does not make for a rational discussion. Would we be having this discussion say if images were embedded inline into web pages and someone wanted to separate images from the HTML document content? This is the same. MOBHTML just wants to treat document structure as an image, a static piece of content. Sure I've used Ajax to prove the concept that this can be done, and people don't like it because its not XSLT. Fine, that's not the point - this proof of concept is just that, and is not the final end of the story, I've proved that in a cross browser manner this can be done. I've also shown that a simple data substitution approach can have the same result as a complex transformation. This works on Firefox, Mozilla, Netscape, Internet Explorer, Safari, Opera and Minimo.. How's that for compatibility - on windows, Mac and Linux and my ipaq. Right now it uses PHP, in the future it doesn't have to. And that's why I've come to this forum to help shape this as an proposed open standard. So, just playing devils advocate - do people agree that a page containing lots of images is poor web design and increases bandwidth because the browser makes multiple separate requests for images? And what about pages that use AJAX to fetch data from the server is that bad web design? Do people agree that well written web applications cache all html to disk, even when the content is highly customised to the person logged in, or contain data being pulled in real time from a database? To answer that, I've been around the web and for a long time coding web applications that hundreds of millions of people use daily. Today I am an architect for one of the biggest and busiest mobile portals in the UK. I can see that (MOB)HTML threatens app servers, because its saying that the browser is intelligent enough to be given complete control of the interface and wants to treat app servers as sources of data - like an B2B application might make a soap request. Sunil -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: 24 January 2007 01:20 To: sunil vanmullem Cc: www-talk@w3.org Subject: Re: (MOB)HTML - Merge on browser HTML (was SDPML) absolutely it does increase the load on the server, you need a php script to serve the pieces of the page IN SEPERATE REQUESTS, that makes no sense whatsoever, increases both bandwith and server load tremendously, a well designed website(application) would simply write the complete page to the hard drive on the server as HTML file, each request would then not incur any server side processing other than simply serve the requested page, I'd say that's probably 99% more load on the server than would be incurred with a well designed cached content on the server. -ark This in no way increases bandwidth, or increases load on the server Quite the opposite. Sunil -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: 23 January 2007 23:59 To: sunil vanmullem; [EMAIL PROTECTED] Cc: www-talk@w3.org Subject: Re: (MOB)HTML - Merge on browser HTML (was SDPML) rendering part has always been the job of the client, well designed website(application) already caches completed pages or parts of them on the server, so there is no processing on the server with each request, just HTML files saved on the hard drive. what you are doing is rather than design efficient website(application) on the server, you add overhead both to the client and bandwidth, in addition you complicate the client requirements and in some cases make the website invisible(googlebot and other bots will never process javascript, it's just not feasible) can you give an example of a simple web server? any chance you could also give an example of a more complicated one that might be required if someone is not using your idea so after all this to make sure we can use a simple server, you now propose to expand the server side for the purpose of satisfying the googlebot? won't that change the requirement from the simple server
RE: (MOB)HTML - Merge on browser HTML (was SDPML)
Hi Hannes, thanks for your message. The application would still continue to do what it does, in sending only the content appropriate to the user and their context Within the application. That doesn't change. What (MOB)HTML says is 'hey application server, you don't need to know how the data is displayed, just give me the content, give me a link to a template and I'll put them together at the client side. so *the application server doesn't have to do as much as it did before as the rendering part of the web page production pipeline is moved to the client and this brings efficiencies. * As the template is not going to change, this can be served by a just a simple web server * and now that the application server and how the page looks are separated, The two can changed almost independently of each other. Agreed about Google, that's why I'm writing a server side rendering piece which brings the rendering back to the app server for browsers that don't support This new way of doing things and present regular HTML to them. In time, with adoption of MOBHTML, I'd like to think that search engines would be able to Do the rendering at their end. I'd certainly be happy to write a plug-in for google. Thanks for the constructive comments, I was beginning to think this forum was dead, or worse full of cynics. Sunil Vanmullem www.paglis.co.uk -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hannes Ledl / LEDL PARTNER Sent: 22 January 2007 22:38 To: www-talk@w3.org Subject: RE: (MOB)HTML - Merge on browser HTML (was SDPML) Hi sunil For my understanding - you / your application serves pages an you let the client decide what to do - what to show. But why you leave the decision to the end of the line (the client / the browser) what about the way keep this decision at lowest level. The server - an keep the content submitted with a lowest as possible logic. Let the server handle the content for the appropriate browser and only serve content really needed. How do you think about SEO? I think, the 'googles' will not handle your content as you want to have. Regards from Austria - Velden Hannes Ledl http://www.ledl.at
RE: (MOB)HTML - Merge on browser HTML (was SDPML)
This in no way increases bandwidth, or increases load on the server Quite the opposite. Sunil -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: 23 January 2007 23:59 To: sunil vanmullem; [EMAIL PROTECTED] Cc: www-talk@w3.org Subject: Re: (MOB)HTML - Merge on browser HTML (was SDPML) rendering part has always been the job of the client, well designed website(application) already caches completed pages or parts of them on the server, so there is no processing on the server with each request, just HTML files saved on the hard drive. what you are doing is rather than design efficient website(application) on the server, you add overhead both to the client and bandwidth, in addition you complicate the client requirements and in some cases make the website invisible(googlebot and other bots will never process javascript, it's just not feasible) can you give an example of a simple web server? any chance you could also give an example of a more complicated one that might be required if someone is not using your idea so after all this to make sure we can use a simple server, you now propose to expand the server side for the purpose of satisfying the googlebot? won't that change the requirement from the simple server to the more complicated one? why not just use current standards and focus on developing a better website(application) that can better cache and manage content so it is more efficient handling requests without adding to complexity of the client code, amount of bandwidth and making the content invisible to googlebot and other such desirable automated visitors. I'm not a cynic, just always looking for better more efficient ways of doing things, this definitely is not. -ark - Original Message - From: sunil vanmullem [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: www-talk@w3.org Sent: Tuesday, January 23, 2007 4:02 PM Subject: RE: (MOB)HTML - Merge on browser HTML (was SDPML) Hi Hannes, thanks for your message. The application would still continue to do what it does, in sending only the content appropriate to the user and their context Within the application. That doesn't change. What (MOB)HTML says is 'hey application server, you don't need to know how the data is displayed, just give me the content, give me a link to a template and I'll put them together at the client side. so *the application server doesn't have to do as much as it did before as the rendering part of the web page production pipeline is moved to the client and this brings efficiencies. * As the template is not going to change, this can be served by a just a simple web server * and now that the application server and how the page looks are separated, The two can changed almost independently of each other. Agreed about Google, that's why I'm writing a server side rendering piece which brings the rendering back to the app server for browsers that don't support This new way of doing things and present regular HTML to them. In time, with adoption of MOBHTML, I'd like to think that search engines would be able to Do the rendering at their end. I'd certainly be happy to write a plug-in for google. Thanks for the constructive comments, I was beginning to think this forum was dead, or worse full of cynics. Sunil Vanmullem www.paglis.co.uk -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hannes Ledl / LEDL PARTNER Sent: 22 January 2007 22:38 To: www-talk@w3.org Subject: RE: (MOB)HTML - Merge on browser HTML (was SDPML) Hi sunil For my understanding - you / your application serves pages an you let the client decide what to do - what to show. But why you leave the decision to the end of the line (the client / the browser) what about the way keep this decision at lowest level. The server - an keep the content submitted with a lowest as possible logic. Let the server handle the content for the appropriate browser and only serve content really needed. How do you think about SEO? I think, the 'googles' will not handle your content as you want to have. Regards from Austria - Velden Hannes Ledl http://www.ledl.at
RE: (MOB)HTML - Merge on browser HTML (was SDPML)
Hi sunil For my understanding - you / your application serves pages an you let the client decide what to do - what to show. But why you leave the decision to the end of the line (the client / the browser) what about the way keep this decision at lowest level. The server - an keep the content submitted with a lowest as possible logic. Let the server handle the content for the appropriate browser and only serve content really needed. How do you think about SEO? I think, the 'googles' will not handle your content as you want to have. Regards from Austria - Velden Hannes Ledl http://www.ledl.at
RE: (MOB)HTML - Merge on browser HTML (was SDPML)
Hi Mike Q: Why use HTML tags at all? HTML is used to keep things as simple as possible - the templates can be authored in any existing HTML editing tool. XML/XSLT uptake is in the future in due to complexity of authoring HTML used to keep the download size small, this solution works on mobile devices running Minimo. The prototype is fulfilling one of its roles: to stimulate discussion. Q: Isn't this just 'client side includes' or Xlink or such? technically this is client side includes using AJAX with variable substitution While this sounds obvious, I'm not aware that its been done before. The syntax of the mark-up has rudimentary flow control and Boolean operators - so not a straight client side include. Thanks Sunil -Original Message- From: S. Mike Dierken [mailto:[EMAIL PROTECTED] Sent: 07 January 2007 23:22 To: 'sunil vanmullem'; www-talk@w3.org Subject: RE: (MOB)HTML - Merge on browser HTML (was SDPML) Q: Why use HTML tags at all? Q: Isn't this just 'client side includes' or Xlink or such? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of sunil vanmullem Sent: Sunday, January 07, 2007 3:23 AM To: www-talk@w3.org Subject: (MOB)HTML - Merge on browser HTML (was SDPML)
