Re: Request for feedback: Filesystem API

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. We have the choice here of
making move() between different filesystems fail, or act in a
non-atomic fashion. Both Brendan and I have asked for clarification of
what people prefer in this thread but with no answer so far. I prefer
to keep it working and act non-atomic, and I'm tempted to keep it that
way until we have some polyfill experience.
* enumerate() We need a way to enumerate, and I don't see a way to
make enumerate() atomic. So this one I think we're stuck with.
* deleting directories. I'll have to think more about this one.
* enumerateDeep() I think this one is needed to avoid forcing people
to deal with async recursion in the common cases. And it is no less
atomic, i.e. no more problematic, than enumerate().

I've tentatively removed copy().


/ Jonas

Received on Monday, 19 August 2013 22:06:25 UTC