- From: Brendan Eich <brendan@secure.meer.net>
- Date: Fri, 09 Aug 2013 21:04:48 -0700
- To: Domenic Denicola <domenic@domenicdenicola.com>
- CC: Jonas Sicking <jonas@sicking.cc>, "public-script-coord@w3.org" <public-script-coord@w3.org>
Domenic Denicola wrote: > A filesystem API seems like the*perfect* candidate for applying the "add new low-level capabilities, allow web developers to iterate on higher-level ones, then standardize later" approach. Whoa there -- my name was plastered on that founding extensiblewebmanifesto thing. I believe you are mixing up two things: * Whether the proposed API can be prollyfilled (it can, on IndexedDB, Jonas says; possibly some perf pain but that's part of the deal). * Whether to standardize bare-bones primitives only, not just first. > For example: > > - At a glance, move, copy, removeDeep, and enumerateDeep seem like derivative APIs. Yes, but everyone will want them and they are uncontroversial. Extensible Web Manifesto never says to ultra-minimize and force library downloads of the exact derived methods everyone expects to be in the standard. Sometimes you can right-size. Also I doubt anything in W3C will be rushed here. Lots of time till final LC, and the important thing is to get to CR. These derived methods and the other things you mention do not cost much and they help people get off the ground sooner. You may be right about text handling, I'll leave that to sicking, but I don't think extend the web forward == over-minimize when we know You Will Need It. /be
Received on Saturday, 10 August 2013 04:05:19 UTC