RE: [Device APIs Requirements] Input to Contacts API

Hi Richard,

Thanks for the feedback. I think the approach you're talking about is OK, if we apply it carefully and consistently across API's. I would describe it as an "atomic" approach in which the API's provide essential functions, and anything beyond that is considered a "convenience" that the developer or a Javascript framework is expected to provide. The balance between convenience (for the developer) and simplicity (for the vendor) is an important one. I was coming from the functional set that we provided in BONDI as the starting point, in which there are some convenience functions, but it's still pretty simple. I'm also coming from the view that given the collective resources and group review that resulted in the BONDI API's (a good process, with valuable result), unless there's a clear reason to deviate, we should remain functionally consistent.

> 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.

> 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.

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").

Best regards,
Bryan Sullivan | AT&T

-----Original Message-----
From: [] 
Sent: Wednesday, October 28, 2009 7:59 AM
Subject: RE: [Device APIs Requirements] Input to Contacts API

Hi Bryan,

Since I'm actively working on the Contacts API, I've included some
thoughts below.

On 27th Oct 2009 at 05:44, SULLIVAN, BRYAN L (ATTCINW) wrote:
> * It MUST be possible to discover the supported fields for 
> Contacts entries.

OK. This can be done by enumerating over the resulting properties of a
Contact object:

for(var propertyName in myObject) {
   // propertyName is what you want
   // you can get the value like this: myObject[propertyName]

In BONDI this has its own API method: getSupportedPropertyKeys() but
this functionality could be easily be done at runtime by a webapp with
the above code.

So do we want/need a method? I'd suggest not.

> * It MUST be possible to clear a list of Contacts entries.

There may be ambiguity around the term 'clear' here. Perhaps you mean
delete/remove Contact(s) from an address book OR you mean clear
Contact(s) from the web app (i.e. nullifying the resulting
<sequence>Contact object(s) for garbage collection)?

If we're talking about 'delete' then this can currently be done by
passing the required Contact objects sequentially through the
addressbook.remove function.

If we're talking about 'clear' then this can be done in a web app with
the following code:

// throw the Contacts list away and create a new empty one
// (this method should also work for the well-documented poor 
// Garbage Collection of IE6. There are other ways to do this also.)
contacts = {};

> * It MUST be possible to clear all Contacts entries.

Same as 2.) above.

The use case of deleting all contacts should be so rare that I don't
think it warrants its own function. Sequentially deleting contacts
through addressbook.remove should suffice.

> Re "Are there convincing use cases for supporting multiple 
> address books in v1 (as opposed to just a default one, and 
> maybe exposing more later)?": Yes, there are convincing use 
> cases. It has been a standard feature in mobile phones for as 
> long as contacts have been a feature, that there is a 
> phone-based contact list and a SIM-based contact list. These 
> two address books, at least, should be supported.

I agree with this. For me, the outstanding question is to find a way to
allow web apps to identify individual address books: by name, URI, index
or reference, and make that meaningful enough to action by the code/user
of a web app.

I.e. * it MUST be possible to identify and target a specific address
book (e.g. the 'SIM' address book or the 'Device' address book) from a
web app.

This is of course still an open discussion.


Kind Regards,


Received on Wednesday, 28 October 2009 22:28:01 UTC