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

Richard,
I think co-existence of the input approach and a programmatic API approach is fine. 

But if *an* input approach for contacts is specified through extensions to the input element, that also is fine, but we might want to avoid the slippery slope of overloading the input element as a path to get to arbitrary content types or functions, e.g.

- image (click here to provide your picture)
- audio (click here to provide voice feedback)
- device status property (click here to allow me to read the battery level for you)
- message (click here to send a message)
- biometric identity (click here so I can authenticate you by thumbprint, retina scan)
- time (give me a minute, please)
- ...

Best regards,
Bryan Sullivan | AT&T
-----Original Message-----
From: public-device-apis-request@w3.org [mailto:public-device-apis-request@w3.org] On Behalf Of richard.tibbett@orange-ftgroup.com
Sent: Tuesday, December 01, 2009 4:06 AM
To: public-device-apis@w3.org
Subject: [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 Wednesday, 2 December 2009 16:36:23 UTC