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?)


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


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


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



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

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.

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