-
Notifications
You must be signed in to change notification settings - Fork 213
Integration with vdirsyncer #145
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
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. |
To make myself clear: the idea is not to make vdirsyncer a component of ikhal, but to split vdirsyncer functionnality into 2 sets:
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). |
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.
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.
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. |
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:
|
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? |
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". |
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). |
perhaps scanning vdirsyncers config if any new calendars have been added would be a nice usability improvement (see #241 ) |
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:
Sent from my phone. Please excuse my brevity. |
I didn't think of parsing the config myself, but rather using the Quoting Markus Unterwaditzer (2015-08-05 13:09:40)
|
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:
Sent from my phone. Please excuse my brevity. |
Quoting Markus Unterwaditzer (2015-08-05 15:26:20)
not sure, I haven't thought about it properly yet |
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 |
This is an enhancement request:
I dream to see a better vdirsyncer/ikhal integration, such that:
Is my dream possible?
The text was updated successfully, but these errors were encountered: