- From: Pearson, Chris C <chris.c.pearson@intel.com>
- Date: Sun, 2 Apr 2000 10:16:07 -0700
- To: "'James P. Salsman'" <bovik@best.com>
- Cc: www-html@w3.org
James - While I certainly don't speak for Intel (much less the fabled "Wintel" :-), my view from the trenches certainly rebuts the notion that there is likely to be a failure to exploit compelling new technologies or capabilities. On the contrary, Intel puts significant resources into seeking out and promoting new uses for PCs. An observation about business in general is that interest level is often proportional to (perceived) market potential. One way to demonstrate market potential is to build and deploy products (or at least prototypes) that exploit the technology/capability. Having even a small user community helps take the decision out of the realm of speculation (or endless debate, as the case may be :-). Certainly, prototypes can be built using existing HTML/browser capability (such as the nefarious OBJECT/EMBED, on which I personally receive royalties ;-). Does such a prototype exist? Is anyone using it? If there is a real need, users won't care whether it's implemented in HTML or with a non-standard extension -- they'll be using it now! -- Chris ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Chris Pearson Enterprise Server Group, Intel Corporation CO5-201; 15400 Greenbrier Parkway; Beaverton, OR 97006-5771 Business: +1 (503) 677-5823; Fax: +1 (503) 677-6367 -----Original Message----- From: James P. Salsman [mailto:bovik@best.com] Sent: Saturday, April 01, 2000 10:58 PM To: timbl@w3.org Cc: Bob.Wohlsen@Schwab.com; dsr@w3.org; ietf@ietf.org; www-html@w3.org Subject: 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 13:16:28 UTC