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: development@crm20.com [mailto:development@crm20.com] 
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: development@crm20.com [mailto:development@crm20.com]
Sent: 23 January 2007 23:59
To: sunil vanmullem; hannes.ledl@ledl.at
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" <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 Thursday, 25 January 2007 01:41:00 UTC