W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2010

Re: File API: Blob and underlying file changes.

From: Juan Lanus <juan.lanus@gmail.com>
Date: Tue, 26 Jan 2010 13:38:42 -0300
Message-ID: <ae65f3f21001260838t5fd73e1bs624c9c81deba2e6b@mail.gmail.com>
To: public-webapps@w3.org
On Sun, Jan 24, 2010 at 8:04 AM, Juan Lanus <juan.lanus@gmail.com> wrote:

>> ** Locking
>> What's wrong with file locking?

> Rob O'Callahan answered that:
> One problem is that mandatory locking is not supported on Mac or most Linux
> installs.

Quite right Bob. But still the lock is the way to go. At least as of today.

HTML5 might be mainstream for the next 10 years, starting rather soon.

In the meanwhile OSs will also evolve, in a way that we can't tell
now. But if there are common issues, like this one, somebody will come
up with a smart solution maybe soon.
For example feeding an image of the file as of the instant it was
opened (like relational databases do to provide stable queries) by
keeping a temporary map to the original disk segments that comprised
the file before it was changed.
For example Apple is encouraging advisory locks
asking developers to design in an environment-aware mood.

Maybe now that I think it a bit more, specifying that the UA should
get a lock is telling HOW to do things, while the use cases practice
teaches us that at the requirements level one should say WHAT to do.

What if the specification only said that the UA has to do its best to
get an integral copy of the input file, or else after doing whatever
it MUST raise an error?
This will leave headroom for the UA designers and also is what the
specification says now, isn't it? I got scared by the "mutating blob"
Juan Lanus
Received on Tuesday, 26 January 2010 16:39:39 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:22 UTC