compiled HTML?
Stan Letovsky <letovsky-stan@CS.YALE.EDU>
Errors-To: listmaster@www0.cern.ch
Date: Tue, 12 Apr 1994 15:19:44 --100
Message-id: <199404121316.AA03321@RA.DEPT.CS.YALE.EDU>
Errors-To: listmaster@www0.cern.ch
Reply-To: letovsky-stan@CS.YALE.EDU
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: Stan Letovsky <letovsky-stan@CS.YALE.EDU>
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: compiled HTML?
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Length: 2042
A random thought: the way the Web currently works, browsers are
required to also function as interpreters of HTML, taking unformatted
documents with formatting directives and producing formatted
documents, as well as handling the client side of the http protocol.
Does it make sense to consider providing an option of decoupling these
functions by defining a "compiled-HTML" format (henceforth C-HTML)
that would require considerably less processing on the client side?
C-HTML would be like .dvi to HTML's .tex; there would be a compiler
that would generate C-HTML from HTML. It would have the disadvantages
that the client would not be able to reshape the document to fit its
window or local style-sheet, but it might have the advantage of
speeding up document transmission. Whether there would be speedup
depends on a complex mix of factors: the expansion ratio of
HTML->C-HTML conversion plus network transmission speeds determine a
possible extra transmission cost for C-HTML (although I suspect that
this ratio could be made near or even lower than 1), whereas the
interpretation costs of C-HTML vs HTML would determine a display-time
speedup. For documents whose cost is dominated by image content
C-HTML would probably make little difference. My concern is with
complex forms for database interaction. Although on paper HTML with
fill-out forms looks like a very promising (albeit not yet fully
adequate) language for doing database front ends, its very slow speed
at transmitting complex forms (about 15 sec for a form containing
about 300 fields, using Mosaic 2.2, NCSA httpd 1.1 on a SPARC IPC,
client and server both on same machine) all but cripples it for that
purpose, since commercial form interpreters can load similar data in a
few seconds, and users expect form interaction to occur at interactive
speeds. At this end of the HTML-application spectrum, at least, the
potential performance improvements that might come with C-HTML would
make a big difference in the usefulness of the Web. Does this strike
any chords?
-Stan