Gave an overview of the current state of DS as a repo for 5.5, along with a discussion of what to expect for 6.0. Discussed the use of rest2ldap (which they were familiar with). Discussed generic (JSON structures) vs. explicit mapping. Discussed the potential value of a hybrid model. Discussed the possibility of having a shared backend for AM and IDM, how that would work and the potential benefits.
Q: Performance for writes?
Q: Is JDBC still supported?
Q: How will this work with relationships?
A: We don't know if we will have the same level of support as we expect to have with JDBC.
Q: Is DS the only LDAP backend that will be supported? What about AD?
A: For 6.0 that is the only planned backend (though it might be possible to use others without support)
Q: How are passwords treated (underlying password hashing used?)?
A: We haven't worked it out yet, but generally would prefer to continue to rely on the native DS behavior.
Q: Is the config stored in the repo?
A: Yes, but could be made to be exclusively file-based.
Q: What about Activiti?
A: Need to continue to use a JDBC backend.
Comment: There is no need for a flexible data model in production. Preference would be for explicitly mapping all properties. Generic only useful for demos.
Discussed with customer later, they expressed interest in how DS is making use of the "Affinity Load-Balancer" option and how that is critical for IDM to use DS in production. Interested in the challenge of making a write and then immediately reading back the same record, as this partner has faced similar difficulties. This seems like a feature that we should make sure gets some coverage in the 5.5 release.