Closed Bug 859306 Opened 11 years ago Closed 6 years ago

Sync contacts with carddav

Categories

(Firefox OS Graveyard :: Gaia::Contacts, defect)

Product:
Firefox OS Graveyard
Component:
Gaia::Contacts
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(tracking-b2g:backlog)

Status:
RESOLVED WONTFIX
Project Flags:
tracking-b2g backlog

People

(Reporter: atopal, Unassigned)

References

Details

(Keywords: feature, foxfood, Whiteboard: [u=commsapps-user c=contacts p=0][priority][SUMO-b2g])

Attachments

(1 file)

DataStore provider for CardDAV using jsDAVlib
46 bytes, text/x-github-pull-request
frsela
: feedback?
arcturus
Details | Review 
As a user I'd like to sync my contacts with a neutral provider (not Google, Facebook or Microsoft). It seems like CardDAV is the way to go here. The CardDAV protocol has been standardized by the IETF and published as RFC 6352.

There are many competing CardDAV implementations and a number of open and closed sourced companies support it for syncing contacts data. Among them: Apple, Zimbra, Blackberry.

Since I could only find a bug for Thunderbird, but not for Firefox OS, I'm filing one. Are there already any plans to support this in feature releases?
Hi,

I really would like to implemente this, CardDAV is definitely the way to go, but AFAIK is out of the scope for versions 1.0.1 and 1.1

Anyway, nice to have this to track it :)
Hello, I met lot of difficulties to find any roadmap or changelog about Firefox OS. I don't even know at which version is the project (most of the public documentation related to this is just dead since one year).

Anyway, on this page http://support.mozilla.org/en-US/kb/getting-started-firefox-os#w_syncing-contacts-between-phones-and-importing-facebook-friends I can read "Syncing contacts between phones": if I follow the link, the only way to synchronize contacts is with... Facebook?!

Thanks to Owncloud, I'm very *very* interested in sync my contacts using CardDav on Firefox OS. Could you say me for when it's planned please?
See https://wiki.mozilla.org/Gaia/Contacts and particularly https://wiki.mozilla.org/Gaia/Contacts#Gaia_v2 ... unfortunately it seems CardDAV is not scheduled at all. :(

And when somebody says "bug for Thunderbird", it would be awfully nice to mention which exact bug it is. In this case, bug 546932.

I wonder, whether this bug doesn't depend on bug 546932 actually.
See Also: → carddav
(In reply to Matej Cepl from comment #3)
The See Also is important :)
+1

Want to buy a Firfox OS Device (Geekphone) and need to Sync via Carddav and Caldav Thunderbird 17 to this device.
Isn't this a duplicate of Bug#546932 ?
Radix, no, that bug is for Thunderbird, this one is for Firefox OS.

Matej, how are Firefox OS bugs dependent on Thunderbird bugs?
(In reply to Kadir Topal [:atopal] from comment #7)
> Radix, no, that bug is for Thunderbird, this one is for Firefox OS.
> 
> Matej, how are Firefox OS bugs dependent on Thunderbird bugs?

I thought that the Firefox OS will use code from now-hopefully-being-developed new Contact module for TB. Or other way around, that Firefox OS will finally force MoFo folks to deal seriously with CardDAV. But anyway, I thought that the code is shared.
blocking-b2g: --- → koi?
Blocks: koi-comms
blocking-b2g: koi? → ---
Whiteboard: [u=commsapps-user c=contacts p=0]
Blocks: comms_backlog
No longer blocks: koi-comms
I would like to take time here to think about how to tackle this problem in a way that will allow us to scale.

Sync is a *BIG* thing, and if we do something shouldn't be just for CardDav, we should try to do something like we did for import/export, allowing multiple sources.
(In reply to Francisco Jordano [:arcturus] from comment #9)
> Sync is a *BIG* thing, and if we do something shouldn't be just for CardDav,
> we should try to do something like we did for import/export, allowing
> multiple sources.

Don't we have already syncing for CalDAV, which is as I understand similar technology as CardDAV? Why not to use parts of the code (is it in https://github.com/mozilla-b2g/caldav/ ?) for CardDAV as well?
>Don't we have already syncing for CalDAV, which is as I understand similar technology as 
>CardDAV? Why not to use parts of the code (is it in https://github.com/mozilla-b2g/caldav/ ?) 
>for CardDAV as well?

WebDAV based sync is basically simple, and much of the code should be portable.

PROPFIND collection
  - check etags
  - retrieve unknown/new objects from server (either REPORT or GET)
  - retrieve changed objects from server (either REPORT or GET)
  - PUT new client objects to server
  - PUT modified client objects to server

So it is quite simple to DO, but to DO WELL is more complicated.  A user needs to be able to provision the account, which if the server supports well_known (RFC5785) is again pretty easy, but not all do.  So you have the tedium of a configuration UI for accounts.  And then the really hard part is a good sync agent needs to deal with conflicts, implement a conflict policy.  What if both the object on the server and the object on the client changed?  Not a problem if the client collection is read-only, but nobody wants that.
(In reply to Radix5 from comment #11)
> And then the really hard part is
> a good sync agent needs to deal with conflicts, implement a conflict policy.
> What if both the object on the server and the object on the client changed? 

Which I hoped was somehow resolved in the CalDAV support.
this is really a must have. I thonk paranoid alu-head-hackers (like me) will be a big customerbase for ffOS. Can't be hard to implement.
(In reply to vondemleschker@hotmail.com from comment #13)
> Can't be hard to implement.

We take patches ;)
 
> We take patches ;)

not my area of expertise, but i will definitly look in it. Is there a documentet way/Api for implementing more contact sources? Haven't yet had the pleasure to mess with ffOS (and this issue is quite a blocker for starting).
There is a project underway to replace the Address Book component of Thunderbird, and CardDAV is one of the main methods they're working on. I'd be surprised if the project wasn't applicable to B2G, as well.

You can find more information about this by reading through recent Thunderbird Status meeting minutes.
Francisco, are you guys still doing 1.3 planning?  Do you think this will make it?  Or is this more a 1.4 or later thing at this point?
Flags: needinfo?(francisco.jordano)
*sigh* I wish this had been the architecture from the very start. I *assume* the Calendar uses CalDAV, right?

But I won't dwell on any further; if you're looking for an übersimple WebDAV/ CardDAV server to write and test against, please check out https://github.com/mikedeboer/jsDAV. It's a robust NodeJS implementation which supports multiple storage backends.

You can also just do `npm install jsdav`.

That concludes my </advertisement>. Good luck implementing this feature.
Hi,

Unfortunately, is not planned for 1.4 :(

Pinging Wilfred to track this request, also contributions are welcome :)

Cheers,
F.
Flags: needinfo?(francisco.jordano)
Flags: needinfo?(wmathanaraj)
On comment 19, I meant not planned for version 1.3, and we should ask Wilfred to check the scope for future versions :_)
v1.3 is closed and v1.4 is filling up quickly. 
I will take it into the backlog and discuss for v1.4+ planning.
Flags: needinfo?(wmathanaraj)
I thought I would be able to synchronize my Firefox OS phone with my contacts on ownCloud through CardDAV. I'm disappointed that it will take so much more time for an open standard like CardDAV to be supported, especially because Mozilla values the open web and privacy so much.

Sure, the majority of Firefox OS users will probably have no qualms with synchronizing their contacts from Facebook and throwing their privacy out of the window, but if there is no privacy-friendly alternative I think Mozilla has it's priorities wrong. I'd expect Mozilla to embrace alternatives like support for ownCloud. I guess I'll have to enter all contacts on my phone manually until CardDAV synchronization is implemented.

According to the roadmap the first release after 1.4 will be in the end of May 2014, so we'd have to wait at least half a year until this feature might be implemented! I'd appreciate it very much if this could still be included in the 1.4 version.
I just want to add my voice to the idea that we should see this feature included as soon as possible.
A Fx OS device is on its way, so if this feature is not implemented in the near future I will most likely take a stab at it. (If that is not at all inconvenient for anyone!)
What is current status of this work?  Scheduled?  Considered by our FirefoxOS product friends?
I was thinking about this the other day and it seems that there may be an interim solution even if CardDav does not make it into core OS for 1.4.

It may be easier/quicker to develop a standalone app that provides CardDav sync'ing.  The contacts and socket APIs are available to privileged apps, so it seems like it should be doable.  It may also be easier to experiment with 3rd party code that exists to slap something together in this environment without going through the process of integrating with the core Contacts app.

A proof-of-concept like this might also make the integration with the core apps easier down the line because we could see what works or doesn't work.

Just a thought in case someone wanted to experiment with that approach.
What Ben comments is the same process that we followed with other features like import from different services.

They were 3rd party apps (done by contacts developers), that after some rework and showing to the product guys that are useful were integrated into the product.

So I would go as well for a PoC first.

Cheers,
F.
Assignee: nobody → frsela
Talk to mconley about Ensemble.
:bkelley fantastic implementation / PoC approach!
As was said before: The complete conjunction between owncloud and FirefoxOS is an important feature as the competitors from google, apple and ms can already offer apps or built-in support and furthermore FFOS could represent a real alternative to big data companies. Maybe a cooperation with owncloud would generate profit for both projects ...
I use ownCloud and would be very useful to use carddav with Firefox OS. I'm using Peak, and had to import the contacts using a external app, but can't sync. Facebook is a proprietary service, and I prefer to use my own "ownCloud".
CardDAV is make or break feature for me. I love my N9, but I switched over to a second hand Galaxy Nexus (Android) just to get carddav support. The N9 also has CalDAV but I rarely use a calendar. Having my contacts in sync with my webmail service and Thunderbird is essential to me.

Even though pure Android 4.3 has really matured into a great mobile OS, I just can't stand the ramming of Google cloud services down my throat anymore. And endorsing a Nestle product in such a way is just too much. Nestle is an evil company, does this signify the point where the once "Don't be evil" company is joining the ranks. I hope not.

Anyways; please, please, please support CardDAV, these open standards are so important!

I am currently considering a Jolla phone (1st choice) but if getting hold of one is difficult right now. Firefox OS would be my next choice, but it needs CardDAV support before I consider.
Hi all,

well, I am one of the many out there who is looking for great software being independent of the big players. I like Android, but I dont want Google (too much proprietary code parts). Ironic? Yah! Thats why I am looking for Firefox OS.

To make Firefox OS supporting open standards, I would like to have CardDav for contact sync.

Thank you guys!
I love the support and enthusiasm in this bug.  For what it's worth, our team (cloud services) is extremely interested in prototyping this out in the coming months.  Anyone who wants to participate, please contact me or jed parsons, or add a comment to this bug.

<3,
lloyd
(In reply to Lloyd Hilaiel [:lloyd] from comment #34)
> I love the support and enthusiasm in this bug.  For what it's worth, our
> team (cloud services) is extremely interested in prototyping this out in the
> coming months.  Anyone who wants to participate, please contact me or jed
> parsons, or add a comment to this bug.
> 
> <3,
> lloyd

Hi Lloyd,

the contacts team has an eye on this as well.

Our current idea is to evolve the contacts app to be able to accept contacts from different sources. And those different sources could be totally independent from the contacts app itself.

That's why we decided to follow with the same way we did the gmail integration, create a third party app, check how it works and get feedback from people, and once it works perfectly we integrate into the main gaia core. So far Fernando, assigned to this task, decided to follow with that philosophy.

In our side, we have been involved with FxA, and of course we are pretty happy to help to that prototype too :)  \o/

Cheers,
F.
+1 to comment 26 and 27 for PoC implementation approach

Francisco, so great to hear that you and Fernando are working on this!  Are there any relevant bugs you can point me to for more backstory and maybe patches in progress?  I'm keen to begin helping out as soon as possible.
Flags: needinfo?(francisco.jordano)
(In reply to Jed Parsons (use needinfo, please) [:jedp, :jparsons] from comment #36)
> +1 to comment 26 and 27 for PoC implementation approach
> 
> Francisco, so great to hear that you and Fernando are working on this!  Are
> there any relevant bugs you can point me to for more backstory and maybe
> patches in progress?  I'm keen to begin helping out as soon as possible.

So far is just this bug, Fernando will provide more information here I guess, as he is assigned to it.
Flags: needinfo?(francisco.jordano)
(In reply to Francisco Jordano [:arcturus] from comment #37)
> (In reply to Jed Parsons (use needinfo, please) [:jedp, :jparsons] from
> comment #36)
> > +1 to comment 26 and 27 for PoC implementation approach
> > 
> > Francisco, so great to hear that you and Fernando are working on this!  Are
> > there any relevant bugs you can point me to for more backstory and maybe
> > patches in progress?  I'm keen to begin helping out as soon as possible.
> 
> So far is just this bug, Fernando will provide more information here I
> guess, as he is assigned to it.

Hi, yes, as Francisco said, I'm currently creating the library to manage CardDAV and by extension WebDAV.

I hope I can show something along next week, but all depends in the daily workload. I'll maintain you informed ;)

Regards.
(In reply to Fernando R. Sela (no CC, needinfo please) [:frsela] from comment #38)
> Hi, yes, as Francisco said, I'm currently creating the library to manage
> CardDAV and by extension WebDAV.

Great!
Hi Fernando,

Oracle has a public, CardDAV test server if you're interested in testing your implementation. I'm at a CalDAV interop event right now, so let me know :)
Flags: needinfo?(frsela)
(In reply to Gareth Aye [:gaye] from comment #40)
> Hi Fernando,
> 
> Oracle has a public, CardDAV test server if you're interested in testing
> your implementation. I'm at a CalDAV interop event right now, so let me know
> :)

Oh, that sounds really interesting !

I'm testing with DAVMail & ownCloud (based son SabreDAV). Other implementations are allways usefull to assure interoperability.

Thanks !
Flags: needinfo?(frsela)
Blocks: 970423
I just want to add my vote to implement CardDAV
(In reply to Sergio Bernal from comment #42)
> I just want to add my vote to implement CardDAV

If you want to vote for this bug, please click the "vote" link next to "Importance" near the top of the page, instead of posting a comment.
It's a shame to let the users to fix this feature request and wait so long time, when I can't stop hearing Mozilla to claim that they protect our private life. FACEBOOK is the only choice offered to the user, NO ALTERNATIVE is set in the Gaia::Contact app, is it a joke? See also the Notes+ official note application where the Evernote provider is the only way to sync our private informations.

Mozilla is not able to protect our private life if any app give an unique and only choice to store directly our data in USA servers under Patriot Act and controlled by the NSA. It's a funny joke.
100% agree. weird sense of dev priorities.
When I saw the first time, It was also weird to me. I don't use Facebook.
blocking-b2g: --- → 1.4?
Triage: new feature so adding it to backlog
blocking-b2g: 1.4? → backlog
I'd like to mention that any implementation, when ready, should be tested against SOGo. It's a great groupaware solution providing CalDAV and CardDAV. SOGo works well with iOS and the Android app; CalDAV-Sync and CardDAV-Sync by Marten Gadja, and CalDAV Sync Free Beta by gege. Also, SOGo supports Thunderbird as it's primary client, infacg the webmail is a clone of Thunderbird UI.

SOGo website: http://www.sogo.nu/

I am willing to setup a testing account on my SOGo server if need be.
I am more than willing to participate in the UX and implementation of this. Now of only I get chosen to get a Firefox OS tablet! :D
+1 
Would love to se support for Owncloud
+1 for SOGo testing
No user of my company can use an smartphone without cal/card-DAV.
How can we use a phone to call people without contact, and how can we have contacts with privacy if there's only facebook sync.
Please hel us and yourself, integrate cardDav.
Or launch a Crowdfunding to collect the money and pay a dev for it (badly bugzilla don't have this feature).
They have enough developers, it's just not in their priorities. They don't care about the community, even the most requested bug stays unanswered for a year.

I guess they'll do it once Facebook, Google and Microsoft services will be fully integrated. Perhaps is there too much Windows & Mac developers to understand the politic guideline promoted by the Commercial Service.

We can't expect this feature to be added in a future release before one other year anyway. And two before it come in the stable OTA releases. I'll be far away from the Firefox OS universe at this point, Ubuntu Touch will have an native access to script this, if not already in the repositories.
It seems like this is not a priority, but it's not true that Firefox OS has enough developers, otherwise this bug would've been fixed already. As was suggested before, if there are developers interested in this, they can develop it as an add-on and it can be integrated into Firefox OS proper. The same was done for the Gmail-sync.

Also, Fernando said he was working on this already, so you might want to check with him on the progress of that work.
(In reply to Vincent from comment #53)
> They have enough developers, it's just not in their priorities. They don't
> care about the community, even the most requested bug stays unanswered for a
> year.

I am not agree with it. 
It's free software, if you don't like something in a software you could make a fork. But a lot of users, like me, don't have the knowledge for it. A crowdfunding feature in bugzilla (feature similar bug 124096) show to Mozilla that users are ready to pay. And we know that Mozilla try to find alternative sponsor (Google is too big).
blocking-b2g: backlog → 1.4?
This still isn't a blocker.
blocking-b2g: 1.4? → backlog
Whiteboard: [u=commsapps-user c=contacts p=0] → [u=commsapps-user c=contacts p=0][priority]
Hi Fernando! Can you give a status summary of where this project is?

Is the "Current Status" section of https://github.com/frsela/jsDAVlib correct?

We would love to have others jump in and help finish jsDAVlib and Firefox OS integration, but need to know where it's at first.

Thanks!

-d
Flags: needinfo?(frsela)
(In reply to Dietrich Ayala (:dietrich) from comment #59)
> Hi Fernando! Can you give a status summary of where this project is?
> 
> Is the "Current Status" section of https://github.com/frsela/jsDAVlib
> correct?
> 
> We would love to have others jump in and help finish jsDAVlib and Firefox OS
> integration, but need to know where it's at first.
> 
> Thanks!
> 
> -d

Hi Dietrich,

Other important topics and bugs collapsed my time :(

I had some (near finished) work to use the library in a FFOS client (Independent client, no integrated in contacts) I hope this week I had some time to finish it.

Also, some test on jsDAVlib to assure it works with all webdav servers could be great.

Regarding the library, is all pushed. I've to update the README.md since now is read-write and not read-only ;)

If you've someone who can help to move faster (integrate with the contacts app) could be great.

As told before, I *want* to work on this :) Hope this week is more "relaxed" and have time to work on this topic :p
Flags: needinfo?(frsela)
Are there some news in the progress?
Finally I found a bucket of time to implement the datastore importer using the jsDAVlib.
Attachment #8436952 - Flags: feedback?(francisco)
I started working on a rewrite of the caldav library we use in calendar here (https://github.com/gaye/davinci.js), and :evrt from fruux approached me about generalizing some of the code I'm writing to speak carddav. The project is very "young", but I think that in terms of code sanitation, it has a good base to build off of. There are currently integration tests that run (quite nicely : ) against fruux's sabredav dav server. :evrt and I are thinking of exposing some of the lower-level apis so that it would be easy to build a carddav library on top of the existing xhr, parsing, and templating facilities.

Thoughts?
https://github.com/gaye/dav is now past it's 1.0 release and has support for all sorts of carddav goodness. We talked a bit about it yesterday, but it would make me super happy if you all could take a look at what we're using in calendar and perhaps use and contribute.
Flags: needinfo?(frsela)
I'll take a look asap. Thank you
Flags: needinfo?(frsela)
Hi there I am new to all this stuff, how can I install the code mentioned above? Did I oversee any documentation for this?
If you don't know how to use the patches attached to this ticket, you should probably first start hacking on Gaia. See https://developer.mozilla.org/en-US/Firefox_OS/Developing_Gaia for more info about hacking Gaia.
Hi!

I'm interested in this too. Is there any POC already for a carddav sync app? Otherwise I way well start one on my own, but I'd be happy to either use or contribute to any existing effort.
Alright guys, I started a little something.

There's not a lot to show off with right now, just a bunch of checkboxes and text. But if you want to join the effort, here's the github repo: https://github.com/aspyct/FireCards

I'm using Angular and the CardDav library listed above (https://github.com/gaye/dav).
(In reply to Antoine d'Otreppe from comment #69)
> Alright guys, I started a little something.
> 
> There's not a lot to show off with right now, just a bunch of checkboxes and
> text. But if you want to join the effort, here's the github repo:
> https://github.com/aspyct/FireCards
> 
> I'm using Angular and the CardDav library listed above
> (https://github.com/gaye/dav).

Thanks for your efforts, Antoine :). But looking at the PR there seems to be an app provided in the patch to test the feature. It's in dev_apps/contacts-ds-provider-3/. I would suggest, however, that instead of building a complete new app, you try to hack around in the Gaia Contacts app to make use of this new CardDAV DataStore :)
Oh, I didn't realize. Thanks for the heads up! Good news then, although I did enjoy this project.
I'm not sure the best place for contacts sync is in contacts. On Android, for instance, I think separate apps interact with the contacts api to sync your contacts. I know that the services/sync team has been thinking a lot about where this stuff should live.
I do agree with :gaye, IMHO, that should leave in a separate app.
(In reply to Francisco Jordano [:arcturus] [:francisco] from comment #73)
> I do agree with :gaye, IMHO, that should leave in a separate app.

I'm not shure about that if one person has multiple accounts (like gmail and owncloud) and therefor multiple syncapps there could be undefined behaviour(eg if the data changed on both remotes). One sync-app could handle such cases much better.
I guess that a separated app is a wrong idea because users should dispose of the powerful of Web to sync their contacts. Few lambda users know that they can sync their contacts.

In addition, a separated app has lot of chances to be abandoned one day, and won't be maintened for new APIs.

Facebook's sync should have been put outside Gaia if it was the correct solution, right?
I agree with :Gaye, i  think separated apps is much better for synchronization services. One app can provide one or many mechanisms, and competition will make the best apps get more exposure
I don't think the final user cares about implementation. Instead of many apps, as said vondemleschker, it'll be more effiscient and user friendly to see all possibilities at the same place.

The more people will contribute, the better will be the code.
I also think solutions can compete and best will make it into gaia in the end.
But besides - are you aware that there is work in progress regarding carddav in the gaia-contacts-sync? See https://github.com/mozilla/gaia-contact-sync/search?q=carddav&type=Code
Do I misinterprete this snippets? Else we should avoid make efforts double, ain't we?
As a non-android-spoiled user, I prefer to have the sync options regarding a specific app in one place, which would naturally be the app itself (although I guess most people could live with the option being in preferences as well). 

I think of this looking kind of like the calender sync - multiple sources, each contact coming from a specific source marked somehow (e.g. color spots), all controllable via the frontend app. I'm pretty sure having non-system apps for contact sync would be highly confusing especially to new users.

This way contact sync would also be consistent with how the calendar app handles calDAV. Feels more natural.
See Also: → 1019787
There's a related PR at https://github.com/mozilla-b2g/gaia/pull/20235 . The repo linked in https://bugzilla.mozilla.org/show_bug.cgi?id=859306#c78 doesn't seem to be around any more, though.
Wilfred, we should advance on this popular topic. Do you know the current state of the new proposal we talk before summer?
Flags: needinfo?(wmathanaraj)
As asked here : https://support.mozilla.org/fr/questions/976531
I vote for a support of CardDAV protocol in COntacts for future release of FirefoxOS.
Thanks !
+1 I really need this as well !
Please note: to express support for this feature request, please use the "vote" feature instead of posting a comment. You can find "vote" at the top of the page next to "Importance."
+1 this is a need. Don't want google to mess with FFOS
there are some re-planning going on at the moment. I will bring this subject up again for a release and see if we can move this forward quicker.
Flags: needinfo?(wmathanaraj)
FYI, I just bought the app CardDAVSync for 1.89€ in marketplace which perfectly synced my owncloud-contacts with the addressbook. So the job doesn`t seem to be impossible. Maybe the service will be done by FFOS itself sometimes but for now this is my solution for everyday use of my FFOS-phone.
Now I only lack sth like TextSecure and I would finally kick Android devices to bin.
I cannot found the CardDAVSync app in the marketplace (maybe it's because of the same non-working search engine than the one used on devmo). Could you provide a link? I'm very interested by this app if it exists. Thanks in advance.
Flags: needinfo?(maste9)
Can.'t copypaste a link but I  must add that sync only works one-way from server to device yet. And I use FFOS 2.0, maybe that's why you don't find it?
Flags: needinfo?(maste9)
I run FFOS 1.3 and can see it. Maybe it's a region problem?!
I don't think it's linked to an OS version:
* I can't see it in the Firefox Marketplace (even on a PC)
* I use 2.2
Could be a regional problem, since I don't think payments are enabled everywhere.
Maybe if you're not in one oh these countries, you can't see the app
https://developer.mozilla.org/en-US/Marketplace/Monetization/App_pricing
As of me, I am not, and I don't see no apps in the paid category:
https://marketplace.firefox.com/search?q=%3Apaid
maste9@gmail.com: thanks for pointing me to the app, that was 2€ well spent!

etienne.deparis@umaneti.net, dp@imaccanici.it: take a look at https://developer.mozilla.org/en-US/Marketplace/FAQ and the question "How do I access the Firefox Marketplace debug settings?". You'll find a way there to change your country. After that, I was able to purchase...
(In reply to dp from comment #92)
> Could be a regional problem, since I don't think payments are enabled
> everywhere.

That kind of sucks ... given that T-Mobile in Czechia sells FxOS phones (https://www.t-mobile.cz/telefony/detail-zarizeni/-/zarizeni/Alcatel/ALCATEL.ONETOUCH.FIRE.E/PO18220/?preferInstallmentPayment=true) it is unfortunate that I cannot pay here (no, I don't have that Alcatel but Flame).
Ok, it's definitely a regional problem. It seems that we, french, cannot spend our € on the firefox marketplace. Thus I'm now a proud german citizen ;) Thank you very much for your help and show me the :debug tip.
BTW, https://github.com/mozilla-b2g/gaia/pull/20235 needs to get probably rebased and reapplied.
https://github.com/mozilla/gaia-contact-sync/ has been deleted.

What are the plan now? Do we have a wiki page summarizing that stuff?
I guess we should continue tu use Android until this feature is added...
This is a deal-breaker for me. I've patiently been waiting for over a year now to have this feature in FxOS. Yet there are over 200 votes on this bug and literally _nothing_ happened for one and a half year. Instead, development seems to focus on 'cool and flashy' new features.
I've been quite an endorser of FxOS among friends and the internet. I still think the general approach Mozilla is taking here is valuable. I just wonder why the focus is off so much. 
If this isn't going to be in 2.2, I'm out.
(In reply to etienne.deparis from comment #95)
> Ok, it's definitely a regional problem. It seems that we, french, cannot
> spend our € on the firefox marketplace. Thus I'm now a proud german citizen
> ;) Thank you very much for your help and show me the :debug tip.

BTW, this doesn't work in Czechia ... when trying to buy a software, I get a new window with "Loading ..." status and it never changes.

Why does Mozilla hate developers for its platform so much?
I work with a primarily business communications oriented user base that would be very interested in transitioning to the FFOS platform as a light-weight, secure, open source alternative. I have identified 6 key features, in relative order of importance, that I believe are essential to this use case. Of the 6, only 2 are currently lacking and CardDAV support is one of them. In my opinion, making the platform viable for business use would greatly help the project in terms of support and funding.  Does anyone else agree / disagree with any of this?

1.  Full disk encryption (currently lacking)
2.  Basic voice and data capabilities (existing)
3.  IMAP / SMTP e-mail client (existing)
4.  CalDAV calendar sync support (existing)
5.  CardDAV contact sync support (lacking)
6.  Modern web browser (existing)
(In reply to adam from comment #101)
> I work with a primarily business communications oriented user base that
> would be very interested in transitioning to the FFOS platform as a
> light-weight, secure, open source alternative. I have identified 6 key
> features, in relative order of importance, that I believe are essential to
> this use case. Of the 6, only 2 are currently lacking and CardDAV support is
> one of them. In my opinion, making the platform viable for business use
> would greatly help the project in terms of support and funding.  Does anyone
> else agree / disagree with any of this?
> 
> 1.  Full disk encryption (currently lacking)
> 2.  Basic voice and data capabilities (existing)
> 3.  IMAP / SMTP e-mail client (existing)
> 4.  CalDAV calendar sync support (existing)
> 5.  CardDAV contact sync support (lacking)
> 6.  Modern web browser (existing)

I agree. I am building a business around helping people to use the Internet privately. There is no perfect solution, but if privacy becomes a priority again for people it will again also have to become a product consideration as well. The FFOS phone is one I am watching in the hope I can add it to our list of recommended products. I can't add it until it supports CARDDAV. I would change your list as follows:

1.  CardDAV contact sync support (lacking)
2.  IMAP / SMTP e-mail client (existing)
3.  CalDAV calendar sync support (existing)
4.  Modern web browser (existing)
5.  Full disk encryption (currently lacking)
6.  Basic voice and data capabilities (existing)

But then my list reflects more of a general populace priority list. I think the reasoning still stands fairly well for business though.

1) Because CARDDAV compliments the core function of a phone... making calls.
2) The next most common thing I see people do with their phone is sharing files/photos.
3) Calendaring is a must and highly necessary feature, though I don't see as many check their calendars on their phone as I do see sharing fiels and photos.
4) Yes browser is essential, possibly in the #3 slot. A browser can make up for missing apps.
5) This is very important, but falls below everything else because there's no point spending time encrypting a phone that nobody will use because it is feature poor.
6) My emphasis here is on voice to mean "voice commands." I see few people using this feature and they look as awkward as they seem to feel using it as well.
Please guys :
- Vote on the bug.
- open a bug for each feature you need/want/think would be cool (don't be shy :-) )
- but DON'T discuss that here. This is not the place. 

It really clutters this bug which is for cardAV support only. I'm also interesting in this support and I seriously consider starting to work on this. But the amount of irrelevant comments just means I need *at least* 2-3 hours to get through the full history to get started, see what's going on, what is already done. And I delay it every time, seeing the amount of spams I need to read. And that's not all. If a dev start to work on that, it means a reviewer will need to go through everything as well. This will further delay the reviewing process. Please consider that a full implementation will require at least 100 more comments between devs and reviewers... Only voting is useful.

Seriously. Please Vote. Forget the "I want it" comment. Thanks a lot!
Just to add that for discussion there is https://groups.google.com/forum/#!forum/mozilla.dev.gaia and there are tons of bytes you can write there before their bitbucket fills up.
In the spirit of encouraging open discussion and preventing cluttering this bug report, I have written a post on Reddit:

https://www.reddit.com/r/FireFoxOS/comments/2jw2j5/carddav_sync_for_contacts_now_has_245_votes_why/

I encourage anyone interested in making this happen to go there and comment / upvote / share as deemed appropriate.
Also let me add here a reference to https://github.com/mcepl/testing_carddav_provider which is reformulation of https://github.com/sanpii/gaia/commit/74120c9c373478d8b9af18d480b02db830c4df70.patch as a standalone privileged application (so for one, we had to switch to Contacts API as Datastore API requires certified app as so it is useless outside of Gaia itself).
For tracking purposes -
Another user is requesting this issue in the SUMO forums: https://support.mozilla.org/en-US/questions/1030755
See Also: → https://support.mozilla.org/en-US/questions/1030755
Whiteboard: [u=commsapps-user c=contacts p=0][priority] → [u=commsapps-user c=contacts p=0][priority][SUMO-b2g]
Are there any news in the integration of carddav?
Hey hozltest

I've planned to have a look at it in the following two weeks.
I found this app on the market :

https://marketplace.firefox.com/app/syncdav
https://github.com/tuxgasy/SyncDav

This may interest some people here.
Yes, this app works, but only one way.

This app is now also free :)
https://marketplace.firefox.com/app/carddavsync
Yes but this one doesn't seems to be open-source :-/

So you don't really know what it does with your contacts and password. And people interested in development here can't help to add features (like two-way sync) or inspire themselves by it to make a native implementation in FFOS or another better app.
blocking-b2g: backlog → ---
tracking-b2g: --- → backlog
No longer blocks: comms_backlog, comms_2.0_targeted
Keywords: feature
Assignee: frsela → nobody
Couldn't find CardDAV feature on FOS roadmap.
Still waiting on two way sync feature, any news?
Keywords: foxfood
I conducted interviews of 3 people on XDA forums, and they all said that they wanted this feature.
This is one of the most wanted features ever, we need contributors to help here or product support and engineers to work on this.
The resolution of this BUG is looooong overdue, and I'd like to add that CardDAV sync should come with offline access to the synced contacts.

If no one else takes this on, can this simply be posted to a bounty site like Bountysource? (https://en.wikipedia.org/wiki/Bountysource)
Agreed, 2 years and still nothing, it seems like end-users concerns and requirements have no whatsoever weight on development plans. That's a sad simple fact. 
Mozilla likes to stress that one of the main goal of the organization is to protect our privacy. By providing out-of-the-box support for Facebook and Gmail but nothing for Self-CA and CardDAV?
Francisco, I'm going to take this, but don't hesitate to take it back if you have engineers from Mozilla to work of this. I'll do this when I have time, so progress will be slow :-)
Assignee: nobody → augustin.trancart
Flags: needinfo?(francisco)
Oh, great! Would be nice to have some progress here. :) My ownCloud is waiting for sync. ;)
Hi :autra that's good news!

We got an initial idea on how to do this in a way that the integration is pretty easy and doesn't require from a lot of dependencies in reviewing.

That idea is to have an external application that performs the sync, basically the contacts api is a privileged one, not certified, which means that anyone could create a sync app to perform any kind of contacts synchronization. With that said, CardDAV will be an excellent first approach ;)

In order to perform that and still have some integration with contacts we could do the following:

- We create a new app, in charge of doing the sync, and this app will offer an activity called (for example) contacts/sync. This app knows how to do everything related to sync, keeps all the logic and also setups any alarm to check for changes and so on.
- Contacts app, can perform in the settings panel a look up for any app that offers an activity called contacts/sync. If the system has any app that offers that, we display a button, to call this activity an drive the user to the new app to configure the sync process or check current status.

The advantages of doing this are, IMO:
- Is a totally independent app. Development should be faster.
- We could predistribute that app, but being a privileged app, it can live in the marketplace, and what is even better, can be updated completely independent. (Not like now, contacts app needs to be updated with the whole gaia, but we expect this to change soon).
- An user could install another app that gives the option to sync (choice is important in Firefox OS!)

That was our initial idea, but feel free to add/modify/send to trash/create from scratch :)

Also we were looking at this DAV library to perform the previous idea:

https://github.com/gaye/dav

Happy coding, and you can find us in the #gaia channel for any support or whatever you need!
Flags: needinfo?(francisco)
I guess the main problem still stands:

"ultimately carddav sync is a pretty hard problem to solve correctly. The main issue there is that the mozilla contacts API doesn't support the full feature-set of vcards. As a result, a carddav client may 1) fetch contacts from the server, 2) update a local vcard (in the contacts api), 3) store the contact again, but now missing important parts of the original vcard, thus resulting in data-loss."

https://www.reddit.com/r/FireFoxOS/comments/2jw2j5/carddav_sync_for_contacts_now_has_245_votes_why/clfuq5n

It looks like the solution depends on the implementation of a full feature-set of vcard, and once that is done, it might be actually trivial. The bug needing to be solved is then this other one (a full feature-set of vcard), that might not even be filed (certainly it looks like it wasn't linked to this one).
Just as an information, Francisco, if I understand correctly it, it would not be exactly integrated:

- It would require from the user to install this app before, so user not knowing those features could not discover it, as they have to know it exists and search how to get it (discoverability)

- The app would not be able to perform automatic and permanent synchronization, with a transparent way for the user, running as a daemon or service like, for example, CalDAV do?

But maybe am I mistaking about those two parts and just misunderstood.

That said, I guess that the solution you're talking about is, as you said, a lot easier to develop, maintain and update.

I don't know about the vCard full support evoked above, but maybe would it be nice to take a look at that too if someone really know well the spec and it's state in Firefox OS?
Flags: needinfo?(francisco)
>It would require from the user to install this app before, so user not knowing those features could not discover it

As Francisco said it, we can predistribute the app. 

>The app would not be able to perform automatic and permanent synchronization

It can with an alarm. Francisco, is there a way to react silently to a alarm? Because if I'm not mistaken, an alarm can launch an app, but we don't want to bother the user every time we sync. Actually, backgroundservice would have been my preferred way to go, but it is certified only. Alternatively, is it possible to make a silent MozActivity? If so, the contact app could trigger a contact/sync activity every x min (configurable) for configured account, and the external app would deal with sync in the background. What is the best solution to you?

About the full vCard support, I don't see why we absolutely need it yet. Maybe this will become clearer with time, but we'll have to store the vCard locally anyway (see [0] for an explanation why). d.pitrolo, could you elaborate if I'm missing something?

This intermediate application will store each vcard and keep a mapping between vCard and contacts. At sync time, it will perform adequate conversion between the 2 format. From contact to server, it will modify the vcard and send it (this way, we don't loose custom fields when we PUT). THe other way around is just a matter of extracting the right fields.



[0] http://sabre.io/dav/building-a-carddav-client/ TL;DR as there can be custom fields in vCard, we should always consider our local datamodel to be simpler and incomplete regarding the real-life vCard datamodel we receive.
(In reply to Augustin Trancart [:autra] from comment #125)
> >It would require from the user to install this app before, so user not knowing those features could not discover it
> 
> As Francisco said it, we can predistribute the app. 
> 
> >The app would not be able to perform automatic and permanent synchronization
> 
> It can with an alarm. Francisco, is there a way to react silently to a
> alarm? Because if I'm not mistaken, an alarm can launch an app, but we don't
> want to bother the user every time we sync. Actually, backgroundservice
> would have been my preferred way to go, but it is certified only.
> Alternatively, is it possible to make a silent MozActivity? If so, the
> contact app could trigger a contact/sync activity every x min (configurable)
> for configured account, and the external app would deal with sync in the
> background. What is the best solution to you?
> 
> About the full vCard support, I don't see why we absolutely need it yet.
> Maybe this will become clearer with time, but we'll have to store the vCard
> locally anyway (see [0] for an explanation why). d.pitrolo, could you
> elaborate if I'm missing something?
> 
> This intermediate application will store each vcard and keep a mapping
> between vCard and contacts. At sync time, it will perform adequate
> conversion between the 2 format. From contact to server, it will modify the
> vcard and send it (this way, we don't loose custom fields when we PUT). THe
> other way around is just a matter of extracting the right fields.
> 
> 
> 
> [0] http://sabre.io/dav/building-a-carddav-client/ TL;DR as there can be
> custom fields in vCard, we should always consider our local datamodel to be
> simpler and incomplete regarding the real-life vCard datamodel we receive.

If every field are not exactly the same on every side of the sync, how would it handle for dupes ? For me if two contacts are exactly the same excepted for a single field (which would sadly not be handled by one side, let's say Firefox OS), it would be considered as two different contacts.
Or it would require to take the decision to have fields acting as primary keys, but in that case, which ones? Different people can use the same name…
I don't know very well how vCards and Carddav are working to check contacts, but how comparisons are done? I would have thought about hashes, but, the same way, it is needed to have the same thing on both sides.

From what I could read from you here, backgroundservice really looks like the best solution, it's just more integrated and require, it seems, more works and approvals to do it if I understand correctly, but is it an issue?
(In reply to d.pitrolo from comment #123)
> The
> main issue there is that the mozilla contacts API doesn't support the full
> feature-set of vcards. As a result, a carddav client may 1) fetch contacts
> from the server, 2) update a local vcard (in the contacts api), 3) store the
> contact again, but now missing important parts of the original vcard, thus
> resulting in data-loss.

We have the very same problem with CalDAV haven't we? Not every field is accessible through the FFOS-calendar. The solution is that you need to be online to insert or update an event in CalDAV-calendars. There is no real sync in the calendar and I am more than happy about it. Have you ever tried to keep a calendar between 2 windows phones in sync when both phones are not connected at any time? I lost several events without knowing it because one phone deleted fresh entries of the other phone.

So whats the problem with not providing real syncing but forcing to be online to write to an online address book?
The problem is obvious: you could not create a contact without Internet connection. And you don't have it always.
(In reply to Yajo from comment #128)
> The problem is obvious: you could not create a contact without Internet
> connection. And you don't have it always.

That's what I said. But that seems to be no problem for calendar events. Why should it be one for contacts?
Both caldav and carddav have webdav-sync. Synchronization is possible here, you just need to make sure you have the complete server representation of the event and the ETag for it. If the ETag changed, you don't update the event/contact with your changed copy but instead notify the user about conflicts, or try to be smart about merging it. Syncing has gotten much better. Phones don't always have a reliable connection, so doing online-only editing is not a good idea.

For vCard you need to make sure you can cope with both vcard3 and vcard4 formats. They are usually identified by a UID property. If multiple contacts with different UIDs describe the same contact, you will have to save this information locally, or possibly create related link properties (e.g. social profile) on one of the vcards.

If this app is separate from the core, please make sure it still feels like core functionality to the user. Bundling it as mentioned is definitely a good step. Other apps might want to access the addressbook, so maybe the data model for the contacts should be extended so that more and possibly arbitrary properties can be retrieved.
That explains why I sometimes can't create a new calendar event. :(
(In reply to vlq from comment #129)
> that seems to be no problem for calendar events. Why
> should it be one for contacts?

It is a problem there too (see comment 131), but this bug is not about calendar events.
(In reply to vlq from comment #129)
> (In reply to Yajo from comment #128)
> > The problem is obvious: you could not create a contact without Internet
> > connection. And you don't have it always.
> 
> That's what I said. But that seems to be no problem for calendar events. Why
> should it be one for contacts?

That looks…pretty obvious. It would become impossible to add a contact to your phone if you were somewhere with no networks connectivity. And this can happen pretty much often depending on several conditions.
It would become a big handicap to use contacts.
(In reply to Yajo from comment #132)
> (In reply to vlq from comment #129)
> > that seems to be no problem for calendar events. Why
> > should it be one for contacts?
> 
> It is a problem there too (see comment 131), but this bug is not about
> calendar events.

Is there already a bug for it, by the way? Maybe should one be created if this is not the case?
(In reply to Clément Lefèvre from comment #133)
> (In reply to vlq from comment #129)
> > That's what I said. But that seems to be no problem for calendar events. Why
> > should it be one for contacts?
> 
> That looks…pretty obvious. It would become impossible to add a contact to
> your phone if you were somewhere with no networks connectivity. 

That's true of course. But this is much better than no CardDAV-support at all.
> That's true of course. But this is much better than no CardDAV-support at all.
Really ? With my 2€/month no data plan, I would be quite embarrassed if I could never add a contact with no wifi : as you can guess I never have wifi when I meet new people outside.
And yet I need carddav sync to sync my mobile phone with owncloud when I'm home …
(In reply to vlq from comment #136)
> (In reply to Clément Lefèvre from comment #133)
> > (In reply to vlq from comment #129)
> > > That's what I said. But that seems to be no problem for calendar events. Why
> > > should it be one for contacts?
> > 
> > That looks…pretty obvious. It would become impossible to add a contact to
> > your phone if you were somewhere with no networks connectivity. 
> 
> That's true of course. But this is much better than no CardDAV-support at
> all.

From what I understood about what you said, it would make it impossible to create contact, as for calendar events André is talking about, if you have no connection available at all. Even locally on the phone.
(In reply to inscription from comment #137)
> And yet I need carddav sync to sync my mobile phone with owncloud when I'm
> home …

Again... Does that not apply to calendar events as well? I can't see the difference. The way CalDAV events are handled is accepted for a couple of years now but with CardDAV this is a huge issue?
For one thing, let's leave this bug to CardDAV Sync, as that's what it's subject says.

Anything over 100 comments is hard to read at all, and way are way beyond that already (which makes me think the actual implementation should be in a dependent bug and not in here at all, but let's try to keep this bug in a state that it can actually be used for work).

All that said, many people use the calendar on the phone only for displaying and having reminders and not for active calendar editing, so the phone is a secondary device for those, while for contacts it usually is the primary device on which you edit them, add new ones (say, in a bar, where you met someone, and which is in a basement that has no cell or wifi reception at all). The use cases are different for many people.

But let's stop the discussion about calendar here. This bug is about CardDAV Sync, let's take anything else either to a mailing list or forum for just discussing, or to different bugs if it's work tasks.
(In reply to d.pitrolo from comment #123)
> I guess the main problem still stands:
> 
> "ultimately carddav sync is a pretty hard problem to solve correctly. The
> main issue there is that the mozilla contacts API doesn't support the full
> feature-set of vcards. As a result, a carddav client may 1) fetch contacts
> from the server, 2) update a local vcard (in the contacts api), 3) store the
> contact again, but now missing important parts of the original vcard, thus
> resulting in data-loss."
> 
> https://www.reddit.com/r/FireFoxOS/comments/2jw2j5/
> carddav_sync_for_contacts_now_has_245_votes_why/clfuq5n
> 
> It looks like the solution depends on the implementation of a full
> feature-set of vcard, and once that is done, it might be actually trivial.
> The bug needing to be solved is then this other one (a full feature-set of
> vcard), that might not even be filed (certainly it looks like it wasn't
> linked to this one).

Just to mention it: There is jCard, a vCard representation in JSON, same with xCard. We can store cards in JSON or XML internally if needed.
(In reply to Augustin Trancart [:autra] from comment #125)
> >It would require from the user to install this app before, so user not knowing those features could not discover it
> 
> As Francisco said it, we can predistribute the app. 
> 
> >The app would not be able to perform automatic and permanent synchronization
> 
> It can with an alarm. Francisco, is there a way to react silently to a
> alarm? Because if I'm not mistaken, an alarm can launch an app, but we don't
> want to bother the user every time we sync. Actually, backgroundservice
> would have been my preferred way to go, but it is certified only.
> Alternatively, is it possible to make a silent MozActivity? If so, the
> contact app could trigger a contact/sync activity every x min (configurable)
> for configured account, and the external app would deal with sync in the
> background. What is the best solution to you?

An alarm, using the alarm api [0], launch a specific document to handle the alarm but that document will be in the background, unless you decide to, explicitly, take the document to the foreground. So we won't have to bother the user. (And alarm api is not certified or privileged, you just need to ask for the permission).

Silent activities doesn't exist, since the definition of activity implies opening an app that shows you it's UI to perform some actions.

In the future with SW, we will have a way of performing a background sync [1], but this is still not yet implemented.

Current code for FB sync, that is on the way to be removed, uses alarm to perform the checks, do the sync and die.

> 
> About the full vCard support, I don't see why we absolutely need it yet.
> Maybe this will become clearer with time, but we'll have to store the vCard
> locally anyway (see [0] for an explanation why). d.pitrolo, could you
> elaborate if I'm missing something?

The mozContacts api was designed following vcard format, so you will have *almost* all the fields to support vcard4, but not all of them.

Some interesting fields for the sync like ETAG are not called like that but you have the field |published| and |updated| [2], this last one acting as a proper ETAG.

> 
> This intermediate application will store each vcard and keep a mapping
> between vCard and contacts. At sync time, it will perform adequate
> conversion between the 2 format. From contact to server, it will modify the
> vcard and send it (this way, we don't loose custom fields when we PUT). THe
> other way around is just a matter of extracting the right fields.
> 

In the current gaia codebase you can find files to transform from mozcontact to vcard (format 3.0 if I can remember correctly, since most of the androids just accept 3.0) since we support export to vcard [3]. It has some dependencies but easy to clean, I could help there easily.

> 
> 
> [0] http://sabre.io/dav/building-a-carddav-client/ TL;DR as there can be
> custom fields in vCard, we should always consider our local datamodel to be
> simpler and incomplete regarding the real-life vCard datamodel we receive.

[0] https://developer.mozilla.org/en-US/docs/Web/API/Alarm_API
[1] https://github.com/slightlyoff/BackgroundSync/blob/master/explainer.md
[2] https://developer.mozilla.org/en-US/docs/Web/API/MozContact
[3] https://github.com/mozilla-b2g/gaia/blob/master/shared/js/contact2vcard.js
Flags: needinfo?(francisco)
(In reply to Francisco Jordano [:arcturus] [:francisco] from comment #142)
> 
> The mozContacts api was designed following vcard format, so you will have
> *almost* all the fields to support vcard4, but not all of them.
> 
> Some interesting fields for the sync like ETAG are not called like that but
> you have the field |published| and |updated| [2], this last one acting as a
> proper ETAG.
The docs state that |updated| is a Date object, but ETags are actually tokens and not dates. If it were just a date, then they could have chosen to stick with If-Modified-Since and not create spec for ETags at all.

> > 
> > This intermediate application will store each vcard and keep a mapping
> > between vCard and contacts. At sync time, it will perform adequate
> > conversion between the 2 format. From contact to server, it will modify the
> > vcard and send it (this way, we don't loose custom fields when we PUT). THe
> > other way around is just a matter of extracting the right fields.
> > 
> 
> In the current gaia codebase you can find files to transform from mozcontact
> to vcard (format 3.0 if I can remember correctly, since most of the androids
> just accept 3.0) since we support export to vcard [3]. It has some
> dependencies but easy to clean, I could help there easily.
It would be nice if we could not cause more chicken-egg issues and go with using vcard4. CardDAV servers are equipped to accept vcard4 and serve vcard3 to clients that need it.
Francisco, what about backgroundservice Augustin talked about? Are they a problem, is there a reason it would be a bad idea? as I don't know that much those ways to do it, from what I read in comments, it looked like a good way to do it even if maybe a bit more complicated? (same behavior as daemons/services)

About vCard version, old Android even uses 2.1, but it's mainly useful to import.
(In reply to Clément Lefèvre from comment #144)
> Francisco, what about backgroundservice Augustin talked about? Are they a
> problem, is there a reason it would be a bad idea? as I don't know that much
> those ways to do it, from what I read in comments, it looked like a good way
> to do it even if maybe a bit more complicated? (same behavior as
> daemons/services)
> 
> About vCard version, old Android even uses 2.1, but it's mainly useful to
> import.

Unfortunately the concept of background services doesn't exist yet, until the implementation in Servicworkers [0] will be done.

[0]https://github.com/slightlyoff/BackgroundSync/blob/master/explainer.md
I don't intend on working on that in the foreseeable future. Feel free to take it :-)
Assignee: augustin.trancart → nobody
Firefox OS is not being worked on
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: