Re: Supporting extra parameters on the Intent object

Yes.  Just raising a bug on the github project now.

On Tue, Jan 31, 2012 at 10:27 PM, James Hawkins <jhawkins@google.com> wrote:
> We definitely will.  Paul, can you add that to the spec for pick on
> webintents.org?
>
>
> On Tue, Jan 31, 2012 at 2:24 PM, Rick Byers <rbyers@google.com> wrote:
>> I agree with James that it's probably not worth the extra complexity to try
>> to support filtering based on extras (it would also be more confusing for
>> the user - wondering why their preferred service doesn't show up from some
>> clients).  I can see how filename for pick may not be as commonly required
>> as I thought, I'm OK with it being optional and so putting the burden on the
>> client to generate one when necessary.  But please lets make the wording in
>> the pick spec encourage the setting of this extra whenever some useful name
>> is available - without it the user experience seems broken in some cases.
>>
>> Thanks,
>>    Rick
>>
>>
>> On Tue, Jan 31, 2012 at 1:40 PM, James Hawkins <jhawkins@google.com> wrote:
>>>
>>> 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
>>> >
>>
>>



-- 
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 23:50:53 UTC