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

Re: BlobWriter simplification/split

From: Eric Uhrhane <ericu@google.com>
Date: Thu, 1 Jul 2010 16:40:17 -0700
Message-ID: <AANLkTikpNlcjFjqU_y3rEoBYQhynWOlqOwNGfWqOMIoX@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: Web Applications Working Group WG <public-webapps@w3.org>
On Thu, Jul 1, 2010 at 4:34 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> 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.

Yeah,take a look at [1] as well; this could eliminate the need for the
save/writeFile call on the simpler interface.

> 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?

Yes, I haven't moved or renamed it, though the path and name are now
both obsolete.
That's probably worth doing as of WebApps publishing an official draft of it.

     Eric

[1] http://lists.w3.org/Archives/Public/public-webapps/2010JulSep/0023.html
Received on Thursday, 1 July 2010 23:41:06 GMT

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