SourceXchange wish (was Re: support for...)

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

Received on Monday, 3 April 2000 05:38:44 UTC