- From: Eric Uhrhane <ericu@google.com>
- Date: Fri, 30 Apr 2010 10:39:53 -0700
- 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 9:01 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> 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.
You're right, I misunderstood. This is a lot better than I was picturing.
However, it's not a complete proposal; how do you want to handle
modifying Files?
You're still letting apps write to the filesystem. They don't get to
pick the filenames, but they can still write malicious payloads if
they can find a way to execute them. There's still some of the same
security risk, but this rules out legitimate ways to share files with
external apps, keeping the browser as a data silo.
Received on Friday, 30 April 2010 17:40:39 UTC