Le 01/04/15 23:28, Emmanuel Lécharny a écrit : > Hi, > > I face an issue that requires some thought - and potentially some rework > in both the ApacheDS and OpenLDAP configuration editors -. > > Once upon a time, we had many versions of the ApacheDS configuration > plugin, because every time we changed the configuration, we had to adapt > the UI. We decided to get rid of all those plugins, to only keep the > latest version (ie 2.0). Th pb is exactly teh same for the OpenLDAP > configuration : it evolves... > > Finding the best way to deal with this problem is not simple. It's not > only a pb of loading the right config, it's also a pb with the UI > itself. ATM, I don't see any good solution to get an UI that is > adaptative, but defining a new plugin for each version, which is > extremelly heavy, or a complex handling of the UI with various checks to > handle all the possibilities. > > First, I do think that for ApacheDS, we can keep going with only one > plugin, because we expect our users to migrate to the latest ApacheDS > version, until we reach a 2.0. It's not ideal, but this is most > certainly the right thing to do. > > For OpenLDAP, it's really different, because there are tens of thousand > users with many different versions (and I'm just talking about the 2.4 > revision, which, as of today, has 41 versions). It makes it impossible > to ignore older versions (up to a point), especially for all those who > are installing the broken and antiquated versions 'provided' (so to > speak) by distribution (RH, Debian, etc...) > > So, what are our options ? > > Currently, we define some Java bean to store the attribute's value. That > means we have to also keep a track of which attribute exists in each > version (this is not done atm), so that we don't inject unexisting > attributes, or simply have missing ones. The other aspect we have to > deal with is the GUI itself : how do we present the parameters and their > values, when it can change fro version to version ? > > At some point in the future, we coud imagine to leverage the template > editor, but that would require some adaptation (typically, if we want to > add popups, as it's not supported). But that would be a lot of work. > > A simpler option would be to have templates for each configuration > ObjectClass, but we would use a much simpler GUI : the user would have > to use the LDAP browser to switch from one configuration element to > another. Quite basic, but an elegant presentation is possible. > > Anyway, a lot to think about, and I'd liek to have your opinion about > what could be the best way to go. > > Thanks ! I would add that, for OpenLDAP, it's impossible to know which version we are connected to, as it does not provide the vendorVersion attribute in the rootDSE :/
The only way would be to provide such an information at the connection level, which is highly problematic...
