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

Hi,

   I would like also to understand how the Web approach would work in case
of bulk updates/additions (e.g. Contact synchronization, backup&restore).
Richard, could you provide some examples about that?

   We have also missed the capability to delete contacts, don't we? I
think we had that in the original set of requirements for this API and is
a feature that may be interesting for some apps.

  I do not have anything against the Web approach but I believe that we
should also try to standardize a programmatic API in addition to that. At
the end of the day, it would be beneficial for developers as some vendors
(Opera and Nokia amongst them [1], [2]) are already implementing that
alternative approach in different manners.

  Would you support that?

Cheers!

[1] http://labs.opera.com/news/2010/12/22/
[2] http://wiki.forum.nokia.com/index.php/CS001238_-_Adding_contact_in_WRT


De:  Rich Tibbett <rich.tibbett@gmail.com>
Fecha:  Fri, 14 Jan 2011 13:50:17 +0100
Para:  Suresh Chitturi <schitturi@rim.com>
CC:  "Frederick.Hirsch@nokia.com" <Frederick.Hirsch@nokia.com>,
"public-device-apis@w3.org" <public-device-apis@w3.org>
Asunto:  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.





Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra pol?tica de env?o y recepci?n de correo electr?nico en el enlace situado m?s abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at.
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

Received on Friday, 14 January 2011 15:05:14 UTC