RE: Contacts API concerns (RE: Draft minutes, 2011-01-15)

Hi Rich, all,

 

Please see below.

 

Regards,

Suresh

 

From: Rich Tibbett [mailto:rich.tibbett@gmail.com] 
Sent: Friday, January 14, 2011 6:50 AM
To: Suresh Chitturi
Cc: Frederick.Hirsch@nokia.com; public-device-apis@w3.org
Subject: Re: Contacts API concerns (RE: Draft minutes, 2011-01-15)

 

On Fri, Jan 14, 2011 at 1:04 AM, Suresh Chitturi <schitturi@rim.com> wrote:

Hi Frederick, all,


Here are the concerns I was trying to raise during the call (but could
not record them in IRC due to server issues:

1) The proposed contacts API draft does not offer a programmable JS API
for saving and updating contacts. Having a standard API (with e.g.
Contact.save() method) provides the benefit of being more efficient

 

Why is a save() API 'more efficient'? (and what does 'more efficient' mean in this context?)

 

Suresh>> what I mean by efficient in this context is that calling on an JS object with a single save operation is much more performing compared to implementing vcard encoder in the script, decoding iit and converting it back to the a native address book format (which is many cases support a non-vCard format).

 

 and agnostic to the underlying format the implementation as we do with the
 read API.

 

The proposal has nothing to do with the underlying format of the implementation. 

 

Suresh>> I think it does. With the current reader API, we do not expose the underlying format i.e. everything that is returned is in the format that we have defined but with “download and save” option we require the implementations to deal with the vCard MIME and convert to native formats.

 

 
 I do not have an objection to the approach in principle, but in my view
 it is weak and should not be shown as the replacement to a "save" API.

 

Please define 'weak'. What are the benefits of a "save" API versus a web platform model?

 

FWIW, the current model, integrated in to the web platform of today, adds a number of benefits over any API approach we could ever come up with:

 

- It's backwards compatible. Web developers can start using vCards in their work without the need to check UA support. All systems already have a fallback application with which to save vCards.

- It's simple - no additional APIs needed.

- It reuses existing paradigms ("download to save data").

- It side steps the issue of prompting the user per 'save' operation, at the discretion of the processing application and/or the preferences of the user in that application.

 

Suresh>> Again, you are assuming that all implementations are vCard friendly, and this is not the case with evolving formats such as PoCo and CAB, so tying our solution to a single format is not a good idea. Having it as an example is fine but it is not guaranteed to work with all the native systems/services unless a conversion takes place and it can be lossy in some situations.

 

I’m afraid the “download to save” model will lead to the same user experience if we had a good permissions model and user prompts for saving the contacts through the “save” API. In both cases you are rely on dialogs/prompts and user preferences.

 

 My proposal is to reword the text to state that this is purely
 informative in nature in the spec, and address the write-back
 functionality through a standard API which is what we set out to do in
 this group.

 

This section consists of two SHOULD requirements. The definition of SHOULD according to 'Key words for use in RFCs to Indicate Requirement Levels' [1] is as follows: 

 

"[SHOULD] means that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course."

 

To be compliant a UA does not have to implement these requirements, though the risk of not implementing these SHOULD requirements must be clear to the implementer (i.e. you won't have any save or update functionality).

 

This is not hypothetical or 'purely informative in nature'. We're making real solutions for real UAs here and if they choose to follow SHOULD requirements then that is their call. The syntax as provided in the spec should be fine as-is.

 

Suresh>>  As far as I understood, the resolution was to provide an example in the Appendix, and not to use normative language to specify this behavior. Like I said in my other mail, I’m fine with the approach in principle but would like this be only a workaround in the first version of the API while we continue to work on programmatic API for later releases.

 

Overall, the key question I would like you to respond to is: What does a programmatic API provide over the web platforms method proposed?

 

Suresh>> What I’m looking for is a tighter integration between the web application and the device functionality through a programmatic API, and that does not rely on external scripts to do the encoding and force the UA to store them “out of band” while all this could be achieved through a single API call.

 

Considering that you are suggesting a different PROCESS with the same INPUT and expected OUTPUTS it's hard to wrap my head around why a Javascript API would be so great when we've arrived on a much more web-integrated proposal that acheives the same output whilst also providing a number of additional benefits (see above) over any programmatic API method we could ever come up with.

 

One solid use case will do.

 

 

Suresh>> please see above.

 

- Rich



-----Original Message-----
From: public-device-apis-request@w3.org
[mailto:public-device-apis-request@w3.org] On Behalf Of
Frederick.Hirsch@nokia.com
Sent: Wednesday, January 12, 2011 10:26 AM
To: public-device-apis@w3.org
Cc: Frederick.Hirsch@nokia.com
Subject: Draft minutes, 2011-01-15

Draft minutes from today's call 2011-01-15. Due to networking issues
some of the material at the end might have been lost, please review.

Thanks to Claes for scribing. HTML follows text.

regards, Frederick

Frederick Hirsch
Nokia


---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

 


---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.