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

Hi,

On 19.1.2011, at 1.24, ext Suresh Chitturi wrote:

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

I appreciate your focus on performance aspects, but I think we can overcome those.

I'd guess every native language and platform has a library for parsing and generating vCard and most address book applications out there support vCard import. Thus parsing is already well supported and performant.

For generating vCards, there exists many implementations in various languages, including JavaScript, both on the client-side and the server-side (mitigates the performance concern to some extend). In addition, writing Plain Old vCard Objects (POVOs!) by hand may also be feasible in most cases as demonstrated in the examples in the spec. Some libraries that may be helpful:

X2V (hCard to vCard, a bookmarklet and an XSLT stylesheet):

  http://suda.co.uk/projects/X2V/

H2V (hCard to vCard, a JavaScript library):

  http://h2v.1daylater.com/

hCard Parser (hCard to vCard, a Greasemonkey script):

  http://diveintomark.org/projects/greasemonkey/hcard/

Or the other way around from vCard:

vcardin (vCard to hCard, a Python script):

  http://www.w3.org/2002/12/cal/vcardin.py

These are just couple of examples I cherry picked from:

  http://microformats.org/wiki/hcard-implementations

I'd like to see creative web developers innovate on top of the existing building blocks first and roll their own save() API into JavaScript libraries instead of an option that we force them in using a standardized save() API which would limit their creativity (and for which we do not yet have a browser-based metaphor which is proven to work).
 
> 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.

Isn't the vCard format the only standard way to import contacts supported by nearly every address book app? Thus supporting it is pretty much a done deal, right?

Btw. the vCard export could be bolted on the current reader API, e.g. by adding a button "Export as vCard" into the picker:

  http://dev.w3.org/2009/dap/contacts/contacts_picker.png

I'm not suggesting we should do that, but just throwing that out for discussion :)

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

Perhaps we can never say a particular format works with *all* but I still think it's the best we got.

-Anssi

Received on Wednesday, 19 January 2011 12:11:37 UTC