- 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