Re: Supporting extra parameters on the Intent object

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
>> >
>
>

Received on Tuesday, 31 January 2012 22:29:05 UTC