CFC: Getting rid of 'extras'

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

Received on Wednesday, 22 August 2012 21:13:11 UTC