Re: BlobWriter simplification/split

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!

> [Better names for SimpleBlobWriter and
> BlobWriter would be quite welcome, BTW.]

May I propose FileWriter in place of BlobWriter? ;-)
You are actually always writing to files, so it would make a lot of sense IMO.

An alternative would be to rename SimpleBlobWriter to FileSaver and
have the two be completely separate interfaces. It doesn't seem like
the inheritance is adding much anyway?

/ Jonas

Received on Wednesday, 30 June 2010 17:19:28 UTC