- From: Greg Billock <gbillock@google.com>
- Date: Thu, 20 Sep 2012 10:27:12 -0700
- To: Jungkee Song <jungkee.song@samsung.com>
- Cc: Tobie Langel <tobie@fb.com>, Norifumi Kikkawa <Norifumi.Kikkawa@jp.sony.com>, Paul Kinlan <paulkinlan@google.com>, WebIntents <public-web-intents@w3.org>, public-device-apis@w3.org, Frederick.Hirsch@nokia.com
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:40 UTC