W3C home > Mailing lists > Public > public-device-apis@w3.org > October 2009

Re: ACTION-19 contact api review / feedback

From: Brian LeRoux <brian@westcoastlogic.com>
Date: Wed, 7 Oct 2009 12:15:22 -0700
Message-ID: <a4bcf6320910071215u158a0802u2ff955941533be73@mail.gmail.com>
To: richard.tibbett@orange-ftgroup.com
Cc: anssi.kostiainen@nokia.com, public-device-apis@w3.org
> The subject of performance aside for a moment and focusing on the
> current proposal [1]: if we add a category/rel field to the Contact
> attributes then this should cover your use case for groups.

A very good point.

> In addition you would be able to filter and display groups using the
> existing ContactFilter interface defined in [1].

Interesting. I was only looking at the requirements currently and
contrasting those. This approach would work and could support
schemaless implementation if we didn't name the properties in the

> On the subject of performance, I'd agree with a concept of pagination
> over an iterator model. As pointed out an Iterator loses some
> interesting Array.prototype methods such as length, push and pop.

yeah, as I mentioned it really is the only workable solution with the
current phones

> In light of the current proposal [1] and to allow for pagination, how
> about the addition of a (optional) contacts filter options attribute to
> the device.contacts.addressbook.find method?
> E.g.,
> var friends = /*...*/device.contacts.addressbook.find({ category:
> 'friends' }, { limit: 10, page: 1 });


> I would rather make the existing ContactFilter interface more flexible
> to allow AND/OR pattern matching across the available contact attributes
> (thereby creating a more flexible universal search feature possible).
> Currently ContactFilter is rigid in it's search but it could be made to
> allow for more flexible search use cases:

Feels like a slippery slope!

> However, rather than going down a schemaless route I would prefer to
> define a more extensive, interoperable base of properties and attributes
> that a contact object should support with support for adding custom
> properties as and when required. This will provide a clearer idea of the
> fields that should be present in all implementations while still
> allowing scope to allow for extensions as and when required.

This is tricky b/c there is likely no way for us to satisfy every
potential property on a contact. I feel schemaless would be more
robust longer term / less cruft.

> On the subject of performance and async vs. sync contact searching, the
> specification [1] could define a DEFAULT value for ContactFilterOptions
> such as default page=1, default limit=200. This would keep contact
> searching performant and synchronous but could be overridden by the
> developer at their own peril.

I like this. +1
Received on Wednesday, 7 October 2009 19:15:58 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:32:12 UTC