Re: [FileAPI] Remove readAsBinaryString?

I don't think it's practical for developers to follow the change logs. 
I've certainly missed a few.

While readAsBinaryString and readAsDataURL are very rarely used, it 
seems to me that editors should take some extra effort to help out 
developers who have in good faith, jumped on the HTML5 bandwagon. Web 
Apps and HTML5 seem to me, to be quite different than other specs. I 
think they're a special case.

Google code search shows readAsDataURL to be about as popular as the 
deprecated readAsBinaryString. It'd be nice if somewhere, near the spec 
but not in it, this history was maintained in a readable and index-able 
form. Change logs do accomplish that, but they are more difficult to get to.

http://www.google.com/search?q=readAsBinaryString

I do think that this deprecated feature can be removed from the File API 
spec altogether. I'd still like a human-usable place to point to.

Scenario: Alice, a random developer, sends a note to Bob a phonegap 
committer about readAsBinaryString being deprecated. Bob is surprised, 
looks at the File API spec and sees that the method indeed is missing. 
"What happened?", wonders Bob. Bob knows the specs are in constant flux, 
and doesn't know what to do. Bob is scared.

Even a simple Editors log supplemental would give some credibility and 
explanation for the change, allowing Bob to feel more confident in 
removing hooks, even allowing Bob to update his own change logs with 
references to the editor's changes.

It's just a bit more formal than pointing to VCS revision markers.

I hope I've helped a little here. To be absolutely clear: I'm fine with 
the method being removed, and I'm not demanding the editor stash the old 
IDL, text nor reason in any particular place. I'm just requesting we 
consider that, as part of this living spec process, we maintain a living 
journal of deprecated APIs.

-Charles

On 12/18/11 11:42 AM, Ojan Vafai wrote:
> What's the point of having deprecated features in a spec? If the 
> purpose of a specification is to get interoperability, then a UA 
> either does or doesn't need to implement the feature. There's no point 
> in keeping a feature that we think should be killed and there's no 
> point in removing a feature that can't be killed because too much web 
> content relies on it.
>
> DOM4 does mark some things as "historical", but DOM4's use of 
> "historical" is different than deprecating it in a subtle but 
> important way. The historical bits in DOM4 will still need to be 
> implemented by all UAs, but the features they correspond to won't 
> (e.g. enums for node types that we're killing are kept).
>
> On Fri, Dec 16, 2011 at 8:42 AM, Arun Ranganathan 
> <aranganathan@mozilla.com <mailto:aranganathan@mozilla.com>> wrote:
>
>     I'm happy to remove this from the specification.  Right now this
>     is marked as deprecated, which I suppose isn't strong enough
>     discouragement?  :)
>
>     ----- Original Message -----
>     > Another topic that came up at TPAC was readAsBinaryString [1]. This
>     > method
>     > predates support for typed arrays in the FileAPI and allows binary
>     > data
>     > to be read and stored in a string. This is an inefficient way to
>     store
>     > data now that we have ArrayBuffer and we'd like to not support this
>     > method.
>     >
>     > At TPAC I proposed that we remove readAsBinaryString from the
>     spec and
>     > there was some support for this idea. I'd like to propose that we
>     > change
>     > the spec to remove this.
>     >
>     > Thanks,
>     >
>     > Adrian.
>     >
>     > [1] http://dev.w3.org/2006/webapi/FileAPI/#readAsBinaryString
>
>