W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2010

Re: FormData and BlobBuilder - duplication of functionality?

From: Kinuko Yasuda <kinuko@chromium.org>
Date: Thu, 15 Apr 2010 17:50:36 -0700
Message-ID: <y2gf6ddb9231004151750u8cb9e064v3106584edb98a48f@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: Michael Nordman <michaeln@google.com>, Dmitry Titov <dimich@google.com>, Web Applications Working Group WG <public-webapps@w3.org>, Eric Uhrhane <ericu@google.com>
On Thu, Apr 15, 2010 at 5:34 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> On Thu, Apr 15, 2010 at 5:20 PM, Kinuko Yasuda <kinuko@chromium.org>
> wrote:
> >>> > [Constructor] interface FormData { Blob toBlob (); void
> >>> > append(DOMString
> >>> > name, Blob value); void append(DOMString name, DOMString value); };
> >>> > Also it looks like BlobBuilder (in the draft dimich linked to) is
> >>> > lacking a
> >>> > means for the caller to set the type attribute of the blob being
> built.
> >>> > A couple ways that could be provided...
> >>> > [Constructor] interface BlobBuilder { attribute DOMString endings;
> >>> > attribute DOMString type; // option a
> >>> > Blob getBlob (in DOMString type); // option b void append (in
> DOMString
> >>> > text) raises (FileException); void append (in Blob data); };
> >>>
> >>> I don't feel strongly, but "option b" looks cleaner to me. Might want
> >>> to make the argument optional though, and default to the empty string.
> >>
> >> Option b works for me and agreed it should be optional with empty being
> >> the default value.
> >
> > I prefer option b as well.  (Especially if there'll be a use case where
> > users want to change the 'type' each time they call getBlob())
> > What will be the default type of Blob when it's not specified?
>
> The empty string.
>
> > In this generally agreed proposal, if we append a blob made by FormData
> to
> > another FormData, we will be getting a nested multipart data, right?
>
> Yes.


Thanks for confirming.  All sound good to me.


>
> / Jonas
>
Received on Friday, 16 April 2010 00:51:25 GMT

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