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 09:52:51 -0700
Message-ID: <a4bcf6320910070952p52176b72l50e7219c7f9d7d3f@mail.gmail.com>
To: anssi.kostiainen@nokia.com
Cc: public-device-apis@w3.org
I do love iteratator approach tho it would not solve our performance
issues in the way that phonegap has to be implemented.

On Wed, Oct 7, 2009 at 2:41 AM,  <anssi.kostiainen@nokia.com> wrote:
> On 7.10.2009 4.42, "ext Brian LeRoux" <brian@westcoastlogic.com> wrote:
>
>> Groups can be very useful and, one use case in particular, would be to
>> support subsets of your contacts. For example: Friends, Family, Work,
>> Work Friends. Very helpful for filtering messages and knowing whom is
>> appropriate for that next chain email you need to send out.
>>
>> I would like to recommend: MAY enable the ability to CRUD groups of contacts.
>
> +1
>
>> Something we ran into with PhoneGap was the need to paginate results.
>> Some of the platforms support this out of the box. Others don't seem
>> to be worried about any user experience lag related to painting 5000+
>> contacts to a mobile screen. At any rate, loading 1000's of contact
>> object literals into an array was rather cpu intensive. I would like
>> to recommend:
>>
>> SHOULD provide an interface for pagination of contacts listing.
>
> The performance issue is a valid point. We could also use an iterator to
> tackle this (see Nokia's strawman proposal for Contacts API [1]). Yet
> another alternative would be to combine an iterator with pagination (e.g.
> the API returns an iterator of arrays where each array contains requested
> number of contact objects). Btw. this API design decision has implications
> to other interfaces dealing with large number of objects as well.
>
> IMHO one potential downside of the iterator approach is that it's not as
> convenient to work with as arrays. With arrays we have built-in support for
> e.g. Array.prototype augmentation, length property and useful array methods
> such as concat(), push(), pop() etc.
>
> For reference, Mozilla has been experimenting with iterators in JavaScript
> 1.7 [2].
>
>> And finally I'd like to raise an issue. If we offer the idea of
>> pagination then it wouldn't be too far to assume that a search
>> interface should be offered. Thoughts?
>
> Surely there should be a search interface. Otherwise developers would end up
> fetching all the contacts and searching though them in JavaScript which is
> slow if the number of contacts is large. This UC can be implemented without
> a specific interface, but there are performance concerns.
>
>> In summary:
>>
>> MAY enable the ability to CRUD groups of contacts.
>> SHOULD provide an interface for pagination of contacts listing.
>
> I'd also add:
>
> MAY provide an interface to search through contacts.
>
> (Perhaps we'll have to do some pruning and decide what will fit in v1.)
>
> -Anssi
>
> [1]
> <http://lists.w3.org/Archives/Public/public-device-apis/2009Apr/att-0001/con
> tacts.html#contact_iterator_interface>
>
> [2] <https://developer.mozilla.org/en/New_in_JavaScript_1.7#Iterators>
>
>
>
Received on Wednesday, 7 October 2009 16:53:26 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:53:39 UTC