Quick question on pick specification data format

[Rick Byers]

The pick intent specification doesn't seem very clear on it's data formats (some of this applies to the other intents specifications as well, but let's just focus on pick here first).  In particular:

• Implies that pick can be used only for data of type image/*, audio/*, video/* and text/uri-list.  
• Obviously the uri-list could point to anything through an extra level of indirection, but we shouldn't need an extra level of indirection.
• Eg., I should be able to invoke pick with say "text/vcard" to say explicitly that I want to pick a contact in vard format, right? 
• The specification doesn't seem to say explicitly that pick takes no data on input and returns data on output (although that's the obvious assumption)
• The spec suggests that the data can either be a single URI or an array of URIs, but some of the examples I've seen on the site assume it's one way or the other (eg. the example does only "output.src = data", but the imagmator demo correctly does "var url = $.isArray(data) ? data[0] : data").  Is there really any value in supporting the single URI case - all code would be simpler if this was always an array.  If we do want to support both, can we update the samples to make this clear (and to ensure they all work together)

I'd suggest clarifying / changing the pick specification as follows:

• Pick can accept any mime type
• In ALL cases, there is no input data, and the output data is an array of URIs which point to items of the requested mime type.

Thanks,

   Rick

[Paul Kinlan]

I should probably clear the documentation and examples up, and be a lot more specific.  

If I was developer asking for text/vcard, I would expect either an single instance of vcard data or URI reference to the data, or an array of vcard instances or URI references.

The instance could be anything that is Transferable or Cloneable using structured clone so: Object, Blob, data uri or string.  Currently it is on the burden of the developer to parse and check the data, and to check if it is a single isntance or an array.

I will clear up pick to say that it will not take data, but the type is what is expected in return - it is just that the representation of the type might take multiple guises.  It can't use be a URI because we need this to work offline - so a blob or JS object can work well in these scenarios.

P

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

[Rick Byers]

Thanks, in-line.

On Fri, Dec 23, 2011 at 11:39 AM, Paul Kinlan <paulk...@google.com> wrote:

I should probably clear the documentation and examples up, and be a lot more specific.  

If I was developer asking for text/vcard, I would expect either an single instance of vcard data or URI reference to the data, or an array of vcard instances or URI references.

Oh - I didn't realize it was legal to pass actual instances as the data.  That's definitely not clear from the pick specification (I thought it was pretty clear from the data formats section that only URIs were permitted).  Also I believe all the existing examples and demos violate this - they're prepared only to receive URIs.  I assume we need to be very precise about what types of objects are supported (to increase the chance that most pick providers will just work with most pick clients without being explicitly tested together).  We also need to consider versioning implications - at some point I assume the spec for pick will be locked and if we want to add a new dataformat type (eg. maybe TypedArray or some new Blob2) it will need to be a new intent (to avoid breaking old clients). 

The instance could be anything that is Transferable or Cloneable using structured clone so: Object, Blob, data uri or string.  Currently it is on the burden of the developer to parse and check the data, and to check if it is a single isntance or an array.

Cool.  But are you saying that the developer needs to have code to sniff strings to try to guess whether they're a URI or a vcard?  I can imagine there are some cases where this would be impossible (or at least very error prone).   

This is perhaps related to another problem I've got - the client of 'pick' will sometimes want to know a name (filename) for what has been picked (eg. for attaching to an e-mail).  For http URLs we can get it from the Content-Disposition (falling back to the suffix of the URL itself), but for other data formats we're screwed (would be a shame to have to ask the user to name files he's attached to an e-mail for example).   We could solve both problems by adding some structure to the format of the pick data.  Eg., say it's an object with optional filename, uri and data fields (where at least one of data or uri must be supplied).

I will clear up pick to say that it will not take data, but the type is what is expected in return - it is just that the representation of the type might take multiple guises.  It can't use be a URI because we need this to work offline - so a blob or JS object can work well in these scenarios.

From the other discussions I've had with you and James, I thought the intent here was to use data: (small) and blob: (large) URLs (but we have the unresolved issue about sharing blob-urls cross-origin).  Being able to transfer actual Blob objects (assuming it's done efficiently without a copy) would be great - as long as all clients are written to support it.

 

Rick

[Rick Byers]

In addition to specifying precisely the format of the data for the standard intents, the spec should also be explicit about the context required for any URLs.  In particular, should a client of 'pick' be able to rely on the URL being portable?  Eg., is it legitimate for my app to pass the URL I got to my server and fetch it from there (to avoid unnecessary download/upload on the client when transferring a file on-line), or might fetching the URL require some cookies that have been set on the client?

It looks to me like the google cloud picker example generates a secure URL which can be used from anywhere to get access to otherwise protected content (eg. an image in a picassa web album marked private to me only).  This seems like the right model to follow for all uses of pick to enable efficient implementations, but since it's not the most obvious thing to test developers will need specific guidance that their URLs must have this property.

Thanks,

   Rick