[contacts] Propsed addition of <input file> extensions to Contacts API

[FPWD critical path discussion -> point 2 in [FPWD-CRITERIA]: discussion
on browser integration]

In discussions on the mailing list we've talked about the necessary
integration with the browser [1] - and how that should be manifested for
DAP APIs.

The Contacts API is currently based around the navigator interface [2].
It is a necessary and continued requirement from a number of parties for
the API to be programmatic based on the initial inputs provided to the
DAP WG [3], [4].

There are also a number of parties alternatively requesting file picker
integration of DAP APIs [5], primarily around the ability to express
implicit user consent of selecting files to be shared (the user
implicitly provides permission to upload files that they select).

This proposal is to maintain the current programmatic access model of
the Contacts API but to include an Annex defining integration of the
result of a contacts-specific file picker operation with the same
low-level interfaces (i.e. the Contact interface) defined in the current
Contacts API.

So, in markup, I could request the following:

<input type='file' accept='pim/contact'>

...and the resulting object would extend the current File object defined
in the File Reader API with Contact attributes defined in the Contacts
API.

interface ContactFile : File {
	// ... ContactProperties
}

The proposal for this annex would therefore include two items:

1. Definition of a pim/contact file upload accept attribute extension
(extension to HTML5 section 4.10.5.1.18) that will filter the file
picker to 

	text/directory, text/vcard and text/directory;profile=vCard mime
type files

		and/or  

	*.vcf, *.vcard files.

2. Definition of a ContactFile interface that extends the File interface
defined in File API as the resulting object from the file picker markup.
All existing File operations remain, but the developer can also access
the parsed contents of a contacts file.


The intention of this proposal is for both models to co-exist within a
conforming implementation. That should read: if I (the developer) need
the user to select one or more contacts then: throw up a file picker and
let them select any/all requested contacts as required. On the other
hand, if the web app knows a specific contact (or set of specific
contacts) that is/are required (because the user has e.g. entered the
contacts phone number in the web app itself and would like to send this
contact an email) then: go the programmatic route to retrieve those
pre-known (or pre-inferred) contact objects subject to the security and
privacy mechanisms inspired from the Geolocation WG to obtain the user's
express permission for this action.

Dependent on the nature of interaction required with a user's contacts
(from the examples provided in the previous paragraph), and dependent on
the preference of the current web app workflow, either model can be
applied by the developer depending on the current usage context. Both
models will result in the same 'contact' object, regardless of the
access method used.

This proposal fails if either party is not convinced of the security or
value of providing both models in a conforming UA. In this case, we will
continue to refine what we have - this is just a proposal at this stage.

So what we think? Perhaps we can address this approach?

Kind Regards,

Richard


[FPWD-CRITERIA]
http://lists.w3.org/Archives/Public/public-device-apis/2009Nov/0247.html

[1]
http://lists.w3.org/Archives/Public/public-device-apis/2009Oct/thread.ht
ml#msg8

[2] http://dev.w3.org/2009/dap/contacts/#devicecontacts-interface

[3]
http://lists.w3.org/Archives/Public/public-device-apis/2009Apr/att-0001/
contacts.html

[4] http://bondi.omtp.org/1.01/apis/contact.html

[5]
http://lists.w3.org/Archives/Public/public-device-apis/2009Nov/thread.ht
ml#msg7

Received on Tuesday, 1 December 2009 12:06:38 UTC