If you intend to have users accessing the Really Simple CalDAV Store with more than one client +then you should attempt to structure the URLs which they use to access the system in the way +that Mulberry does it.
+Basically, Mulberry breaks the URL into three parts:
+The host name is, of course, up to you. The 'root path' should be /caldav.php/ and anything following that is the calendar namespace.
Within the calendar namespace RSCDS uses the first element of the path as the user or resource name, so that a client connecting at the root path +can see all of the (accessible) users and resources available to them (Mulberry displays this hierarchy) with any calendars below that.
+Effectively this means that in Evolution, Sunbird and Lightning you should really specify a calendar URL which is something like:
++caldav://calendar.example.net/caldav.php/username/home/ ++
Then, when more calendar client software sees it as useful to be able to browse that hierarchy, you won't be up for any heavy database manipulation.
+I may well enforce this standard in some way before release 1.0, as well as auto-creating the collection records when Evolution, Lightning
+or Sunbird attempt to store to a non-existent collection.