Re: Web Intents W3C Editor's Draft 31 January 2012 - Review comments

On 3/14/12 2:59 PM, James Hawkins wrote:
>
> On Wed, Mar 14, 2012 at 2:43 PM, Greg Billock <gbillock@google.com 
> <mailto:gbillock@google.com>> wrote:
>
>     On Wed, Mar 14, 2012 at 12:56 PM, Charles Pritchard
>     <chuck@jumis.com <mailto:chuck@jumis.com>> wrote:
>     > Great job Greg.
>     >
>     > I'd like to see the intent element section brought closer in
>     line with
>     > HTML5's spec semantics.
>     > http://dev.w3.org/html5/spec/Overview.html#the-canvas-element
>
>     Thanks, Charles. I hadn't seen that form. I'll switch to it.
>
>     > With the intent registration tag, the only Category would be
>     "Embedded
>     > content".
>     > Include in the definition that the <intent> may have fallback
>     content.
>     >
>     > ....
>     >
>     > The WebIDL on the constructor is a little dated. I believe that
>     "raises" and
>     > "in" were taken out of current IDL.
>     > [Constructor(in string action, in string type, in optional any
>     >         data, in optional sequence<Transferable> transferList,
>     in optional
>     > dictionary<string> extraData) raises DOMException]
>     >
>     > I want to confirm that this IDL was intended; my understanding
>     earlier was
>     > that it would be:
>     > [Constructor(DOMString action, DOMString type, optional any
>     data, optional
>     > sequence<Transferable> transferList),
>     > Constructor(DOMString action, DOMString type, optional any data,
>     optional
>     > Dictionary<DOMString> extraData)]
>
>     I brought this up at the end of the thread about extras. What are
>     folks' opinions about using two constructors vs. having one with more
>     optional parameters? I favor having the one so that ports and extra
>     metadata can be mixed, even though it'll lead to an empty array
>     parameter sometimes.
>
>
> We can't self-limit the API by saying that using ports (transferables, 
> actually) obviates the need for extras since this is not necessarily true.
>
> I propose putting both the |extraData| and |transferList| as optional 
> parameters in one constructor, but have |transferList| as the last 
> parameter since we definitely envision it being the least-used of the two.

As I see it, they are for two different uses. For instance, I'm going to 
be using transferList, not extraData, in most of my uses. transferList 
is used by protocols, extraData is used by files/metadata.

They're both handy, but there's a bit of a push to get rid of cases like 
this:
new Intent('action','type', 'data', null, [transfer]);

There's a difference between these two semantics:
new Intent('intent:share','image/png', 'data:base64,....', { title: 'My 
image'});
new Intent('intent:share','image/png', { title: 'My image'}, null, [ 
imageData] );

That latter one is more of a protocol, though a basic one. It's still 
more complex than the first example.

That said, I don't feel too strongly about this. It's only a minor 
concern, and perhaps an unnecessary concern.

>
> I also propose shortening |extraData| to |extras| to match the Android 
> Intents API (plus it's shorter/cleaner).
>
"extraData" is just a descriptive part of the IDL. It looks like 
"getExtra(key)" is the accessor that authors would use.


-Charles