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

On Wed, Jan 19, 2011 at 12:28 AM, Suresh Chitturi <schitturi@rim.com> wrote:

> Below.
>
> -----Original Message-----
> From: DANIEL JESUS COLOMA BAIGES [mailto:dcoloma@tid.es]
> Sent: Friday, January 14, 2011 9:00 AM
> To: Rich Tibbett; Suresh Chitturi
> Cc: Frederick.Hirsch@nokia.com; public-device-apis@w3.org
> Subject: 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?
>
>
> Suresh>> Exactly, programmatic API is being implemented/adopted today as
> we speak, and providing a choice to developers makes sense rather than
> forcing the developers to rely on just a "download and save" option.
>

While I'm not really in favor of a programmatic API at this point, the way
forward is for someone to step up to take over the Contact Writer
specfication here:

http://dev.w3.org/2009/dap/contacts/Writer.html

The issues with write paradigms are well known in this group (e.g.
http://lists.w3.org/Archives/Public/public-device-apis/2010Jul/0112.html).
We did a lot of work over the last few months to arrive at a 'download and
save' model that works without overloading the asynchronous notification bar
concept of Geolocation. In fact, a definition of success for the Contact
Writer spec should be that it does not rely on an async notification method
of user interaction. It becomes messy quickly when a page tries to access
lots of device functionality simultaneously, all relying on such a
notification. That is not a case for policy frameworks but a bad design in
the first place.

If you feel like the Contacts Writer spec is the way forward, then perhaps,
Suresh or Daniel, you are willing to take over the editing of this
specification to document the programmatic write and save mechanism in a way
that works. I'm happy to let the market ultimately decide what works.

Does this sound like a good way to proceed on this?

- Rich


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