Abook storage backend about vdirsyncer

[untitaker]

Of course a cleaner solution still would be to write a new client that uses vdir.

[zodtm]

You can check out https://github.com/hnrysmth/ppl
Its storage backend is basically a dir full of vcf files (with only UIDs missing)

[untitaker]

It definetly has a nice interface, but it seems it is not able to deal with vcf files created by other programs.

[t-8ch]

For querying with mutt I have written a small program: https://github.com/t-8ch/snippets/blob/master/contactquery.c

[zodtm]

I did a quick test, and it seems one can toss in new vcf-files, but the problem is ppl derives the nicknames from the filenames in its backend. I took the liberty of asking the author about UID filenames in the context of better vdirsyncer integration ( henrycatalinismith/ppl#47 ).

I really think vdirsyncer + ppl would be an awesome combination.

[untitaker]

@t-8ch Oversaw your comment... interesting, last week i searched for a decent vcard parser in C (so i could use it from Rust) and couldn't find anything. I ended up porting https://github.com/untitaker/dotfiles/blob/master/home/.scripts/mates to Rust, and it was hardly better.

[t-8ch]

@untitaker It should also be possible to use libical for vcards (see vobject.h). It should be packaged for all distros. Or just use my version :-)

[untitaker]

I wanted to take this as an opportunity to learn Rust. Will take a look at vobject.h.

[geier]

untitaker: are you starting a new addressbook project?

[untitaker]

Not sure. I didn't get very far, there's no decent standalone vcard library for C, and none for Rust. Don't really want to depend on evolution-data-server.

[untitaker]

I rather write this for learning Rust, not really for making something usable.

[untitaker]

FWIW, here it is: https://github.com/untitaker/mates

@t-8ch if you want we could add your script to https://vdirsyncer.readthedocs.org/en/latest/supported.html#client-applications

[t-8ch]

@untitaker I added it and pushed it and a small fix to master.

[untitaker]

Thanks!

[untitaker]

Closing this because writing a custom addressbook client yields far better results.

[tristan-k]

Can you please reopen the issue. I'm trying to use Trojita with Carddav. It currently lacks support for it, but does read abooks adressbook in ~/.abook. If vdirsyncer would be able to write to abooks storage backend, Trojita would be able use Carddav. Also see this issue for a workaround with another python script, which fails for some reason.

[untitaker]

Please open a new issue with the stated, more general, goal to integrate Trojita. I would strongly recommend looking for alternative ways that don't involve ~/.abook.

…

On Thu, Jun 01, 2017 at 06:52:03AM -0700, ǝʞɔoʃʞ uɐʇsıɹʇ wrote: Can you please reopen the issue. I'm trying to use Trojita with Carddav. It currently [lacks](https://bugs.kde.org/show_bug.cgi?id=358485) support for it, but does read abooks adressbook in `~/.abook`. If vdirsyncer would be able to write to abooks storage backend, Trojita would be able use Carddav. Also see this [issue](dglent/vcf2addressbook#1) for a workaround with another python script, which fails for some reason. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: #25 (comment)