Hi Martin, hi Jonas, First of all, thanks Jonas for your work, I really appreciate it.
>[...] > > A few comments in order to proceed: > > * Regarding your FIXME: I don't really see an issue with $HOME, possibly > a lack of understanding. The initscript already (re-)creates the default > directories before daemon start. For anything non-default, the user > needs to take responsibility of adjusting things. > > * For the file-store path patch, I see what you are getting at, however, > my focus is on radicale as a system daemon. If you go forward with > mimicking XDG_DATA_HOME, I'd suggest ~/.local/share/radicale/collections > instead of the ~/.local/shared/Radicale/collections you wrote. The user > would need a migration path though, similar to what I wrote into the > NEWS file. Using ~/.local instead of ~/.config is a much better choice, and I really should use that in the default configuration file. Using the real XDG_DATA_HOME environment variable is an even better solution, isn't it? > * Continuing with that path, there is the issue of config variable > renaming. If the user used a custom config file before and did not > change the variable name, he will end up with an empty calendar since > radicale silently uses the internal default of the new variable. It > could be good to notice that the old "folder" is set but > "filesystem_folder" is not set and gracefully fall back to that one > (possibly with some warning output that this is deprecated). I'm not > sure though how common this case will be, so not hacking a patch yet. The default folders will probably change again in the near future (as said in the last paragraph). Before 1.0, I've decided not to advertise about this in the code, but adding a warning saying something like "your storage folder is empty" could be a good idea. > * I found that my client (Iceowl) has an issue with the new 0.7 version > if the calendar is newly created and clean, namely it considers > radicale's answer invalid. (Adding events is working fine though and > from then on everything is ok.) Even though Iceowl/Sunbird is not an > officially supported client, I'm thinking of hacking a patch to fix > that. However, this could wait until a later package version. This issue is fixed in this commit: https://github.com/Kozea/Radicale/commit/c3ce8fde389075aa3c83b3db58b28f127c27ccf1 That's a bit more difficult now to create collections, as we must: - Understand that the client wants a collection (as usual) - Choose between a calendar and an address book Most of the clients can't create collections, they send requests and hope that the collection is already created for them. The collections are now created on GET requests, and the PROPFIND sometimes requests advertise their calendar or address book powers (that's what the commit does). I hope that it doesn't break the Apple clients support. Tests with different clients are welcome :). Regards, -- Guillaume
signature.asc
Description: This is a digitally signed message part
