- From: Rick Byers <rbyers@google.com>
- Date: Mon, 30 Jan 2012 10:36:43 -0500
- To: public-web-intents@w3.org
- Message-ID: <CAFUtAY-7AacU=r5k6z9hU_aM_tk4WbZhJp4gh2Mb_k-dGas7wg@mail.gmail.com>
I agree that having some such mechanism is essential. I've been experimenting with some real-world scenarios using the pick intent and it seems clearly broken without a filename. The proposed mechanism seems reasonable to me. My only concern is whether we really want to commit to all metadata for any intent being strictly optional. For the specific case of 'pick', I suspect that services that don't have any reasonable filename will be much rarer than clients that require a filename, and so I'd much rather put the burden on services to fabricate the filename when necessary than on the clients that need it (this can be non-trivial - eg. choosing an appropriate extension to match the mime type of the data for compatibility with systems like Windows). It would be a shame for every client of pick to have to maintain non-trivial filename generation code that only gets used in very rare cases - or worse, services deciding they have to fabricate filenames anyway due to a couple popular clients that don't properly do it themselves. Regardless, I think this API is OK for required metadata too - as long as we're clear in the definition of each intent on what is required. Rick On Mon, Jan 30, 2012 at 9:10 AM, Mounir Lamouri <mounir@lamouri.fr> wrote: > On 01/30/2012 02:30 PM, Paul Kinlan wrote: > > Because we want the data described by the "type", specifically a > > mime-type, to describe the just the data being sent. If you say it is > > an image/jpeg it must be a JPEG image that is received (which does not > > include the file name), not a JSON object with arbitrary values > > defined. > > I don't see the relation with JSON here... > Anyway, I wouldn't mind to have a Dictionnary returned instead of the > requested data but I understand your point here. Though, we could use > some WebIDL tricks to have this behaving as you want with data.value > always returning the requested data and [PutForwards=value] but I'm not > a big fan of PutForwards in general. > > -- > Mounir > >
Received on Tuesday, 31 January 2012 12:15:29 UTC