RE: [Device APIs Requirements] Input to Contacts API

Anssi,

If we are "in doubt" that can also be a sign of the need to think it through a little bit more, before we "leave it out". For the contacts properties example, if it is so easy to iterate over the contents (TBD based upon the data model as pointed out by my comments) or use "built-in constructs using well-known patterns" then I agree it makes sense to leave it out. But we should do what we can to clarify, to a reasonable degree, how built-in constructs and well-known patterns can be used to address the convenience provided in the BONDI API.

Re the need to support the SIM Contacts as an Address Book, sync is an orthogonal question. There are valid use cases to sync and not to sync, so that should not affect the decision to support SIM Contacts. Re SIM size and performance, these have increased significantly from the early GSM SIMs and new UICC's and the interfaces to them support high speeds. The vCard specification has also evolved (see RFC 2425 / RFC 2426) and supports most contact information use cases. 

Best regards,
Bryan Sullivan | AT&T

-----Original Message-----
From: Anssi Kostiainen [mailto:anssi.kostiainen@nokia.com] 
Sent: Thursday, October 29, 2009 3:34 AM
To: SULLIVAN, BRYAN L (ATTCINW); ext richard.tibbett@orange-ftgroup.com
Cc: Device APIs and Policy Working Group WG
Subject: Re: [Device APIs Requirements] Input to Contacts API

On 29.10.2009, at 0.27, ext SULLIVAN, BRYAN L (ATTCINW) wrote:

>> OK. This can be done by enumerating over the resulting properties  
>> of a
>> Contact object:
>
> If it's so easy to iterate over results, then I agree that's a  
> convenience we can discount. I'm not exactly sure from your example  
> but I guess you're saying that the contact object is an associative  
> array in which the property name is the index of an array entry for  
> that property. That is one assumption, but the contact object may  
> not be an associative array, right (TBD, and up to us)? Also will  
> every contact object contain every field as an array member (with at  
> least null as the value)? The way in which the developer would have  
> to search the array and/or test for the presence for a property  
> (which may be different from *support*) should be clear. If it's too  
> complicated, the value of the convenience function goes up. Since we  
> defined that convenience function in BONDI, my base assumption is  
> that it's also valuable in DAP.

I tend to think that the old wisdom in API design "when in doubt,  
leave it out" should be obeyed here especially if the given  
functionality is attainable via built-in constructs using well-known  
patterns.

> +++++
>> If we're talking about 'delete' then this can currently be done by
>> passing the required Contact objects sequentially through the
>> addressbook.remove function.
>
> I was talking about "delete". That's what I took "clear" to mean. In  
> this case this is a BONDI consistency issue only. Deleting contacts  
> (either a list or all) is not a common function I would expect, but  
> we did define it in BONDI and it seems pretty simple to implement,  
> either way.

The same as above. We should not make the destruction case to be too  
easy. rm -rf / is not too common to warrant its own method.

> +++++
> Re "device" or "SIM" based address book, we could add a read/write  
> attribute to the contact object, defining the "address book  
> type" ("phone", "SIM").
>


Yes, technically multiple address books (phone, SIM, cloud ..) are  
supported. I also see that the current API requirements document lists  
the following as a requirement from which the above is derived:

[[
    * MUST enable listing all available address books on the device;
]]

However, most normal users tend to stick with the defaults and are  
unaware of the fact that the contents of the address book can be  
stored into multiple places. Also developers would like to get their  
hands on the most authoritative data available and don't care from  
where the data comes from. IMHO this is a potential place for confusion.

My question is should we actually abstract this detail away from the  
developer and delegate the decision of  the data store selection to  
the platform (in the end this would typically be a setting a savvy  
user is able to change).

I tend not to see a situation where not keeping all the data stores in  
sync would be beneficial. By allowing API-level access for changing  
the data store would potentially create problems with synchronization  
between e.g. the device and the cloud data store. Also this could lead  
to a situation where the user is looking at the different address book  
from the one the developer is using.

A note related to SIMs. We should make a note and investigate how to  
deal with the limitations of SIMs. The data models they support may be  
modest i.e. a subset of the data model specified herein. The memory  
size is probably also very limited. Reading and writing to/from a SIM  
is also a slow operation. Someone who has studied this topic more  
could educate us.

-Anssi

Received on Thursday, 29 October 2009 14:06:17 UTC