Return-Path: X-Original-To: apmail-directory-dev-archive@www.apache.org Delivered-To: apmail-directory-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 4E54A17823 for ; Tue, 14 Jul 2015 11:00:56 +0000 (UTC) Received: (qmail 30193 invoked by uid 500); 14 Jul 2015 11:00:56 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 30138 invoked by uid 500); 14 Jul 2015 11:00:56 -0000 Mailing-List: contact dev-help@directory.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Apache Directory Developers List" Delivered-To: mailing list dev@directory.apache.org Received: (qmail 30128 invoked by uid 99); 14 Jul 2015 11:00:55 -0000 Received: from Unknown (HELO spamd2-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 14 Jul 2015 11:00:55 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd2-us-west.apache.org (ASF Mail Server at spamd2-us-west.apache.org) with ESMTP id 80EC21A6F38 for ; Tue, 14 Jul 2015 11:00:55 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd2-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 2.9 X-Spam-Level: ** X-Spam-Status: No, score=2.9 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=disabled Authentication-Results: spamd2-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-us-east.apache.org ([10.40.0.8]) by localhost (spamd2-us-west.apache.org [10.40.0.9]) (amavisd-new, port 10024) with ESMTP id Df8XF2Nvthc3 for ; Tue, 14 Jul 2015 11:00:46 +0000 (UTC) Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) by mx1-us-east.apache.org (ASF Mail Server at mx1-us-east.apache.org) with ESMTPS id 37604428DB for ; Tue, 14 Jul 2015 11:00:46 +0000 (UTC) Received: by wicmv11 with SMTP id mv11so11079623wic.1 for ; Tue, 14 Jul 2015 04:00:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=ubZKG3C21HuAAk2ckEZ1fVbx5gc5rhOZWgpND/+2d+E=; b=xZFgWSbqrgQzN4YjKP/bA9c/sKDvvgSkEXJxtxEWoYdv0N97Zx4va6t+SCeatHWiW1 PgEvC9wUR8kSyTaUU/1T3u7YxS7MTYbwEDKPyyTP1MuJK5VPpdT5LVwgGM+SsKSZeItN p0Gk9QiKjhwoKyv0lWfBYextnfmHO3FG6CwRT/8JP7LpM5a34Fep5J/HFs7KbXTEHSI9 6iFZwF36Diza2bfb8UkDdJmnxRAMZ7PPgi/tLnQ4U1OfqbpWHmaEeCVKKFVEyA0QHRlq bExuxOEdf+4byvg+xPBY4ddvfW9SjDXyTNPvtW7yVtzIVEpIgPUwV8568RGQlqc/NXEl voMg== MIME-Version: 1.0 X-Received: by 10.194.23.36 with SMTP id j4mr77140410wjf.105.1436871645443; Tue, 14 Jul 2015 04:00:45 -0700 (PDT) Received: by 10.27.201.135 with HTTP; Tue, 14 Jul 2015 04:00:45 -0700 (PDT) In-Reply-To: <55A4E7BD.4000606@evolveum.com> References: <55A4CD24.3080600@evolveum.com> <55A4D8A6.7060002@gmail.com> <55A4DEC3.2030600@evolveum.com> <55A4E7BD.4000606@evolveum.com> Date: Tue, 14 Jul 2015 13:00:45 +0200 Message-ID: Subject: Re: 389 Directory Server support in API From: Pierre Smits To: Apache Directory Developers List Content-Type: multipart/alternative; boundary=047d7b3a91b203bf9a051ad3c016 --047d7b3a91b203bf9a051ad3c016 Content-Type: text/plain; charset=UTF-8 See inline On Tue, Jul 14, 2015 at 12:43 PM, Radovan Semancik < radovan.semancik@evolveum.com> 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 * Services & Solutions for Cloud- Based Manufacturing, Professional Services and Retail & Trade http://www.orrtiz.com --047d7b3a91b203bf9a051ad3c016 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
See inline



On Tue, Jul 14, 2015 at 12:43 PM, Radovan Se= mancik <radovan.semancik@evolveum.com> wrote:
On 07/14/2015 12:12 PM, Pierre Smits wro= te:
Is that an achievable goal? Crappy servers pose so many exceptions to the r= ule, 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 se= parate dev branch, so that trunk isn't affected until such an integrati= on 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 anyw= ay.

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.
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa= dding-left:1ex">
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 thems= elves have lots of exceptions and not all of them are implemented in the AP= I. 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 we= ll. Though that might prove disadvantageous to the adoption of our flagship= product ApacheDS.=C2=A0
=C2=A0

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 O= penLDAP) .... 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/quirk= s 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 yo= ur and others' burden.=C2=A0
=C2=A0
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 practi= cally 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 t= o do in trunk. For now.


--
Radovan Semancik
Software Architect
evolve= um.com

Best regards,

Pierre Smits

<= font size=3D"4">ORRTIZ= .COM
Services & Solutions for= Cloud-
Based Manufacturing, Professional=
Services and Retail & Trade
--047d7b3a91b203bf9a051ad3c016--