- From: Brendan Eich <brendan@secure.meer.net>
- Date: Mon, 12 Aug 2013 10:51:10 +1200
- 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: > From: Jonas Sicking [mailto:jonas@sicking.cc] > >> > Like Brendan points out, what is considered the "low-level capabilities" isn't always obvious. > > I think a good guide is whether it's "atomic" or not. Old Unix nerds like me recall read(2) was enough for directories, and the reading code had to grovel through the 14-byte filename / 2-byte ino blocks (wherefore strncpy, etc.). But readdir is a useful abstraction, reflected in remote filesystem protocols: one doesn't want to hardcode the directory entry structure into usercode. This is separate from atomicity. My point again is that we don't want reductionistic (i.e., stupid) single rules for what's standardized, with the rest pushed onto library authors (until everyone is so sick of downloading that a later standard spec absorbs the user-level implementations). It's good to follow this dialectic process, so don't let me be a wet blanket. But do consider that there are rules other than atomicity for guilding the art of design here. It's an art, not a science, because as Knuth said, we can't program computers to design APIs for us (yet). /be
Received on Sunday, 11 August 2013 22:51:42 UTC