W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2010

Re: BlobWriter simplification/split

From: Jonas Sicking <jonas@sicking.cc>
Date: Thu, 1 Jul 2010 16:34:56 -0700
Message-ID: <AANLkTimXEQ3FgIbHfmL6AyBgvTyXZDi8nRZAlm4wNg-q@mail.gmail.com>
To: Eric Uhrhane <ericu@google.com>
Cc: Web Applications Working Group WG <public-webapps@w3.org>
On Wed, Jun 30, 2010 at 10:18 AM, Jonas Sicking <jonas@sicking.cc> wrote:
> On Tue, Jun 29, 2010 at 5:17 PM, Eric Uhrhane <ericu@google.com> wrote:
>> Following up on discussions mainly at [1] and use cases at [2], I'd
>> like to propose splitting the BlobWriter [née FileWriter] class, with
>> an eye to solving some UI problems and simplifying implementation.
>>
>> When saving a Blob to a location outside the FileSystem API sandbox,
>> we want to prompt the user exactly once, and want to be able to
>> indicate that a write is taking place, e.g. by throbbing the download
>> indicator.  We want the throbbing to go away as soon as the write is
>> done, and we don't want the app to have continued privileges to write
>> outside the sandbox.  [That's been debated, but I think it's beyond
>> the scope of what we're working on so far, so let's leave that case
>> for later expansion.]
>>
>> When writing inside the sandbox, we probably don't need the throbber
>> at all, and we definitely don't want to prompt the user on each write.
>>  Leaving aside the question of how one obtains a BlobWriter without
>> using the sandbox and when exactly prompts happen [I'll open another
>> thread for that], I think that:
>>
>> *  We don't want to have the same API call cause prompts to pop up on
>> some instances of BlobWriter and not others.
>> *  We don't want to have the same API call be reusable on some
>> instances of BlobWriter and not others.
>>
>> I propose the following split:
>>
>> Define a parent class, SimpleBlobWriter, that's used for one-shot Blob
>> export.  This is what you use when you don't have the FileSystem API,
>> when the user selects the save location.  It contains a writeFile()
>> method, which writes a Blob to a file in a single operation.  It is an
>> error to call writeFile if readyState is not INIT, so SimpleBlobWriter
>> is single-use.  Its other members are abort(), readyState, the ready
>> state constants, error, length, and the progress event handlers, as
>> defined in the current spec.
>>
>> Derive from SimpleBlobWriter the class BlobWriter, which adds
>> position, truncate(), seek(), and write(), as defined in the current
>> spec.  This is what the FileSystem API's createWriter() call would
>> return.
>>
>> This lets you have different APIs for different behaviors, and removes
>> fields from SimpleBlobWriter that aren't actually useful without the
>> FileSystem API.
>>
>> How does that sound?
>
> Sounds great!

Actually, i realized that I have second thoughts on some details here.

It would be great if the "save as" functionality provided by the
SimpleBlobWriter worked such that at the time the "where do you want
to save a file" dialog pops up, the UA already knows what Blob is
going to be saved. This has several advantages over the UA first
receiving a request to save something, and then receiving the data
that is to be saved. For example:

* If the Blob is a File, default the filename to File.name
* Allows the UA to display the size of the file, thus allowing the
user to save to different locations depending on the expected size of
the file
* Allows the UA to determine the type of the Blob and adjust the
filename based on that. Firefox does this for content-disposition
save-as dialogs.

As a separate question, at what URL are the latest drafts available?
Is http://dev.w3.org/2009/dap/file-system/file-writer.html still
authoritative?

/ Jonas
Received on Thursday, 1 July 2010 23:35:58 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:39 GMT