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

Dear Dr. Berners-Lee,

Thanks for your message:

> Rather than trying to change The HTML specification, one needs to
> encourage this feature to be implemented, and implemented well.

I completely agree with that end goal, whether the means involve 
extending HTML or not.
 
> Ways to do this include:
> 
> 1. lobbying browser manufacturers;

I've tried this, spending solid weeks on the phone, writing email, 
and talking in person to developers from Microsoft and Netscape, 
without any luck.  Microsoft has been the most frustrating, with 
people all over Redmond phoning me, talking for half an hour, and 
then never returning any further phone calls or emails.  At least 
Netscape has never even led me on like that (or shown any real 
interest.)  I kept quiet on the OBJECT/EMBED issues for so long 
partly because I thought Microsoft didn't realize how much wintel
was benefiting from them, which seems very stupid of me in hindsight.

My impression is that *you*, however, could have them all scrambling 
to implement pure-HTML4-based microphone upload if you simply took a 
public stand on it.

> 2. doing it yourself to an open source browser such as Amaya or Mozilla;

Amaya doesn't even have the most rudimentary form of file upload.
Mozilla's was broken for most of the past six months --
  http://bugzilla.mozilla.org/show_bug.cgi?id=8209
-- and I'm still working on it.

> 3. sponsoring someone to do (2) on the open source exchange;
> 4. doing a great facility specification for it with simulated bitmaps to
> guide

It's occurred to me in the past couple days that integration with 
the layout engines could be a lot simpler.  Currently INPUT TYPE=FILE 
widgets are rendered with a text entry box for a filename, and a 
"Browse..." button.

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, and "text/*" could 
have an "Editor..." button, and so on for the other types.  That 
could be done much faster than anything I've seen proposed by 
anyone previously.

> It may be that a NOTE simply pointing to the need and making a spec for
> doing it as above *according to the HTML4 spec*  would be a good idea too.

The motivations section of the device upload NOTE points out the 
need, but do you think that the big browsers would pay as much 
heed to another NOTE than to a direct request from you?

Tim, how about if you just wrote an open letter to Microsoft and 
Netscape, asking that they correct their interpretations of the 
ACCEPT attribute (not a filename pattern!), and allow for 
launching customizable file-input helper applications, with the 
default for "audio/*" being the Microsoft Sound Recorder on 
their wintel platforms, as a starter.  Would you please do that?

For as many benefits as I think the device upload proposal has, 
with the Content headers, security considerations, default device
selection, MAXTIME, client buffer maxlength exposure, etc., I 
would drop my advocacy for all those factors, because they amount 
to nothing more than distractions until the major browsers just 
*do something* to at least make microphone upload real.
 
> To suggest an alternative way of  doing this (as for example in Mr Salsman's
> note) will of course lead to the possibility of two companies implementing
> it in different ways, which is something very counter-productive and which
> we try very hard to avoid.

That's not entirely fair, because there is nothing in the device 
upload proposal that would preclude device upload when the DEVICE 
attribute is not specified.  It is clear that your goal is to 
prevent problems from cropping up within HTML.  Won't you please 
ask Microsoft and Netscape to correct their problems with the 
ACCEPT attribute before they keep us all from these important 
features any longer?  Thank you.

Cheers,
James

Received on Sunday, 2 April 2000 01:58:26 UTC