search

Kozea / Radicale

A simple CalDAV (calendar) and CardDAV (contact) server.
https://radicale.org
GNU General Public License v3.0
3.36k stars 437 forks source link

Follow roadmap for 2.0 #372

Closed liZe closed 7 years ago

liZe commented 8 years ago

As defined in #364.

liZe commented 8 years ago

I've removed the extra storage, auth and rights modules. Anyone is insterested in testing the new code and config file?

untitaker commented 8 years ago

Could you keep the refactor out of master until it is finished? Thanks!

Will test soon, but right now I have to deal with the dev version being broken in my CI. :(

liZe commented 8 years ago

Could you keep the refactor out of master until it is finished? Thanks!

I won't, sorry :/.

I've had really bad experiences with keeping ongoing development out of master, and good experiences after with big changes in master early:

By the way, I've added a 1.1.x branch, and I'm trying to keep master working even with big changes (Travis is watching us!)

Will test soon, but right now I have to deal with the dev version being broken in my CI. :(

Thank you, good luck!

liZe commented 8 years ago

I've tested the current version (af19377c) with Thunderbird, DAVdroid and CalDAV Sync Adapter. Collection discovery seems to work well with and without authentication.

liZe commented 8 years ago

The Collection API has been changed as proposed in #130.

untitaker commented 8 years ago

BTW I think https://github.com/eventable/vobject/pull/23 should be considered a blocker issue.

liZe commented 8 years ago

The file locker has been implemented in #402.

I've tested (not for a long time) the current master branch with many clients, including Cadaver, Thunderbird, iOS Calendar, OSX Calendar, and it seems to work well.

liZe commented 8 years ago

I've removed freebusy (#34) and sync-collection REPORT (#306) from the roadmap, as they need a lot of time. I'll fix the two last technical tickets (#440 and #327) and realease a new RC soon.

The next step is testing and documentation writing. Anyone interested?

untitaker commented 8 years ago

I consider https://github.com/Kozea/Radicale/issues/384 and the previous one I mentioned to be blocker issues.

On 13 July 2016 16:11:42 CEST, Guillaume Ayoub notifications@github.com wrote:

I've removed freebusy (#34) and sync-collection REPORT (#306) from the roadmap, as they need a lot of time. I'll fix the two last technical tickets (#440 and #327) and realease a new RC soon.

The next step is testing and documentation writing. Anyone interested?

You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/Kozea/Radicale/issues/372#issuecomment-232367169

Sent from my Android device with K-9 Mail. Please excuse my brevity.

liZe commented 8 years ago

I consider https://github.com/Kozea/Radicale/issues/384 and the previous one I mentioned to be blocker issues.

eventable/vobject#23 has been merged in vobject, so that shouldn't be a problem anymore. #384 is a real problem.

untitaker commented 8 years ago

Sorry, I meant https://github.com/eventable/vobject/pull/33

On 13 July 2016 16:22:55 CEST, Guillaume Ayoub notifications@github.com wrote:

I consider https://github.com/Korea/Radicale/issues/384 and the previous one I mentioned to be blocker issues.

eventable/vobject#23 has been merged in vobject, so that shouldn't be a problem anymore. #384 is a real problem.

You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/Kozea/Radicale/issues/372#issuecomment-232370638

Sent from my Android device with K-9 Mail. Please excuse my brevity.

untitaker commented 8 years ago

Also I would propose waiting for a vobject release and setting the new version as minimal requirement, otherwise I'd imagine that a lot of bugreports will arrive when using older versions.

On 13 July 2016 16:22:55 CEST, Guillaume Ayoub notifications@github.com wrote:

I consider https://github.com/Korea/Radicale/issues/384 and the previous one I mentioned to be blocker issues.

eventable/vobject#23 has been merged in vobject, so that shouldn't be a problem anymore. #384 is a real problem.

You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/Kozea/Radicale/issues/372#issuecomment-232370638

Sent from my Android device with K-9 Mail. Please excuse my brevity.

liZe commented 8 years ago

Everything seems to be OK on the technical side now (except from eventable/vobject#33). There's a couple of small features to add and small bugs to check, but nothing like what's been done during the last weeks.

Thank you for the amazing work :clap:.

I'll start the documentation during the next days, following what's been defined in this ticket and the open documentation tickets of the milestone.

liZe commented 8 years ago

Here are the first pages of the future website. If anyone is interested…

untitaker commented 8 years ago

The site design is very nice!

I consider "shares through WebDAV" an overstatement since Radicale only supports the set of WebDAV required for CalDAV and CardDAV. In practice I've not been able to mount Radicale collections with davfs. It is possible with owncloud though.

Also I'm not sure what you mean with "warns on concurrent editing" and "secure connections".

On 10 August 2016 18:11:13 CEST, Guillaume Ayoub notifications@github.com wrote:

Here is the first pages of the future website. If anyone is interested…

You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/Kozea/Radicale/issues/372#issuecomment-238917637

Sent from my Android device with K-9 Mail. Please excuse my brevity.

liZe commented 8 years ago

The site design is very nice!

:smile:.

Oh… You'll be impressed when our webdesigners work on that!

I consider "shares through WebDAV" an overstatement since Radicale only supports the set of WebDAV required for CalDAV and CardDAV.

1.x versions were not able at all to talk to WebDAV clients, but 2.x versions will be much better. It's working at least with OwnCloud and Cadaver.

In practice I've not been able to mount Radicale collections with davfs.

I didn't know davfs, it's really cool! I've tried it and… Guess what, it works perfectly! Setting use_locks 0 in /etc/davfs2/davfs2.conf is the only thing I did, and I'm able to copy and rename files and directories, and of course edit files :wink:. Really amazing.

Also I'm not sure what you mean with "warns on concurrent editing" and "secure connections".

"Warns on concurrent editing" means that, for clients supporting this feature, Radicale will refuse to edit an item that has been modified since the last time the client downloaded it.

"Secure connections" means that Radicale supports HTTPS, even without a "real" HTTP server.

bandali0 commented 8 years ago

Really looking forward to 2.0!

@liZe Any pointers or recommendations for "simple installation" for personal use? I'm about to re-setup my VPS from scratch and would love to use Radicale 2.0 for my calendars and contacts.

liZe commented 8 years ago

Any pointers or recommendations for "simple installation" for personal use? I'm about to re-setup my VPS from scratch and would love to use Radicale 2.0 for my calendars and contacts.

Installing from scratch for personal use is really easy. You can follow what's in the future tutorial :

That's all!

bandali0 commented 8 years ago

Ha I see, thanks! I'll try and see if I can run it behind nginx.

pbiering commented 8 years ago

Dropping Phyton 2.x support and enforcing Phyton 3.x leads to installation problems on Enterprise Linux version 7 (latest RHEL or CentOS). Biggest issue is that I haven't found a mod_wsgi module for EL7 -> radicale "must" run in standalone mode with Apache in front using ProxyPass Major issue is missing "python34-vobject", but this is solvable by an adjusted rebuild of SRPM of latest Fedora version.

I can confirm now proper working with "Thunderbird Inverse SoGo Connector", for migration from old multi-filesystem one should perhaps document, that calender "folder" layout changed:

Old: /user/calendar-1/id-of-entry-1.ics /user/calendar-1/id-of-entry-2.ics ... /user/calendar-1.props containing "VCALENDAR"

New: /user/calendar-1/id-of-entry-1.ics /user/calendar-1/id-of-entry-2.ics ... /user/calendar-1/.Radicale.props containing "VCALENDAR"

BTW: in case a manual calendar folder was created on file system but missing .Radicale.props and then using SoGo connector with folder URL leads to a very strange result: new calendar entries are created as folders, entry contents is a file in that folder having a short hashed name, .Radicale.props is also stored in the folder, directory/file permissions on Unix are 777 and SoGo can't read back the entry (because dot-props for folder is missing): /user/calendar-with-no-dot-props/id-of-entry-1.ics/shortid /user/calendar-with-no-dot-props/id-of-entry-1.ics/.Radicale.props -> somehow not expected, I would suggest rejecting creation of entries in a folder in case this is not explicitly defined in .Radicale.props as VCALENDAR or VADRESSBOOK.

Permissions of 777 are probably the result of umask(0), see https://github.com/Kozea/Radicale/pull/540

liZe commented 8 years ago

new calendar entries are created as folders

It's normal. There's no difference between an event and a calendar in iCal, so PUTting an event in a non-calendar collection is just like creating a calendar in this collection. Nothing strange here :wink:.

migration from old multi-filesystem one should perhaps document that calender "folder" layout changed

Of course! We just need to write the Storage page of the new configuration.

Dropping Phyton 2.x support and enforcing Phyton 3.x leads to installation problems on Enterprise Linux version 7 (latest RHEL or CentOS).

With "serious" distributions, it's probably not a good idea to use Radicale 2 before it's been officially packaged. But if anybody wants to try, using pip to install vobject and putting Radicale behind nginx+uwsgi is a solution that should be available in any current distribution.

pbiering commented 8 years ago

new calendar entries are created as folders

It's normal. There's no difference between an event and a calendar in iCal, so PUTting an event in a non-calendar collection is just like creating a calendar in this collection. Nothing strange here :wink:

Can one implement a feature (perhaps optionally like "strict_subfolder_usage") to prevent creating Items in the root folder which aren't collections? Because this turns to totally strange situation:

WP run calendar autodiscovery and suddenly has more calendars, the original "folder-based" ones + for each new Item created in the root-folder...means calendars in WP are increasing over time...one per new Item created by a client which (for whatever reason) places entries in the / folder

pbiering commented 8 years ago

Please take a look on my pull request on top of master, I would consider it as stable now, found no issues so far: https://github.com/Kozea/Radicale/pull/526

liZe commented 7 years ago

I'll release a beta version of 2.0.0 soon. The 2.0.0 milestone has some issues open, but some of them can wait after the beta is released.

The future documentation can be updated on the gh-pages branch, take a look if you're interested!

liZe commented 7 years ago

I have released 2.0.0rc1 on PyPI! The version is hidden but available.

There are lots of cool features waiting in some pull requests, but I find them a little bit too dangerous to merge them just now. 2.0.0 is working quite well right now, I'll only merge bugfixes before 2.0.0.

Please check that everything works for you!

klonos commented 7 years ago

The version is hidden but available.

Can you please share the secret 😄 ...links to binaries would be awesome 😉

liZe commented 7 years ago

https://pypi.python.org/pypi/Radicale/2.0.0rc2 ;)

liZe commented 7 years ago

Please read carefully if you're interested in Radicale's future.

Now that #591 is (almost) fixed, I'll release 2.0.0 using the git master branch on Saturday or on Sunday this week.

I know: I'm late.

Before the release, I'd like you (@untitaker, @pbiering, @Unrud, and anyone interested of course) to help me solving a couple of problems:

What do you think about that?

Another important point: THANK YOU.

It's been a pleasure to merge your pull requests and discuss all these issues and feature requests. After 2.0.0 is released, it's time for Radicale to find new co-maintainers with superpowers. Radicale has become a lot bigger and powerful than it was before. There are really interesting pull requests waiting to be merged, but I can't find the time and the motivation to read, review and merge them anymore. Moreover, I've always loved really simple code with a small amount of features, and I think that Radicale now wants to include features that I'm not ready to clean, debug and maintain alone. Of course, I'll keep an eye on the project and tell what I think, but I'd like to give admin rights to the repository and to PyPI to some current contributors. If anyone is interested, just tell me!

:heartbeat:

Unrud commented 7 years ago

I'll release 2.0.0 using the git master branch on Saturday or on Sunday

Before you do this, please cherry-pick https://github.com/Kozea/Radicale/pull/484/commits/fc05e551919d773ca848b6892de88140bb3ad110 (#598 is the same fix, but checking path.startswith(base_prefix) was forgotten). The SCRIPT_NAME environment variable is currently not working at all.

I propose to merge (or reject) #604 and #608 before the release. They are very small, but change the default configuration and behavior of the --config command line argument slightly. Therefore, they cannot be merged in a minor release later.

I think that all the other open pull requests don't change anything in a manner that is not backwards compatible.

There are lots of issues open about the documentation.

I started writing the documentation for 2.0.0 in #607 and created an easier way to upgrade from 1.x.x in #606.

it's time for Radicale to find new co-maintainers with superpowers.

I would be interested. I was thinking about forking Radicale anyway.

liZe commented 7 years ago

Before you do this, please cherry-pick fc05e55

It's done, thanks.

I propose to merge (or reject) #604 and #608 before the release.

I've merged both, better now than later.

I think that all the other open pull requests don't change anything in a manner that is not backwards compatible.

I'm a coward, some of them are too big for me :wink:. I'd prefer to merge them in a future version.

I started writing the documentation for 2.0.0 in #607 and created an easier way to upgrade from 1.x.x in #606.

I've merged #606 and I'll merge #607 just before releasing 2.0.0. I'll release a new 1.1.x version too.

I would be interested. I was thinking about forking Radicale anyway.

Good news! I think that you have the skills and motivation to bring Radicale to a higher level. No need to fork then, here is a copy of the key :key:.

liZe commented 7 years ago

Radicale 2.0.0 has been released :tada:.

djmattyg007 commented 7 years ago

Congratulations :)