Invalid assumption made about the URI of calendars stored in a CalDAV server

[stellingsimon]

We are using ical4j-connector in a setting where it is not the only client communicating with the same CalDAV server. As a result, we may fetch events from a CalDAV server whose URI does not strictly follow the pattern ${eventUID}.ics. The CalDAV standard specifies that the client (which may be a different one than ical4j-connector!) is free to choose URI and UID as long as they are valid. They do not need to be related in any way, although that's admittedly often the case.

We currently cannot update these events through ical4j-connector. The method CalDavCalendarCollection::writeCalendarOnServer takes a Calendar object and a flag isNew, but derives the event's URI from its UID. There is no way for us to specify the URI, even though we know it.

Similarly, the methods CalDavCalendarCollection::removeCalendar and CalDavCalendarCollection::getCalendar take a UID instead of a URI. They can be tricked to work with URIs ending in .ics, but if the suffix isn't present in the URI, events cannot be fetched using ical4j-connector.

I propose the following changes:

• Add an overload with an additional parameter String eventUri to the methods CalDavCalendarCollection::writeCalendarOnServer, CalDavCalendarCollection::addCalendar and CalDavCalendarCollection::updateCalendar. The existing overloads should stay so that the API is backwards-compatible.
• Add two new methods CalDavCalendarCollection::getCalendarFromUri and CalDavCalendarCollection::removeCalendarFromUri taking a single argument String uri. The existing getCalendar and removeCalendar should be kept so that the API is backwards-compatible.