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