Open macosforgebot opened 12 years ago
macosforgebot
commented
12 years ago zecke@… originally submitted this as attachment:0001-xmldirectory-Update-documentation-to-match-3.x-reali.patch:ticket:474
First attempt at removing old things
macosforgebot
commented
12 years ago @wsanchez originally submitted this as comment:1:ticket:474
Yes, it's outdated.
macosforgebot
commented
11 years ago @wsanchez originally submitted this as comment:5:ticket:474
macosforgebot
commented
10 years ago @wsanchez originally submitted this as comment:6:ticket:474
New XML schema in going into v6…
schmurfy
commented
7 years ago What is the status on this ? For now trying to do anything with this project has become my worst nightmare, the conf folder contains dozen of files, just finding what is loaded was a challenge and once you have the file there is no documentation on what they should contain, how are people even using this ?
dreness
commented
7 years ago Hi,
It is true that this project lacks comprehensive documentation. However, there are breadcrumbs you can follow based on what we do have, and also mailing lists and an IRC channel - these are linked from https://apple.github.io/ccs-calendarserver/, which is linked from README.rst.
Starting from README.rst, note that the 'run' script wants to use conf/caldavd-dev.plist by default. This indicates that CalendarServer needs to be told which config file to load at startup (the run script is offering to use a sample config), and this is confirmed by looking at the run script itself to see how it executes caldavd.
The 'run' script is just a convenience wrapper around caldavd that makes assumptions to ease the quickstart process from a git checkout, and should only be used when developing / testing, not for production.
The config file specified at start time is the one that decides which other configs (if any) are loaded. For example caldavd-test.plist (which 'run' will offer to copy to 'caldavd-dev.plist' for testing purposes) loads conf/auth/accounts-test.xml for user account definitions. There is no expectation that every file under conf is being used by a running service - only the ones specified by the plist used when starting caldavd. There is also support for an "Include" directive to load other config files, useful to separate different kinds of config into different files if you desire.
As far as the meaning of the plist entries, most of them are commented. The default values for all config items are defined here, and as a convenience, a plist-formed version of that config is available in conf/caldavd-stdconfig.plist. Any config elements that are not specified in the loaded config will inherit the values shown in caldavd-stdconfig.plist. Do not edit this file, or stdconfig.py. Instead, simply define what you want in your own config file, when there are differences from the defaults, or even when there aren't if you want your config to be fully explicit.
Swinging back around to the more specific parts of your question:
The XML DTDs are unfortunately not enough to understand what a valid record looks like - the DTDs just specify a fairly loose set of constraints on what elements / attributes are valid at the XML-parsing layer, without respect to any higher-layer logic. For that logic, look towards twext/who - specifically directory.py and idirectory.py
Looking at twext code and also the various sample XML and plist files should hopefully get you going in the right direction. In caldavd-stdconfig.plist, the sections DirectoryService and ResourceService define which xml files are loaded to define the various record types, and AugmentService defines which file (if any) stores calendar-specific attributes that would likely not exist by default in a standard directory service (this seems like an odd thing in the context of an XML-based DirectoryService / ResourceService, but we also support LDAP services using a standard schema).
... and to answer your first question: no status, but we're probably a little closer now that I've written the above...
schmurfy
commented
7 years ago thanks for your detailed reply I will try to find my way.
zecke@… originally submitted this as ticket:474
http://trac.calendarserver.org/wiki/XMLDirectoryService and the copy in the source tree refer to cuaddr, proxies, and more. These are not available in CalendarServer 3.x.