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" <sunil.vanmullem@btopenworld.com>
To: <hannes.ledl@ledl.at>
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: www-talk-request@w3.org [mailto:www-talk-request@w3.org] 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

Received on Wednesday, 24 January 2007 11:33:11 UTC