RE: Contacts API typical use cases and privacy considerations

On Fri, Feb 19, 2010 at 16:30, Dominique Hazael-Massieux (dom@w3.org) wrote:
> Le vendredi 19 février 2010 à 17:25 +0100, 
> richard.tibbett@orange-ftgroup.com a écrit :
> > Is your proposal that a Contacts.find() entry point should 
> throw up a 
> > 'contacts picker' to the user? i.e. when the API is called 
> the user is 
> > presented with a 'contacts picker', proceeds to select the 
> contacts to 
> > work with and the browser provides the user-selected 
> Contact objects 
> > back to the webapp?
> 
> It would probably have to be a separate method (provided we 
> want to keep the functionality that Contacts.find() offers), 
> but yes, that's the basic idea.
> 

Calling a JS method that throws up a contacts picker has the implication of producing a blocking JS dialog. We should therefore mandate that any contacts picker that is render be non-modal.

If this is correct, this proposal is just a different interpretation of the user interface required when accessing Contacts.find(): throw up a non-modal 'contacts picker' interface instead of a non-modal 'Allow'/'Deny' interface for example.

1. the Contacts.find() API syntax remains as-is:

e.g., navigator.service.contacts.find({}, successCB, errorCB, {fields:['name','addresses']})

2. the 'Security and Privacy Considerations' may not need modification. 

Perhaps we need to be more formal on this approach in the methods and/or 'Security and Privacy Considerations'? My initial reaction is that we don't.

I'm liking this approach.

Thoughts?

- Richard


*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************

Received on Friday, 19 February 2010 16:57:23 UTC