ebdb
ebdb copied to clipboard
girzel
Integrate with vcf files on disk and vdirsyncer
vdirsyncer synchronizes a carddav/caldav server with local filesystem and drops vcf/ical files in there. These files can be read by many tools such as khard, khal and Emacs has vdirel. I'm the author of the last one. Is there anything we could do together?
Absolutely -- vcard and carddav support are the last big feature I'd like to add to EBDB. I've been waffling about how to do it, though: I've more or less got export working, that just needs to be fleshed out. But I've been dragging my feet about import. On the one hand it feels like there are a lot of libraries that do something like this out there, and I'm reinventing the wheel. On the other hand, import is going to be slow no matter what, and going from vcard to some other format to EBDB is going to make it worse.
My assumption was that carddav support would go like this: EBDB would still keep its records in its native format. When we first connected to a server, initial sync would be slow. After that, any changed records would be first converted to vcard format and then sent along the wire (or in reverse when updating from the server), but the local storage would still be EBDB, minimizing the amount of conversion. I was assuming I would use the built-in url-dav library, and was planning on cribbing from org-caldav.
My understanding of vdirel is that it would expect all contacts to be stored in vcard format. I'm not averse to that in principle, so long as read and write times are tolerable (EBDB load times are currently pretty bad, and it bothers me).
Then the only question is how to parse the vcard files. I was considering a big pile of regexps, and also the wisent parser. Neither sounded like a lot of fun, hence my procrastination.
Eric Abrahamsen [email protected] writes:
My assumption was that carddav support would go like this: EBDB would still keep its records in its native format. When we first connected to a server, initial sync would be slow.
do you want to implement communication with carddav servers yourself? It feels more reasonable, at first at least, to read the vcf files that vdirsyncer downloaded. It adds a dependency to vdirsyncer but you get a lot for free: synchronization, conflict management, workarounds for broken servers…. Vdirsyncer works like a charm and it would be a shame to re-implement it.
-- Damien Cassou http://damiencassou.seasidehosting.st
"Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill
I don't want to, I assumed I would have to! I would be more than happy to consider vdirsyncer. Like I said, my first concern is simply speed, and that depends on the performance of vcard parsing. The only potential downside to using vdirsyncer would be if we were obliged to keep all the records in vcard format, but vcard parsing was very slow.
If that isn't a problem, then I'm happy to use vdirsyncer, I'm in no hurry to write my own carddav client.
vcard and carddav support are the last big feature I'd like to add to EBDB.
What is the current plan in regard to the above? Do you plan to consider using vdirsyncer?
The plan is to first write a vcard parser, I think the idea was to use parsec. EBDB already writes vcard okay (or it could do without much more work), but I don't have anything for parsing.
Once there's a parser in place, it looks like vdirsyncer could do the rest.
Progress is slow but steady! I'm about halfway through a vcard parsing library.
Well, this is taking a lot longer than I expected! Here's the parsing library:
https://elpa.gnu.org/packages/vcard.html
I am also using the same workflow.
I am using vdirsyncer to synchronise my contacts with Google Contacts and my Android phone. Google CardDAV server is a very peculiar one (in particular because it only supports CardDAV 3.0, and does immutable updates of vcards), but, I guess, is the only one that is not obscure. At the moment I am using khard and khal from console, and on machines where Emacs is unavailable, but I would certainly want to use it from Emacs.
Thank you for your job any way!
