Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 55529 invoked from network); 14 Sep 2010 10:50:50 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 14 Sep 2010 10:50:50 -0000 Received: (qmail 24752 invoked by uid 500); 14 Sep 2010 10:50:50 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 24406 invoked by uid 500); 14 Sep 2010 10:50:47 -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 24399 invoked by uid 99); 14 Sep 2010 10:50:46 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 14 Sep 2010 10:50:46 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of akarasulu@gmail.com designates 209.85.216.171 as permitted sender) Received: from [209.85.216.171] (HELO mail-qy0-f171.google.com) (209.85.216.171) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 14 Sep 2010 10:50:41 +0000 Received: by qyk30 with SMTP id 30so2925511qyk.16 for ; Tue, 14 Sep 2010 03:50:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=0K5vNMNfqgMa4Xn/SzN2dkivF85+fcAHL7hirA7B00g=; b=njHV7pwdIGOyRt0HKyHZXtAVOYQd+yo48luy1SOW6QftdhSZtmowaM/SQuXrkbjqAs 6gWpmDU47eyFDHxXTyonqdOy1HAc8KeJN1HbGR/fZ+4EA5GJ8GD0BbhbP53QTRqeVUS5 0H2DRMviJaQXWREjRBpWJTJaTBGpkm6Tc6evI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=quiZFGr0qN2KIKmFX1E17J241jtFG6LWZYVCUSqUCizKt4LBF19ZMUI5ilx8dTtnYB 6ZZNG5Ih4y45XLuPD35NtPEWvBOMnt+jSimqE4DVe2zjJA7gGFBBUy2Off/aIaEQslwl 2qzWh1TL43/D4zQhZBtpiwWoCGOfASw9dYjjM= MIME-Version: 1.0 Received: by 10.229.89.15 with SMTP id c15mr4232730qcm.202.1284461420962; Tue, 14 Sep 2010 03:50:20 -0700 (PDT) Sender: akarasulu@gmail.com Received: by 10.229.248.72 with HTTP; Tue, 14 Sep 2010 03:50:20 -0700 (PDT) In-Reply-To: References: <4C88F910.7010005@gmail.com> Date: Tue, 14 Sep 2010 13:50:20 +0300 X-Google-Sender-Auth: ILyeJMXUYWyV72fU6-Ha9alffLk Message-ID: Subject: Re: API / shared merge From: Alex Karasulu To: Apache Directory Developers List Content-Type: multipart/alternative; boundary=00163646d804b9669a049035fa2e --00163646d804b9669a049035fa2e Content-Type: text/plain; charset=ISO-8859-1 On Thu, Sep 9, 2010 at 11:19 PM, Kiran Ayyagari wrote: > On Fri, Sep 10, 2010 at 12:39 AM, Stefan Seelmann > wrote: > > On Thu, Sep 9, 2010 at 5:11 PM, Emmanuel Lecharny > wrote: > >> Hi guys, > >> > >> it seems that when I did the big modification (merging all the Messages) > >> last month, I forgot to uncomment the dsml-parser which is part of > shared. > >> > >> I had it working by pointing to the ldap-api project, as it now depends > on > >> it, but that was not enough to be able to build it when uncommented in > the > >> shared/pom.xml file, as shared does not depend on ldap-api. > >> > >> However, in my mind, the next step was to integrate the ldap-api project > >> into shared (well, imo, shared <==> ldap API up to a point). > >> > >> Here is what I suggest we do : > >> - move ldap-client into shared > >> - rename shared to ldap-api > >> - move all the DIR-SHARED issues to DIRAPI > >> - and release ldap-api > > > > I agree and would like to discuss some more steps before releasing the > API: > > - should we rename the package names o.a.d.shared or keep it? > this will be a huge a change, IMO we should keep it as it is for now > > - about the number of modules, should we merge some? Especially the > > ldap-schema* modules contain only 10 classes splitted into 3 modules. > > - the shared-ldap module contains some packages that are not directly > not quite sure about these, I think there are some dependency issues with > these > > related to a client API: aci, sp, trigger, subtree.Should we still > > keep them in the ldap-api project or move them to a server module? > we should move them all out of api except ACI, cause studio can use the > ACI parser and also we might provide some easy to use api for > setting and storing ACI programmatically > Again this is a problem because we're trying to turn shared into API and these are not interchangeable I think. Things in shared are not for API. We should step carefully. > > > > At last before publishing an API we should decide which classes we > > consider as public API and which classes are for internal use only. > yeah, but am afraid it will delay the release by few more days > > > > I agree with your words of caution. As long as there are doubts and we've not done everything in terms of mapping out what exists and the several levels of problems that could result we might want to not do this right now. It will take a long time to do this properly. A quick rearrangement that is not thorough will just require us to do this again. And this might piss off our users needlessly. -- Alex Karasulu My Blog :: http://www.jroller.com/akarasulu/ Apache Directory Server :: http://directory.apache.org Apache MINA :: http://mina.apache.org To set up a meeting with me: http://tungle.me/AlexKarasulu --00163646d804b9669a049035fa2e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Sep 9, 2010 at 11:19 PM, Kiran A= yyagari <kayya= gari@apache.org> wrote:
On Fri, Sep 10, 2010 at 12:39 AM, Stefan Seelmann <seelmann@apache.org> wrote:
> On Thu, Sep 9, 2010 at 5:11 PM, Emmanuel Lecharny <elecharny@gmail.com> wrote:
>> =A0Hi guys,
>>
>> it seems that when I did the big modification (merging all the Mes= sages)
>> last month, I forgot to uncomment the dsml-parser which is part of= shared.
>>
>> I had it working by pointing to the ldap-api project, as it now de= pends on
>> it, but that was not enough to be able to build it when uncommente= d in the
>> shared/pom.xml file, as shared does not depend on ldap-api.
>>
>> However, in my mind, the next step was to integrate the ldap-api p= roject
>> into shared (well, imo, shared <=3D=3D> ldap API up to a poi= nt).
>>
>> Here is what I suggest we do :
>> - move ldap-client into shared
>> - rename shared to ldap-api
>> - move all the DIR-SHARED issues to DIRAPI
>> - and release ldap-api
>
> I agree and would like to discuss some more steps before releasing the= API:
> - should we rename the package names o.a.d.shared or keep it?
this will be a huge a change, IMO we should keep it as it is for now<= br>
> - about the number of modules, should we merge some?= Especially the
> ldap-schema* modules contain only 10 classes splitted into 3 modules.<= br> > - the shared-ldap module contains some packages that are not directly<= br>
not quite sure about these, I think there are some dependency issues = with these
> related to a client API: aci, sp, trigger, subtree.S= hould we still
> keep them in the ldap-api project or move them to a server module?
we should move them all out of api except ACI, cause studio can use t= he
ACI parser and also we might provide some easy to use api for
setting and storing ACI programmatically

Again this is a problem because we're trying to turn shared into API = and these are not interchangeable I think. Things in shared are not for API= . We should step carefully.
=A0
>
> At last before publishing an API we should decide which classes we
> consider as public API and which classes are for internal use only.
yeah, but am afraid it will delay the release by few more days
>


I agree with your words of cau= tion. As long as there are doubts and we've not done everything in term= s of mapping out what exists and the several levels of problems that could = result we might want to not do this right now. It will take a long time to = do this properly. A quick rearrangement that is not thorough will just requ= ire us to do this again. And this might piss off our users needlessly.

--
Alex Karasulu
My Blog :: http://www.jroller.com/akarasulu/
Apache Directory S= erver :: http://directory.apache.or= g
Apache MINA :: http://mina.apache.org
To set up a meeting with me: http://tungle.me/AlexKarasulu
--00163646d804b9669a049035fa2e--