Re: Supporting extra parameters on the Intent object

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