W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2010

Re: [FileAPI] Blob.URN?

From: Eric Uhrhane <ericu@google.com>
Date: Thu, 29 Apr 2010 18:58:47 -0700
Message-ID: <k2y44b058fe1004291858rb050d9bh934de0069f41849b@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: Robin Berjon <robin@berjon.com>, "Tab Atkins Jr." <jackalmage@gmail.com>, Darin Fisher <darin@chromium.org>, Michael Nordman <michaeln@google.com>, Web Applications Working Group WG <public-webapps@w3.org>
On Thu, Apr 29, 2010 at 3:35 AM, Jonas Sicking <jonas@sicking.cc> wrote:
> On Thu, Apr 29, 2010 at 3:00 AM, Robin Berjon <robin@berjon.com> wrote:
>>> Though admittedly I'm biased because I'm not sold on the whole
>>> FileSystem API and I don't expect anyone will step up and implement it
>>> in firefox anytime soon.
>> Care to elaborate?
> I don't see any significant advantages over the other storage methods
> we already have defined for Files and Blobs, specifically localStorage
> and IndexDB. And there are significant advantages of using a database
> to store files. For example if you're storing emails in a database,
> you can just stick the attachments as a property of the emails. And
> things like filename collisions and finename charset encodings and
> case sensitivity become a thing of the past.

I quite agree that emails belong in a database.  But I don't think
it's going to work very well for large media files.  Will you do video
editing with your blobs stored in a database?  How's it going to
handle overwriting just the id3 tag of an mp3 file?  Will it deal well
with 10GB of BlueRay?  The most reasonable proposals I've seen for
large media on top of a database effectively boil down to implementing
something that looks like a filesystem on top of the database, which
seems a lot less efficient than just going straight to the disk.  It
also doesn't get you the interoperability with external apps.

> Note that just because the APIs expose the files as being stored in
> the database, doesn't mean that the implementation has to physically
> store the files in the database if that is bad performance wise.

Then for large media you've got to have a filesystem on top of a
database on top of files.

> And there security aspects involved as well. I'm not entirely
> comfortable with any site being able to write just any file to my file
> system. For example writing viruses or malware seems like asking for
> trouble.

Well, you don't have to grant every site access to store files, of
course.  But if you're explicitly granting permission, is it harder
than getting a user to just download a bad file?  And this way at
least they'll be tucked away under the profile directory, not in a
place they tend to click on a lot.

> The only use case I have heard for FileSystem over IndexDB is that
> with FileSystem OS software like iTunes and iPhoto can pick up and
> index music and images stored by the site. While neat, this doesn't
> seem particularly urgent.

Is making the web better urgent?

Internally, we've got folks clamoring for filesystem access, and we're
far from the only folks doing web development ;'>.

Received on Friday, 30 April 2010 01:59:32 UTC

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