Re: BlobWriter simplification/split

On Wed, Jun 30, 2010 at 10:29 AM, Eric Uhrhane <ericu@google.com> 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!
> >
> >> [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?
>

*Saver.save() is very good naming, short and sweet and tersely accurate.

As for the (*) noun. Whatever noun is chosen, it should probably be used for
the entire family (*Saver, *Reader, *Writer) for consistency. Also I don't
think its safe to assume that a *Saver interface will only ever be used to
dump a blob to a file (Jonas mentioned the possibility of dumping a blob
into an IndexedDB). These things make me lean towards Blob as the noun. Of
course... Y (bikeshed) MMV.