W3C home > Mailing lists > Public > www-html@w3.org > April 2000

Re: support for Salsman proposal for form-based device input

From: Clover Andrew <aclover@1VALUE.com>
Date: Mon, 3 Apr 2000 10:06:33 +0200
Message-ID: <5F78AA062F6AD311A59000508B4AAF6D092AF1@pcs02>
To: "'www-html@w3.org'" <www-html@w3.org>
James P. Salsman <bovik@best.com> wrote:

> Suppose that when ACCEPT includes "audio/*" that another button, 
> labeled "Record...", for example, would be rendered, set up to 
> launch an external recorder helper application instead of set 
> within the layout.  And for "image/*" there would be a button 
> with "Capture photo..." or something like that [...]

This is a great idea. The only change needed would be a Note in
the HTML to say that user agents MAY choose to do it, where an
API exists on the host platform for device capture of that type.

> [MS and Netscape should fix ACCEPT]

Quite so. Even with a DEVICE attribute, the ACCEPT setting would
*still* have to implemented properly; giving it a different
syntax for file and device as in device-upload.html loooks like
an unnecessary and confusing wart to me, not to mention it
breaking the HTML 4 definition.

I can't see anything a server could usefully do with
Client-file-maxlength or Content-type-alternates(*), and I can't
think of any reason it should need to know Content-source-device.
Are there any particular circumstances where these could be used?

Then there's only MAXTIME left in the specification. Could you
suggest an application where this might be useful? The only
analogue I can think of is that kind of answerphone that
annoyingly cut you off in the mid

(Sorry.) Anyway, the ostensible reason they do that is to
avoid wasting all their recording space. For a web server, file
length rather than time would be the limiting factor to this,
and that could better be limited with the LENGTH attribute,
couldn't it?


> The protocol proposed in this draft has been proven to scale
> for very large files, but is not intended for open-ended
> uploads of content of indeterminate length. 

Thought: chunked transfer-encoding in HTTP requests?

(*: this may be an old chestnut but I haven't seen mention of
it anywhere; shouldn't it, grammatically speaking, be
"alternatives"? I'm sure I've seen both multipart/alternate
and /alternative in use, are both allowed?)

Andrew Clover
Technical Support
Received on Monday, 3 April 2000 04:10:15 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:05:53 UTC