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

Re: Request for feedback: Filesystem API

From: Jonas Sicking <jonas@sicking.cc>
Date: Mon, 19 Aug 2013 15:41:53 -0700
Message-ID: <CA+c2ei-LTusyUt+g6Z2vEOBXomg8K+KAmuXyNL-tBgW_g1tk_Q@mail.gmail.com>
To: François REMY <francois.remy.dev@outlook.com>
Cc: "public-script-coord@w3.org" <public-script-coord@w3.org>, Brendan Eich <brendan@secure.meer.net>, Domenic Denicola <domenic@domenicdenicola.com>
On Mon, Aug 19, 2013 at 3:33 PM, François REMY
<francois.remy.dev@outlook.com> wrote:
>> On Mon, Aug 19, 2013 at 2:21 PM, François REMY
>> <francois.remy.dev@outlook.com> wrote:
>>>> I think this cuts to the core of your argument. My vision was to have
>>>> a low-level API. Like you say, conflict resolution can be handled so
>>>> many ways so I think it's best handled by libraries or by
>>>> application-level logic.
>>>
>>> It's totally fine, but then I'm with Domenic: I would object to any non-atomic function. Any non-atomic function either requires proper hooks to handle its non-atomicity or needs to be removed from the API surface, to avoid the risk of creating a state where a bad API get used because it's built-in, and does more bad than it does good.
>>
>> The only non-atomics that we have are:
>>
>> * move() between different filesystems.
>
> and also move() when there's already a folder using the same name at the specified location, and therefore conflicts.

That's still atomic and always fails.

/ Jonas
Received on Monday, 19 August 2013 22:42:51 UTC

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