- From: Jonas Sicking <jonas@sicking.cc>
- Date: Thu, 29 Apr 2010 21:01:12 -0700
- To: Eric Uhrhane <ericu@google.com>
- 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 6:58 PM, Eric Uhrhane <ericu@google.com> wrote:
> 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.
I think you're misunderstanding what I'm proposing as implementation.
When someone stores an object like:
{
from: "jonas@sicking.cc",
to: "sven@swede.se",
subject: "Glad Midsommar!",
body: "Hi Sven, here are the pictures from the ABBA party at the
summer house.",
attachments: [file1, file2, file3, file4]
}
into an IndexDB store we can store the files (file1-file4) to the
users file system, but in a browser controlled folder and with browser
controlled file names. Then when this object is read out of the
IndexDB store, we'll return an object where the File objects refer to
the files on the file system. So any operations on those will be as
efficient as for FileSystem.
/ Jonas
Received on Friday, 30 April 2010 04:02:13 UTC