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 Fri, 03 Apr 2015 08:08:47 GMT
Le 03/04/15 09:20, Clément OUDOT a écrit :
> 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.
>
Yes, I will. The pb is that the monitor backend is not always setup...

Anyway, tahnks for the info.

Mime
View raw message