Integration with vdirsyncer

[pdav]

This is an enhancement request:

• given that configuring two distinct programs is a mess for new users, resulting in lower khal adoption
• given that the vdirsyncer and khal authors seem to collaborate efficiently ;-)

I dream to see a better vdirsyncer/ikhal integration, such that:

• vdirsyncer is still an autonomous program (with a specific configuration file for autonomous use), but some of its functions are callable from ikhal,
• I only have to manage the khal configuration file, with vdirsyncer specific parameters inside,
• such parameters are transmitted by ikhal to vdirsyncer functions when needed,
• ikhal synchronize (with vdirsyncer functions) on start, may be ultimately in a separate thread to minimize start-up latency,
• when I type the '$' key (as with mutt) or when I quit ikhal, ikhal starts a (blocking) synchronization with vdirsyncer

Is my dream possible?

[untitaker]

I don't like the idea of tightly coupling khal with vdirsyncer. One of the ideas I had when writing vdirsyncer was that it would be replaceable. One could use Dropbox, Syncthing, BitTorrent Sync, or just a mounted sshfs instead of it, if synchronizing with a specific server isn't a requirement. All of those are more performant than vdirsyncer could ever be. While it wasn't my intention at that time, I nowadays think that vdirsyncer should act more as a compatibility layer to CalDAV, and even in that sense the idea is still comparable to OfflineIMAP's.

Still, the 99%-usecase matters, I suppose. We have #136, which would help with deduplicating the config files' content, while sacrificing none of the flexibility (see the linked issue in there for an extensive explanation). Additionally khal could try to read vdirsyncer's config to see where calendars and contacts are, but I think a cleaner solution (and conforming with the idea of vdirsyncer's interchangeability) would be to specify a standard location for calendars and contacts.

[pdav]

To make myself clear: the idea is not to make vdirsyncer a component of ikhal, but to split vdirsyncer functionnality into 2 sets:

• a module with callable functions which perform the task given some arguments
• a main function whichs read the configuration file and calls module functions with appropriate arguments, such as vdirsyncer can still be used as an autonomous program such as OfflineIMAP.

Aftter all, mutt embeds an IMAP client and can still be used with OfflineIMAP.

I strongly believe that 1 > 1+1 (i.e. ikhal with embedded CalDAV synch is superior to 2 separate programs).

[untitaker]

to split vdirsyncer functionnality into 2 sets

khal already makes use of vdirsyncer's functions to read the items from the harddrive, and all functionality of vdirsyncer is usable as a library. I didn't document those parts because this would confuse the user further.

Aftter all, mutt embeds an IMAP client and can still be used with OfflineIMAP.

Yes, and there is a reason why OfflineIMAP exists even though mutt already supports IMAP. The main argument is that it enables offline usage, but that's not even half of the advantages one gets.

ikhal with embedded CalDAV synch is superior to 2 separate programs

From a usability perspective it's easier to grasp, I've made the counterargument above. Khal used to have embedded sync, see https://unterwaditzer.net/2014/vdirsyncer.html.

[geier]

I fully agree that usability is important and we should vastly improve in that area. While I use mutt/alot and offlineimap myself, several of my friends don't because setting it up properly is too much hassle to them.

What I want to do is getting khal to work with all storages that vdirsyncer supports, i.d., with local vdir storages as well as with remote (CalDAV) storages. I'll try to tackle that issue with the planned database rewrite. Using a remote storage would obviously delay startup, therefore syncing should perhaps been done asynchronously.

This would lead to two different usage models:

1. advanced users who want more control over their collections set up khal & vdirsyncer seperately, the way it is currently done. A nice addition for them (at least I want this feature) would be a "post_mod_hook", i.d., specifying a function that is run on exiting khal if any collection has been modified.
2. users who want a fast set up need to edit only khal's config file, directly giving the path to a remote storage (in the best case this is done by a setup utility).

[untitaker]

A nice addition for them (at least I want this feature) would be a "post_mod_hook", i.d., specifying a function that is run on exiting khal if any collection has been modified.

No offense, but I really don't get why people want to put modification hooks into every program, e.g. pimutils/vdirsyncer#133. Isn't this better handled by inotifywatch?

[untitaker]

Maybe the solution is a separate script which sets up both khal and vdirsyncer, without any modifications done to khal or vdirsyncer. This would have the advantage that the user could extend their already-existing configuration if they want to "get advanced".

[geier]

None taken ;-)

First, if you are not on Linux, there might be no inotify-watch (e.g. on *BSD), second if you are using inotify watch you'll need to start two commands instead of one or you'll need to write a wrapper script (this would be my preferred alternative).

[geier]

perhaps scanning vdirsyncers config if any new calendars have been added would be a nice usability improvement (see #241 )

[untitaker]

I've been planning to expose this information as new vdirsyncer commands, but I strongly discourage from parsing the config.

On 4 August 2015 14:57:29 CEST, Christian Geier [email protected] wrote:

perhaps scanning vdirsyncers config if any new calendars have been
added would be a nice usability improvement (see #241 )

---

Reply to this email directly or view it on GitHub:
#145 (comment)

Sent from my phone. Please excuse my brevity.

[geier]

I didn't think of parsing the config myself, but rather using the
relevant parts of vdirsyncer from khal. But time is in hard supply atm
anyway...

Quoting Markus Unterwaditzer (2015-08-05 13:09:40)

I've been planning to expose this information as new vdirsyncer commands, but I strongly discourage from parsing the config.

On 4 August 2015 14:57:29 CEST, Christian Geier [email protected] wrote:

perhaps scanning vdirsyncers config if any new calendars have been
added would be a nice usability improvement (see #241 )

---

Reply to this email directly or view it on GitHub:
#145 (comment)

Sent from my phone. Please excuse my brevity.

---

Reply to this email directly or view it on GitHub:
#145 (comment)

[untitaker]

That part is in need of a refactoring though, the current way how I pass the config around is silly.

I don't think we should make khal depend on more internal APIs of vdirsyncer. I'd like to provide a clean, well-documented interface for this, but I have no idea what it'd look like.

Would khal parse vdirsyncer's config everytime or would you save the results in your own datastore?

On 5 August 2015 15:07:08 CEST, Christian Geier [email protected] wrote:

I didn't think of parsing the config myself, but rather using the
relevant parts of vdirsyncer from khal. But time is in hard supply atm
anyway...

Quoting Markus Unterwaditzer (2015-08-05 13:09:40)

I've been planning to expose this information as new vdirsyncer
commands, but I strongly discourage from parsing the config.

On 4 August 2015 14:57:29 CEST, Christian Geier
[email protected] wrote:

perhaps scanning vdirsyncers config if any new calendars have been
added would be a nice usability improvement (see #241 )

---

Reply to this email directly or view it on GitHub:
#145 (comment)

Sent from my phone. Please excuse my brevity.

---

Reply to this email directly or view it on GitHub:
#145 (comment)

---

Reply to this email directly or view it on GitHub:
#145 (comment)

Sent from my phone. Please excuse my brevity.

[geier]

Quoting Markus Unterwaditzer (2015-08-05 15:26:20)

That part is in need of a refactoring though, the current way how I pass the config around is silly.

I don't think we should make khal depend on more internal APIs of vdirsyncer. I'd like to provide a clean, well-documented interface for this, but I have no idea what it'd look like.

Would khal parse vdirsyncer's config everytime or would you save the results in your own datastore?

not sure, I haven't thought about it properly yet

[WhyNotHugo]

An alternative compromise, is to have a sample vdirsyncer with calendars in a certain location, and have khal search that path by default. So if users don't change the sample configuration, khal would work out-of-the-box.

Yet another alternative, is khal-configure, that generates a khal configuration file based on the current vdirsyncer one (maybe offer to run it if none exists too?).