Re: [contacts] HTML5 Device integration proposal

Would it be a good idea to duplicate location in the device element as
well, so that it may be placed under the same controls as have been
contemplated in the DAP privacy policies?

I'm concerned about proceeding without an unencumbered privacy policy
in place, for location, contacts, audio, video, the device's file
system, and other databases that web apps developers want to use,
including network selection under multi-homing.


On Mon, Jul 5, 2010 at 11:16 AM, Rich Tibbett <rich.tibbett@gmail.com> wrote:
> This is a short and sweet proposal for low-level integration of the DAP
> Contacts API [1] to the candidate HTML5 Device element [2] being defined in
> WebApps.
> The rationale for this proposal is that regardless of whether a web page
> obtains address book data from either the programmatic method defined in [1]
> or a HTMLDeviceElement-based method yet-to-be-fully-clarified in [2] it
> should be capable of accessing any resulting contact data in a uniform way.
> By providing a DOM-based method in [2], the 'contacts picker' (as
> informatively described in [1] Appendix A) would be reusable for the
> HTMLDeviceElement method without requiring that the 'contact search
> notification' dialog to also be used in this approach. The result is one
> less click for the user in the DOM-based approach.
> The proposal for accessing Address Book information from the HTML5 Device
> element goes like this:
> <device type=people onchange="successContactFindCallback(this.data)">
> <script type="text/javascript">
> // Identical to the example provided in the Contacts API:
> function successContactFindCallback(contacts) {
>     // do something with resulting contact objects
>     for (var i in contacts) alert(contacts[i].displayName);
>     // ...
> }
> </script>
> where: HTMLDeviceElement.data will always be of type
> Contact[] whenever HTMLDeviceElement.type=='people'
> This element would render on a web page similar to the file input element
> except that it would load the 'contacts picker' on invocation by the user.
> This is notably not a form-based control, though data resulting from this
> control could be used to populate a web form.
> Could additional Contact API find() parameters be provided from a web page
> to the 'contacts picker' in the DOM-based approach as follows?
> <device type=people
> data-params="fields=name,emails;filter=Robert;updatedSince=2010-05-23T00:00:00Z"
> onchange="successContactFindCallback(this.data)">
> Any better ideas for the 'data-params' attribute that I used above
> considering it's not currently a common HTML5Element attribute?  Perhaps
> this attribute should be added to the HTMLDeviceElement interface in [2] or
> maybe an existing HTMLElement attribute (such as 'accept') could be reused
> for this purpose.
> Finally, a logistical question: How much of this proposal, if useful, can be
> included in the HTML5 Device document [1] vs. the Contacts API document [2]?
> Any feedback would be much appreciated. I'm just throwing the ball up in the
> air :-)
>
> - Richard
>
> [1] http://dev.w3.org/2009/dap/contacts/
> [2] http://dev.w3.org/html5/html-device/

Received on Monday, 5 July 2010 18:23:00 UTC