Re: compiled HTML?
"Daniel W. Connolly" <connolly@hal.com>
Errors-To: listmaster@www0.cern.ch
Date: Tue, 12 Apr 1994 17:17:01 --100
Message-id: <9404121510.AA28404@ulua.hal.com>
Errors-To: listmaster@www0.cern.ch
Reply-To: connolly@hal.com
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: "Daniel W. Connolly" <connolly@hal.com>
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: Re: compiled HTML?
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Length: 1318
In message <199404121316.AA03321@RA.DEPT.CS.YALE.EDU>, Stan Letovsky writes:
> 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.
I think the delay you're seeing is not in document transmission, but
rather in the code in the Mosaic HTML widget that lays out the various
fields. It's either in Mosaic HTML widget code, Xt geometry management
code, or OSF Motif widget code.
I think the Mosaic forms implementation is somewhat "quick-and-dirty."
If you're interested in snappy performance for 300-field forms, you've
got to put more engineering into the forms support.
You could do the formatting on the server side, but I doubt that would
be optimal, since the server doesn't know whether it's formatting for
an X display, a Mac, or a vt100. I think this is a client-side issue.
Dan