search

apple / ccs-calendarserver

The Calendar and Contacts Server.
https://www.calendarserver.org
Apache License 2.0
485 stars 136 forks source link

not logical approach of using defaults. #476

Open f1-outsourcing opened 7 years ago

f1-outsourcing commented 7 years ago

If you do not define anything in the plist you expect the default value to be send, thus

in:

<key>mapping</key>
        <dict>

no key uid, thus your ldap query should use uid. but to my surprise I see apple-generateduid being send!

This i had to correct with:

<key>uid</key>
      <array>
      <string>uid</string>
</array>

A few years ago I had installed 4.2, then i had no issues. It is a bit early to deduct anything yet, but I hope your development team has not downgraded to the level of that of wordpress developers.

dreness commented 7 years ago

In the interest of having accurate expectations, I will offer a bit of history. This project was started by Apple, and almost all of the contributions have been from Apple employees. The primary target platform was macOS (at the time, "Mac OS X"), and was delivered as one of the services in Apple's Server product (initially "Mac OS X Server", then "OS X Server" when it became an app instead of an entire OS distribution, and finally "macOS Server").

CalendarServer was developed from the start as an open source project, and has taken patches over the years from the community - patches that people have needed for their own purposes. The project has never had a goal of being easy to use over the long term in a generic open source context. That is certainly a good goal, but has not been a goal of this project. For Apple's primary target (Server), the tasks surrounding upgrade and migration of CalendarServer are handled automatically by software that is not part of the CalendarServer project. The average user of CalendarServer in Server has probably never even seen the config file.

We fully recognize that upgrade and migration of any other kind of deployment of CalendarServer is a very manual task, amidst very sparse documentation. It is not for the faint of heart. I wouldn't say that CalendarServer's support for other platforms is getting worse, I would say it's always been shaky at best. That said, if you're willing to overcome these challenges, CalendarServer can provide a lot of features, and scales to enterprise level. Personally, I still think there is more value in CalendarServer being open source than closed source, even though it does not have the polish that many expect. I will confidently assert that filling in the gaps at the deployment / ops level is way, way less work than what was required to produce this codebase.

On the up side: a) patches are welcome! b) we have mailing lists where even non-apple-employees contribute by helping others - see https://apple.github.io/ccs-calendarserver/

f1-outsourcing commented 7 years ago

I was expecting such reply actually. Although it is mainly an apple product, I still think a good approach would be to keep the application simple with eg. an expectable behaviour. And if it is easy to deploy it on other platforms it will also be easy to deploy with osx. And you will get lots of feedback from a larger community. Opensource and open standards are the future. Things like the above issue are likely going to bite you in the future.