RE: Files on IndexedDB

Comments below.

-----Original Message-----
From: Jonas Sicking [mailto:jonas@sicking.cc] 
Sent: Wednesday, June 12, 2013 8:56 AM
To: Arthur Barstow
Cc: piranna@gmail.com; Webapps WG
Subject: Re: Files on IndexedDB

Hi Art,

Actually, the response in [2] says that we should clarify in the spec
that files, blobs and filelists are stored "by value" rather than "by
reference". This is not a normative change since the spec already
defines this behavior. However the behavior is defined somewhat
indirectly which means that it'd make sense to clarify it explicitly.

/ Jonas

<bryan> It's still not clear to me why you say that File blobs (blobs as extended by the File API) are stored by value. The current working implementation across multiple shipping browsers would say that File objects are not stored by value, but that when read (as in "8.5.4. The readAsText(blob, label) method") the current filesystem data is read, not a stored copy. Perhaps I'm misunderstanding the intent of this proposed change, and it would not actually change current implementations. But the section 8.5.4 is pretty clearly (to me) referring to an operation that reads data from the underlying filesystem, e.g. "While processing the read, as data from the blob becomes available..." indicating that there is a process of reading from some storage. It would not make sense for example if I have a 1GB file that I want my app to read, that the browser has to make *two* copies of it - one in some browser-temporary/hidden filesystem location (as a copy of the original file) and the second, in-memory copy. It would be much more straightforward, and support the existing UX, if the browser reads the current filesystem version when "readAs..." methods are called.

Thanks,
Bryan Sullivan 

On Tue, Jun 11, 2013 at 11:24 AM, Arthur Barstow <art.barstow@nokia.com> wrote:
> Hi - your comment is considered a "Last Call comment" and it was included in
> the LC's comment tracking document [1].
>
> In [2], Joshua proposed this comment be addressed/resolved as a feature
> request and as such, it was added to the IDB feature request list [3].
>
> For the purposes of tracking your comment, please indicate if this
> resolution is acceptable or not.
>
> -Thanks, ArtB
>
> [1]
> <https://dvcs.w3.org/hg/IndexedDB/raw-file/default/Comments-16-May-2013-LCWD.html>
> [2]
> <http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0817.html>
> [3] <http://www.w3.org/2008/webapps/wiki/IndexedDatabaseFeatures>
>
>
>
> On 5/30/13 5:24 AM, ext piranna@gmail.com wrote:
>>
>>
>> According to IndexedDB specification, File and Blob and FileList objects
>> should be allowed to be stored inside IndexedDB doing a shallow copy. On
>> Mozilla this is possible, although File and Blob objects are stored
>> nativelly on a special place on the hard disk. Chrome is working on it at
>> this moment. Problem is, seems they are being duplicated and a copy is
>> stored instead of a reference to the original File. I think is not the
>> correct way to do it... or at least not always.
>>
>> File and FileList objects are only available from Input tags (at this
>> moment you can't be able to create them by hand, and also can't be
>> downloaded, only Blob objects), so they exists on the user hard disk, so
>> it's not necesary to make a duplicate and waste space. It would make sense
>> to store a copy inside IndexedDB when you want to store it, but if you want
>> to store only some metadata for the File object (for example a hash of the
>> file, or a flag for "already viewed" chapters on a local hard disk stored
>> serie) making a copy is useless.
>>
>> Also, although is being currently discused, FileList objects are suposed
>> to be "live" objects showing the current status of a directory each time is
>> readed (both added, updated and removed File objects), and File objects
>> should work the same, working mainly as references to the hard disk status
>> that would not be the actual one if they are stored duplicates on the
>> database (they will show the status when the File / FileList was stored),
>> and specially when the IndexedDB is accessed between reloads.
>>
>> On the other hand, Blob objects can be created and downloaded, so it makes
>> sense to store duplicates of data that's currently on RAM and would
>> disappear after a page reload, in the same way you save your work before
>> closing an application.
>>
>> So my proposition is about to allow the File and FileList objects being
>> stored as actual references to the original hard disk File and FileList
>> objects instead of data duplicates, and only store really inside IndexedDB
>> data from Blob objects. This way would allow to store references to opened
>> File and FileList objects between reloads of the page without requiring to
>> the user to re-select them and process them again as new, while allowing to
>> store data (also File objects) inside IndexedDB in the form of Blob objects.
>>
>
>

Received on Wednesday, 12 June 2013 02:18:21 UTC