On 06/11/2015 12:28 PM, Emmanuel Lécharny wrote: > Hi guys, > > a quick heads up on what's going on for the OpenLDAP Config editor, > which is scheduled for the next Studio release > > o The global configuration design is almsot completed. There are now 4 > of the 6 pages that are working : > - 'overview' which deal with general parameters > - 'database' was already working fine > - 'security' has just been completed. It covers all the general security > parameters (SASL, TLS, and a few other parameters) > - 'Tuning' is completed. It covers the parameters that can be tuned > (limits, concurrency, indexes...)
Phew, this is so much boilerplate code to create all the sections and widgets and to listen to modifications and do verifications etc. I didn't implement such editors since years, but wonder if there are simpler (or elegant) ways like automatic data binding between the model and UI elements. > o The Options page has to be added, it covers 15 parameters (currently, > only 4 are covered) > > o Some issue has to be fixed when we try to save the config. This is due > to some delta being computed with some modify being sent when they > should not. I will review the full process this week. Hopefully, I'll > get something working soon. Not sure if this is helpful, or if they can be combined, but we have 3 code parts the compute diffs of entires: * PartitionsDiffComputer in openldap.config.editor * PartitionsDiffComputer in apacheds.config * Utils.computeDiff() in ldapbrowser.core > Next steps : > ------------ > > o Have a way to save the configuration into a LDIF file, if we are not > connected to an OpenLDAP server > o Have a way to read the configuration from a LDIF file, if we are not > connected to an OpenLDAP server > o Check the Databases configuration. There are missing parameters > o Check the Overlays configuration. A dedicated page has to be added for > that > o ACLs editor should be accessible in the configuration > > > Wishes : > -------- > > o It would be good to be able to save a configuration locally, to be > able to revert to it if necessary (à la SVN) Two ideas: * We can include jgit/egit into Studio, that is a full git implementation in Java and for Eclipse * If Mavibot would support transactions/versions this may also be an option to use > o A delta between two configurations would be good to have then > o A defautt configuration should exist, so that we can revert back to it > > Lot's of thing to do, as you can see, but still, good progress too. > > Thanks ! > Thanks for the update.
