See inline
On Tue, Jul 14, 2015 at 12:43 PM, Radovan Semancik < [email protected]> wrote: > On 07/14/2015 12:12 PM, Pierre Smits wrote: > >> Is that an achievable goal? Crappy servers pose so many exceptions to the >> rule, that any project, trying to realise a client solution, will >> eventually find that has shot itself in the foot. Of course, no one can >> argue with a contributor scratching his own itch. But shouldn't this be >> done in a separate dev branch, so that trunk isn't affected until such an >> integration is tried, tested and accepted? >> > > It looks like it is not so bad. What we mostly need to do is have an > option to disable various syntax/semantics checks (e.g. like this check for > OID). > And maybe some other things, such as explicit enumeration of attributes to > get from root DSE. But this may be generally useful as an optimization > anyway. > Good to know that the work done is beneficial to overall optimisation of the product. I was just asking to get a better understanding, not condemming in any way. > > I've tested several LDAP servers during part months. And it looks like the > current API only works with ApacheDS in the strict mode. OpenLDAP might be > also to be OK, but may need some fixes as it looks like even RFCs > themselves have lots of exceptions and not all of them are implemented in > the API. All other servers that I have tested fail miserably and require > relaxed/quirks mode to be able to parse the schema. > Maybe we can influence those other products to improve their act as well. Though that might prove disadvantageous to the adoption of our flagship product ApacheDS. > > So I think is it not a question whether we want to have a clean API or > not. It is more a question whether we want to have an API for ApacheDS > (maybe OpenLDAP) .... or whether we want to have API that is also useful > for other major servers that are out there in the wild. We already have > relaxed/quirks mode. Then why not extend it when the required changes are > small? > > I am inclined to agree. I am also keen on keeping in mind that this drives adoption and thus having more contributors to ease your and others' burden. > But I agree that if there is a need for a brutal changes to the API then a > separate branch might be really required. But now all the fixes were > practically only changes in a couple of source code lines and mostly > encapsulated inside their classes (except that pulling up of methods to > interface - and that was the reason I was asking for review). I think that > is quite safe to do in trunk. For now. > > > -- > Radovan Semancik > Software Architect > evolveum.com > > Best regards, Pierre Smits *ORRTIZ.COM <http://www.orrtiz.com/>* Services & Solutions for Cloud- Based Manufacturing, Professional Services and Retail & Trade http://www.orrtiz.com
