W3C home > Mailing lists > Public > public-script-coord@w3.org > July to September 2013

Re: Request for feedback: Filesystem API

From: Brendan Eich <brendan@secure.meer.net>
Date: Mon, 12 Aug 2013 10:51:10 +1200
Message-ID: <5208155E.5080106@secure.meer.net>
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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:37:50 UTC