directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Clément OUDOT <cou...@linagora.com>
Subject Re: [Studio] Configuration UI
Date Fri, 03 Apr 2015 07:20:34 GMT
Le 02/04/2015 07:47, Emmanuel Lécharny a écrit :
> 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...
Hi Emmanuel,

We get this information in the cn=monitor backend, see:

dn: cn=Monitor
structuralObjectClass: monitorServer
creatorsName:
modifiersName:
createTimestamp: 20150403064323Z
modifyTimestamp: 20150403064323Z
monitoredInfo: OpenLDAP: slapd 2.4.40 (Oct  1 2014 11:57:04)
entryDN: cn=Monitor
subschemaSubentry: cn=Subschema
hasSubordinates: TRUE


But it would be indeed easier to get it from RootDSE. Maybe you should 
open an ITS for this.

-- 
Clément OUDOT
Responsable LinID - http://linid.org


Mime
View raw message