Mailing-List: contact directory-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List"
 <directory-dev@incubator.apache.org>
Received-SPF: pass (hermes.apache.org: local policy)
Message-ID: <41D4BF36.8@steitz.com>
Date: Thu, 30 Dec 2004 21:53:42 -0500
From: Phil Steitz <phil@steitz.com>
User-Agent: Mozilla Thunderbird 1.0RC1 (X11/20041201)
MIME-Version: 1.0
To: Apache Directory Developers List <directory-dev@incubator.apache.org>
Subject: Re: Question about project names.
References: <768dcb2e04122818221869788d@mail.gmail.com>
 <3744050C-5ABD-11D9-B3AF-000D93324AD6@gbiv.com>
 <41D4A3A0.9040508@bellsouth.net>
In-Reply-To: <41D4A3A0.9040508@bellsouth.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Alex Karasulu wrote:
> Roy T. Fielding wrote:
>>
> <snip/>
> 
>> FYI, I really don't like this trend of independent projects being created
>> within umbrella projects.  If you are creating a generic toolkit then
>> it should be incubated as a separate project.  
> 
> 
> This toolkit was in part derived from the shortcommings of the seda 
> subproject.  Originally there was an ldap frontend that was protocol 
> specific.  We made it independent of protocol and called it seda so 
> other servers can use it. MINA is a complete rewrite of the frontend 
> code to solve some of the problems with the seda implementation.
> 
> Our intention is not to create all these projects under the Directory 
> umbrella to mask anything.  There is no need to presume anyone is trying 
> to dupe the ASF.  What is happening is a consequence of writing code 
> that can be reusable.  Plus this is a vast subject area.  Directories 
> are founded on ASN.1, OSI, TCP/IP and other concepts.  We're not 
> building a small library here.  There's just so much that goes into 
> building a directory server.  A great example is the ASN.1 code.  It is 
> reusable and can be used for protocols other than LDAP like SNMP.  I 
> would imagine that it could be split off to become standalone.  This is 
> the problem of dealing with such a large effort which depends on so many 
> other technologies.  What are we to do?
> 
> Personally I speaking for myself I have a hand in all these projects 
> minus naming.  There is cross reactivity of other individuals as well.

I agree, and the last point is key -- I am afraid that if we split 
things up we may lose some of that.
> 
>> IMO there are too many
>> single-developer products being masked under the Directory umbrella,
>> rather than a coherent group of individuals working together on a
>> single product (and thus having sufficient voters to make collaborative
>> decisions about that product).  
> 
> 
> Ok perhaps you're right. But we need all these peices. Perhaps we should 
> just incubate a little longer or split it all up.  Directory is slated 
> to be a TLP project and subprojects underneath it are expected.  However 
> I do recommend budding some things off.  For example seda (or whatever 
> it is to be called), MINA, sedang can go into a newtorking toolkit 
> effort.  I just did not want to do it now since we created it for Eve in 
> the incubator.

This is a hard one.  I think we all agree that Roy has a point there -- 
we need more collaboration. This is very important, not just for the 
community but to make sure we have enough oversight.  Now that I have 
[naming] into a releasable state I will start meddling -- er, helping 
;-) -- in some of the other subprojects.
> 
> Jakarta gave birth to several projects because of the size of the 
> undertaking and the same has happened to us.  Question is how do we 
> manage this.  Right now Trustin and Berin have taken a massive load off 
> of of the LDAP specific focus by taking care of the networking code.  
> I'm glad its happening to free up minds to put more energy on LDAP 
> specific stuff.  Wes McKean helped with the project formerly known as 
> Snickers and Alan Cabrera is helping too so this also takes load off.  
> You see the trend I'm sure.
> 
>> This is just my concern, but please
>> understand that we didn't create Directory in order for it to become
>> another Jakarta or Avalon.
> 
> Are you suggesting we split Directory apart into separate projects 
> within the incubator?  We could do that.  We could split most of it 
> appart.  We could put all the frontend stuff together as one project for 
> a set of networking toolkits. I think this has enough critical mass in 
> terms of interest and users to graduate quickly.  We could split the 
> naming, asn.1and kerberos subprojects into separate projects to be 
> incubated separately.  Then we can split ldap and eve (renamed of 
> course) into the real Directory project.  The ASN.1 stuff (old Snickers) 
> can also be split off.  Likewise the Kerberos server should be split too.
> 
> BTW I asked on #asf to see what people's opinions are.  Noel and Brett 
> Porter thought it makes sense to keep it together since thsee projects 
> are all interrelated and used.  Personally I would rather address your 
> concerns now and split if we have to.  We can still work with this code 
> to build an LDAP server even if it is in different incubator projects.  
> It will just be inconvenient but hardly impossible to do.

FWIW, I am in the keep it together camp.  I think there is *great* 
potential in Directory and its community.  Partly because of the size of 
the problem space and the great talent assembled, things have sort of 
taken off a little independently. Roy is giving us good feedback and we 
need to listen to it, but I don't think we need to split things up just 
yet and I think it would be a mistake to do so.

Also, while I applaud your openness and flexibility above, unless we 
break *everything* apart, seems to me that we end up forced into 
unnatural acts of division. Also, I don't think all the little pieces 
separately would be able to attract communities. [naming], for example 
is a useful little component that would never make sense as a TLP.  I 
suppose we could - sniff - go back home to Jakarta Commons; but that 
seems silly and we need to JNDI-knowledgable eyeballs here.

Phil

> 
> Alex
>