W3C home > Mailing lists > Public > public-device-apis@w3.org > October 2009

RE: [Device APIs Requirements] Input to Contacts API

From: <richard.tibbett@orange-ftgroup.com>
Date: Thu, 29 Oct 2009 17:24:56 +0100
Message-ID: <355A518BC0575547B2A3D6773AAF8EEF59880F@ftrdmel1>
To: <BS3131@att.com>, <public-device-apis@w3.org>
Hi Bryan,

On 28th Oct 2009 at 10:27PM, 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.

The resulting Contact object is an Object and the code allows us 
to enumerate over the properties (the attributes) of an Object in 
the same way we can iterate over an associative array in other 
languages.

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

Good point. All properties should be provided in the response object, 
even if they are null. 

I will add some description of this to the current spec.

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

You know, if I'm adding a new Contact my initial logic falls down. I 
don't know what the supported attributes are until I have an existing 
Contact object from the AddressBook. That may therefore require us to 
include a getSupportedPropertyKeys() method to the API.

I propose to add this to the current spec.

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

Are the number of address book types finite? So far we have 'phone' and 
'sim'. I would add 'ext' to that list to identify 'other' address books.
If this is all then we can add a simple string attribute to the 
AddressBook object. 

If it's not finite or we want to add better address 
book targeting then perhaps we should look at URIs.


Thanks,

Richard

 
Received on Thursday, 29 October 2009 16:25:36 UTC

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