Roadmap Updates

[tobixen]

This is a contination of #474.

There are two remaining items on the old road map, Async/API changes and the JMAP project. Async is ongoing work and will be released in 3.0, hopefully to be released in the end of January. I've looked through the list of outstanding issues, and found some more issues I'd like to get closed while releasing 3.0, that gives an extra 23 hours.

While working on the "server hints project", I did lots of development on a caldav-server-tester package, but it's needed with more QA and polishing and then make a proper release of the project. It would be very useful if people that experience problems with their private caldav servers are able to run the tester by themselves. It's also useful for generating configuration. I estimate 40h on this task, including documentation.

I think JMAP will be the next. The estimate was set to 40h, it's a very optimistic estimate for getting full-blown support for a completely different protocol - but 40h should be enough to get started with JMAP, set up something that covers the very basic save/load/search-methods, but no corner cases or extras supported. Research should also be done to see if there are existing JMAP libraries out there - but keep in mind tha JMAP is primarliy an email protocol, so whatever exists may not be optimized for calendaring usage. My idea now is to split out a new Calendar Client package which should have a fairly consistent API no matter if one will communicate with a CalDAV server or a JMAP server. The bulk of the work will be done outside the CalDAV library, but I expect that there will be a 3.1-release of CalDAV.

The scheduling support is under-tested, under-developed and needs more work, I'd like to release improved scheduling in version 3.2. The scheduling seems to be in demand, it's not much documented, but people still manage to find the methods and figure out that they don't work.

Rough time estimates

• ASync + API improvements - 50h (as before)
• Fixing/closing more issues for the v3.0 release - 23h
• Documentation updates v2.0 -> v3.0 - 12h
• Polishing and releasing the caldav-server-tester utility, including documentation - 40h
• Basic JMAP support - 40h (as before)
• Basic JMAP documentation - 8h
• Fixing/closing issues related with scheduling in 3.2 - 40h
• Rethinking JMAP and make a roadmap for full JMAP support - 8h

So it's 90 hours from the original road map and 95 hours extra.

Those issues will probably keep me busy until the summer, but I've also tagged up milestones 3.x / 3.x-google / 4.x in GitHub (with time estimates entered in the comments for some of those tasks), as well as my plann command line interface project.

Issue listings

Issues slated for 3.0:

• 4h - Rethink the new search API #590
• 4h - Replace "black style" with ruff #589
• 4h - Implement workarounds for servers not implementing text search and servers not implementing uid search #586
• 5h - search.py is already ripe for refactoring #580
• 2h - Digest Authentication error with niquests #564
• 5h - Test setup: try to mute expected error/warning logging and break on unexpected error/warning logging #518
• 4h - Refactor the test configuration again #509
• 6h - Refactoring - get_duration, get_due, get_dtend to be obsoleted #482

This sums up to 30 hours. Realistically I expect to close around 75% of those issues, giving an estimate of 23 hours.

Most of the issues are about improving the quality of the project and removing technical debt. I think some of those things should be prioritized as it's good to get it done when releasing a major version.

Issues slated for 3.2 - 38 hours, all of them should be completed:

• 12h - Scheduling - test server framework #596
• 4h - Spin up DAViCal docker container for testinga #595
• 8h - Check calendar owner #544
• 6h - event.add_organizer needs some TLC #524
• 8h - Problem with accept invite in calendar #399

[stevepiercy]

The scheduling seems to be in demand, it's not much documented, but people still manage to find the methods and figure out that they don't work.

"If it ain't documented, it's broken." I'd suggest adding enough to the budget to document what is needed, whether it's API or narrative docs.

[tobixen]

It's a good point. It bloats up the estimate, but considering my last overrun (spending more than 200h on something predicted to take around 50h), that's probably smart. Updated.