Re: Supporting extra parameters on the Intent object

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