Re: request for new forms submission consensus "William M. Perry" <email@example.com>
To: firstname.lastname@example.org (Marc Andreessen)
Subject: Re: request for new forms submission consensus
In-reply-to: Your message of "Mon, 11 Oct 1993 05:48:22 MST."
Date: Mon, 11 Oct 1993 06:42:22 -0500
From: "William M. Perry" <email@example.com>
In response to your message dated: Mon, 11 Oct 1993 05:48:22 MST
>Can we come to a consensus on a forms submission method that uses
>HTTP/1.0 to deliver the contents of large forms (including multiline
>edit fields) to smart servers in the next week or two? (Unless we
>already have and I missed it...)
>All things being equal, I think I'd be happy with the current
>encoding method (name=value&name=value with escaping) just slapped
>into the body of an HTTP/1.0 'SUBMIT' request -- keeps things simple
>and straightforward, avoids creating a new syntax, is known to
>properly handle escaping issues, and servers and code already exist
>for decoding/handling it.
What about issuing a real MIME-message? multipart/text or something
like that (not a MIME guru, so somthing else might be more
appropriate). Each variable could have its own 'part'. Would this be
too much of a pain on the server side? (Imagine it would)
>To be honest, the idea of encoding it in some kind of SGML format
>does not excite me in the least -- what would be the added value?
>Also, I'd like to suggest that multiline text fields have a different
>type (e.g. "textarea") than single-line fields ("text"), as they
>really are different types of things, and imply different issues
>(semantics) for client-side handling.
Definitely agree with this! I'm going to have a few hours of coding
ahead of me to add all the forms options you guys put into Mosaic2p5
into my emacs browser.
Popup lists are great, but as I said in an earlier message, I think
we need to stay away from things like sliders and knobs.
Looking forward to playing with pre5 when I get to my xterm!