Re: Content of URL picked by Intent

My big worry about [{...}] is that it introduces a pitfall for
developers, who I think may naturally just use an object. If we
encourage handling both, that's essentially using "instanceof Array"
as the check, which is displeasing and, I worry, error-prone, since
developers may simply test with one form and not use the other.

The convention of just always using an array is preferable, but has
poorer ergonomics. It's disappointing to have to always use that form
when we suspect that the majority of uses won't utilize multiple
values. This also solves the problem of "pick" -- where the client
doesn't really need to pass any data, and the "type" field is more
like an "Accept" header.

So I'm leaning towards wanting to use "type" to differentiate these
cases. It's explicit, it doesn't complicate the single-value case. For
non-MIME types, I'm pretty confident this is the right approach --
they can define collection types and how they work, and there's no
trouble. The trouble is that MIME doesn't really have a good
collection type. Adam Barth suggested that a more MIME-pure specifier
here would be "multipart/mixed;type=image/*" That's not as compact as
"[]image/*", but since "[]image/*" isn't really a type in any
language, it has a certain appeal.

Any other intuitions about this? I think any of these proposals will
accomplish the goal, and what we're trading off is a developer
ergonomic issue -- some of the solutions will cause discomfort of
various sorts for various audiences, and we'd like to minimize the
aggregate discomfort. The discomfort I'm estimating as the most acute
is client developers wanting to get started. I'd like them to have as
few problems as possible using the API, and so I'd like to make their
path as clear as possible.


On Thu, Sep 20, 2012 at 3:58 AM, Jungkee Song <jungkee.song@samsung.com> wrote:
>> From: Tobie Langel [mailto:tobie@fb.com]
>> Sent: Thursday, September 20, 2012 6:30 PM
>>
>> On 9/20/12 7:22 AM, "Norifumi Kikkawa" <Norifumi.Kikkawa@jp.sony.com>
>> wrote:
>>
>> >Hi, thank you for your comments, Greg and Paul.
>> >I like Paul's idea. Consistency with android intent must help developers.
>>
>> I strongly disagree that consistency with Android intents should be taken
>> into consideration when designing an API for the Web platform. Especially
>> if this makes the API inconsistent with the rest of said platform.
>>
>> As previously mentioned in this thread, INPUT[type=file]'s `files`
>> property always points to a FileList[1], whether or not the multiple
>> attribute is set. Similarly, the `files` property of the dataTransfer
>> interface of Drag and Drop[2] also points to a FileList regardless of how
>> many files have been added to it.
>
> +1.
>
> Greg. I think using the 'type' parameter is one good idea but prefer [{...}]
> approach. Using 'type' to indicate multiple would add complexity to service
> implementation as well as service picker logic - i.e., the service
> identification with (action, type) pair, etc. As mentioned in [1], [{...}]
> style is being used in quite a few places in web context including the ones
> Tobie quoted above.
>
>
> Jungkee
>
> [1] http://lists.w3.org/Archives/Public/public-web-intents/2012Sep/0032.html
>
>
>
>> I don't see any benefit in diverging from this well-know and consistent
>> behavior.
>>
>> --tobie
>>
>> ---
>> [1]:
>> http://dev.w3.org/html5/spec/states-of-the-type-attribute.html#file-
>> upload-
>> state-(type=file)
>> [2]: http://dev.w3.org/html5/spec/dnd.html#the-datatransfer-interface
>

Received on Thursday, 20 September 2012 17:27:41 UTC