Re: Supporting extra parameters on the Intent object

I'm wary of adding even more filtering.  I disagree that we should
give the ability to filter by extra parameters as this increases the
footprint of the API in a way that restricts the usefulness of the
feature.  The extras should generally be optional, unless specified as
required by a particular action (Android supports this, but I'm not
sure we have a use case yet).  We can't force services to do The Right
Thing, but services that do The Right Thing should naturally rise to
the top of the ecosystem.


On Tue, Jan 31, 2012 at 5:49 AM, Paul Kinlan <paulkinlan@google.com> wrote:
> The majority of apps I have built so far care nothing about the
> filename at all because the data is consumed directly in the app and I
> would hate to mandate that the we need a file name or hardcode it
> someway.
>
> Android extra's are a point of burden in that for basic actions you
> never know the extra's to expect and they are not implemented
> consistently.  If we start with a good solid grounding of
> documentation, yet keep it freeform then we are in a better place.
>
> Can we light-weight encode the extras required by the client app so
> services can say only list services that defintely support "fileName"
> extras?
>
> If you look at the spec [1] we have thought about how we can ask for
> specific types of data such as a JPEG encoded as a link
> ("text/uri-list;type=image/jpeg" - the picker will list services that
> return links, but only links to images), and to Gregs' point earlier
> can we encode this requirement for a file name in the a way that will
> allow the UA to filter (or ignore)?  For example could we say
> "text/uri-list;requires=filename" then if a service didn't say it can
> provide this data it would not be presented in the picker?
>
> Taking this further, if a service initiated an action using `new
> Intent("http://webintents.org/pick", "text/uri-list", ... );` then a
> service registered to support "text/uri-list;requires=filename" would
> still be listed, but a service that only supports "text/uri-list"
> wouldn't as it has said it can't support the required data for the
> operation.
>
> P
>
> [1] - http://dvcs.w3.org/hg/web-intents/raw-file/tip/spec/Overview.html
>
> On Mon, Jan 30, 2012 at 3:36 PM, Rick Byers <rbyers@google.com> wrote:
>> 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
>>>
>>
>
>
>
> --
> Paul Kinlan
> Developer Advocate @ Google for Chrome and HTML5
> G+: http://plus.ly/paul.kinlan
> t: +447730517944
> tw: @Paul_Kinlan
> LinkedIn: http://uk.linkedin.com/in/paulkinlan
> Blog: http://paul.kinlan.me
> Skype: paul.kinlan
>

Received on Tuesday, 31 January 2012 18:41:22 UTC