972000 - [meta] Import or access contact info from third parties

Status: RESOLVED WONTFIX

(Hello (Loop) :: Client, defect)

Comment 1

[Maire Reavy [:mreavy]]

Romain, Can you do the bug breakdown for this?  Please work with Niko, Abr, & Alexis -- and anyone else you feel you need to.

Comment 2

[Romain Testard [:RT]]

(In reply to Maire Reavy [:mreavy] (Please needinfo me) from comment #1)
> Romain, Can you do the bug breakdown for this?  Please work with Niko, Abr,
> & Alexis -- and anyone else you feel you need to.

Reviewed with Niko and TOkeshu - the current breakdown is enough for them

Comment 3

[Adam Roach [:abr]]

Attachment: Proof of Concept: CardDav Importer

Comment 4

[Adam Roach [:abr]]

This proof of concept is meant to demonstrate the architecture described at https://wiki.mozilla.org/Loop/Architecture/Address_Book#Importing

I've done some manual testing with this against the Google Contacts CardDav interface. Note, however, that the parsing in the proof-of-concept CardDav importer is quite rudimentary, and would probably need some cleanup before we would consider using it.

If you invoke the following code (with valid values for "user" and "pass") from the loop panel, you should see all the corresponding contact objects logged in the JS console:

  navigator.mozLoop.startImport(0,
    {
      service: "carddav",
      host: "www.google.com",
      auth: "basic",
      user: "[e-mail]",
      pass: "example-password"
    },
    function(id, contact) {
      console.log("New contact: " + JSON.stringify(contact));
      // This is where the panel code would store the contact in the IndexedDB table
    },
    function(id, err) {
      if (err) {
        console.log("Error:" + JSON.stringify(err));
      }
    }
  );

Comment 5

[Mark Banner (:standard8)]

Is there any particular reason the POC is in gecko space rather than content space? I don't see a need for it in gecko land.

Comment 6

[Adam Roach [:abr]]

(In reply to Mark Banner (:standard8) from comment #5)
> Is there any particular reason the POC is in gecko space rather than content
> space? I don't see a need for it in gecko land.

There are a handful of reasons:

1) I understand (from your note at Bug 972079 comment 7) that the Google Contacts API introduces some difficulties related to some cross-origin issues, and moving to gecko gives us much more room to maneuver. It seems quite probable that other services we choose to interface with may have similar properties.

2) For the specific conduit that I wrote -- which is proof-of-concept for now, but might be a valid approach if (a) we decide to have a generic CardDav importer or (b) the Google Contacts API proves to have some critical flaw -- the ability to send CardDav PROPFIND and REPORT requests from content requires the server to whitelist those methods (and the Depth header field) via CORS. And most don't (notably, Google does not).

3) Once we move on to importing things like native OS address books, the need for privileged access is pretty clear.

Comment 7

[Maire Reavy [:mreavy]]

Not needed for first release of FxA & contacts.  We broke off the piece of this meta that is needed.

Comment 9

[Mark Banner (:standard8)]

We are currently reworking the Loop "user journey" (bug 1209713) and as part of this direct calls and contacts are being removed. Therefore closing contact related bugs as wontfix.

Tracking id: contactuserjourneyclosing