directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lécharny <elecha...@gmail.com>
Subject Re: [Studio] Configuration UI
Date Thu, 02 Apr 2015 05:47:50 GMT
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...

Mime
View raw message