Comments inline. James Carlson wrote: > Jeff Trawick writes: >> James Carlson wrote: >>> Has this change (and the reason for it) been discussed with the team >>> that supports the native Solaris LDAP library? >>> >>> >> It has been discussed to a small extent.
The Netrep/Solaris naming services team, that owned Solaris naming services, including sparks, nscd, Native LDAP, NIS, libldap5 etc. and the OpenLDAP project has been disbanded, as I have told Jeff and others. The group was disbanded/RIFd in the November/December 2008 time frame. The supported components of the system including sparks/nscd, libldap5, NIS and the Native LDAP components have been transitioned to RPE and are in a sustaining only mode, at this time. Currently there is no new funding scheduled for these components moving forward. As I have previously stated to Jeff and others, the OpenLDAP interfaces are all currently classified as volatile. Sun has defunded all future work for OpenLDAP. There is currently no long term LDAP strategy, except to have RPE continue to maintain the existing libldap5 APIs in the WOS. RPE has stated repeatedly that they have no interest in supporting OpenLDAP, except at the current support level [2 IIRC] which is to to say: they will log incoming bugs. At this time, unless Sun plans to allocate resources differently, people should not expect to see OpenLDAP APIs promoted beyond volatile anytime in the future, and they should not expect to see any additional enhancements, except possible future "as is" updates to SFW as time permits. As I told Jeff previously, since OpenLDAP was delivered into SFW, and since I delivered the project to that consolidation, if I have time later this year [probably no sooner than Q3 2009), and if at that time the OpenLDAP has released another stable release, I hope to find time on the side to update the SFW consolidation to some newer TBD release. I have also tried to make it clear the to web stack project teams that the OpenLDAP project considers it acceptable to make incompatible changes to any of their interfaces, including their libldap APIs, at any micro release, and does so regularly. It has been my experience that the OpenLDAP project tends to make bump their libldap library version levels about every 6 weeks. Anyone committing themselves to using these APIs should not set expectations that they will see fixes, unless they also want to commit to maintenance of the project in SFW. I have offered to hand OpenLDAP SFW 'ownership' over to one of the webstack groups or someone else if desired. I am willing to notify projects that choose to depend upon these APIS, that I intend to update SFW with a newer release so that those projects can make plans as necessary. Since we are not actively participating in OpenLDAP development, and have no plans to do so moving forward, anyone using these APIs need to understand that any updates will likely be replacements of older volatile interfaces with newer volatile interfaces, and it will be incumbent on the projects using the interfaces to deal with any incompatibilities in their code. The OpenLDAP project does not necessarily preserve backwards compatibility and Sun is not making the investment to help. I am considering delivering newer versions of OpenLDAP through the /pending, /contrib then /dev repos in the future, versus through the SFW consolidation. that may add further instability. > > That begs the next question: are they in substantial agreement with > the direction that this team is going? > >> Note that this isn't so much a technical matter of how to get a couple >> of specific open source packages to interoperate with the native Solaris >> LDAP library as it is a long term consideration for how we accommodate >> existing open source applications on the platform. > > Indeed! That's exactly the issue. > > What is the long term strategy here? Do we get rid of the native > Solaris LDAP library? If so, then why hasn't it been marked > "Obsolete" with OpenLDAP as the replacement? None. See above. > > If that's not the long term strategy, then what exactly is? Do we > have such a strategy for LDAP on Solaris? No Strategy, see above. Sustain Solaris libldap5 only. > >> All of the LDAP-exploitive packages we know of which are either >> potentially in scope for inclusion with the OpenSolaris web stack or >> likely added by users already work with OpenLDAP; relatively few of >> these packages work properly with native Solaris LDAP. Solairs Native LDAP does not, and probably never will support OpenLDAP, unless those projects are restarted and re-funded. > > I don't think that means that system architecture ought to be > "designed" by having each individual project vote with its feet. > > That's a recipe for chaos. > Agreed. It's not clear to me that projects that have a high expectancy of support and stability should depend upon essentially unsupported, highly volatile and unstaffed projects. Doug.
