Re: CFC: Getting rid of 'extras'

Can you provide an example to show before and after?  A few disparate cases
would be helpful to see the impact of the change.

Thanks,
James

On Wed, Aug 22, 2012 at 2:09 PM, Greg Billock <gbillock@google.com> wrote:

> In June, we discussed getting rid of getExtra() in favor of an extras
> attribute (i.e. [1]). I'm increasingly persuaded that we should just
> get rid of extras altogether. When this was proposed [2], it was
> because we knew we needed to be able to attach metadata to the payload
> data for pre-existing types (such as MIME types). But a better scheme
> to deal with that is to create extensible payload formats to begin
> with. Such formats have to be documented anyway (see e.g. [3]), and so
> it is better to just use the existing structured-clone payload to
> describe the type. Any extra header information can just be included
> there.
>
> So the proposal is to strike |getExtra()| from the API, and add a best
> practices recommendation that any documented payload type passed
> through |data| be a Javascript Object type so that fields may be added
> to it as necessity arises.
>
> This would mean a revision to documents such as [3], but going forward
> it puts data passing on a firmer footing where types get designed with
> extensibility in mind from the beginning. I don't think we even really
> lose any generality -- web developers need to consult documentation to
> figure out which extras keys mean what, anyway, and as we've learned
> from trying to pass MIME types, there end up being reasons to want to
> pass, say, both URLs and Blobs through the type anyway, not to mention
> even better future constructs, such as Stream [4], so there isn't much
> intuitive power in the type anyway. If you have to consult the
> documentation, it's easier to document the type as one object, rather
> than as the object and then extras data.
>
>
> [1]
> http://lists.w3.org/Archives/Public/public-web-intents/2012Jun/0118.html
> [2]
> http://lists.w3.org/Archives/Public/public-web-intents/2012Mar/0003.html
> [3] http://www.w3.org/wiki/WebIntents/MIME_Types
> [4] http://dvcs.w3.org/hg/streams-api/raw-file/a3858f3ef0ae/Overview.htm
>
>