Andrew,
Thank you for your kind reply:
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.
I've put a corresponding wish up on SourceXchange:
http://www.sourcexchange.com/WishDetail?wishID=227
Anybody who would like to sponsor this development should please
submit an official SourceXchange RFP and/or comment the wish.
As for any more NOTEs, I am out of that business but I encourage
anyone with a friendly W3C Advisory Committee representative to
do whatever needs to be done.
[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.
Agreed; in pursuit of backward-compatibility it is best to
emphasize compatibility over backwardness. If MSIE and NS
stop interpreting ACCEPT as a filename pattern (which I hope
they both already have; I haven't checked lately) then I will
expunge that wart from the versions over which I have control.
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?
Yes, Client-file-maxlength would be useful for an ultra-thin
client with limited buffer memory, for example a wireless phone
with only a few MB of recording RAM. Lets hope Moore's law
buries that need.
Content-type-alternates was for lightweight content negotiation,
and depended on the server regenerating (or redirecting) the HTML
with different ACCEPT parameters; more trouble than it has been
worth, for certain.
As for Content-source-device (which I've accidentally called
"Content-device" once on these lists.) There is probably some
OCR application that could benefit from figuring different optical
contrast expectations from scanners and cameras, but that is
near the least of my worries. If anyone ever ends up needing
that, it could be done with creative use of x-tra parameters on
the Content-type header of the multipart/form-data submission, e.g:
Content-type: audio/... ;x-source-device=microphone
Then there's only MAXTIME left in the specification. Could you
suggest an application where this might be useful?
The guy who suggested it used to put together television shows.
All of these pie-in-the-sky features are distractions until the
basics are implemented on common browsers. Since SMIL seems to
want to be just like teevee, lets wait until browsers implement
a user-specified maximum time that SMIL presentations are
allowed to play before bothering device upload with MAXTIME.
And about the security considerations, lets just hope that
Java/J/ECMAscript and the DOMs aren't allowing write access to
the INPUT TYPE=FILE VALUE attributes and submitting forms by
themselves these days.
Cheers,
James