Re: BlobWriter simplification/split

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!
>
>> [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.

We renamed BlobReader based on the perspective that it took data from
a Blob and read it into memory.  Likewise BlobWriter takes data from a
Blob and writes it to a file.  I think the symmetry makes sense.
Calling it FileWriter also works, but then you're naming by
destination instead of source, so I don't think it complements
BlobReader as well.

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

I do like *Saver, though, since it clearly just saves an entire Blob.
How about BlobSaver [with method save() instead of writeFile] and
BlobWriter?

The inheritance gets you length, abort(), error, the state constants,
and all the progress events, which may have identical handlers in many
cases.  I think that's probably enough to be worthwhile.  Anyone else
want to chime in?

     Eric

Received on Wednesday, 30 June 2010 17:30:35 UTC