- From: Brian LeRoux <brian@westcoastlogic.com>
- Date: Wed, 7 Oct 2009 12:15:22 -0700
- 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
filter.
> 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 });
+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