directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <aok...@bellsouth.net>
Subject Re: [protocol-api] why don't we just call this protocol
Date Thu, 16 Dec 2004 15:31:09 GMT
Berin Loritsch wrote:

> Alex Karasulu wrote:
>
>> It's kind of understood that this is a framework api.  I want to 
>> avoid hyphenated project names...
>>
>> Dat cool?
>> Alex
>>
> NP
>
> However I did want to differentiate it from a different "protocols" 
> directory that housed the
> protocol handler implementations for LDAP/Kerberos/etc.
>
Hmmmmm ..... Ok lemme just describe my take on this ...

The protocol provider (implementations) are very project specific.  
Meaning the LDAP provider would go where Eve goes or the Kerberos 
provider would go where Kerberos goes et. cetera.  Why would we split 
the protocol provider with handlers apart from the protocol servers? 

I admit that for now it looks good having all providers under one area 
because we're all under the same umbrella.  I don't think however SEDA, 
MINA and sedang belong here at directory.  Forseeably they will go into 
either jakarta or some kind of networking tlp.  It makes sense for the 
ASF to do this so other projects can use them without having the feeling 
they are tying themselves to Directory.  It's like having a aspect based 
TLP like logging.  Nothing about SEDA, sedang or MINA is specific to 
Directory.  Imposing upon users to have imports from the directory 
project to build for exampel an sftp server would be a mistake.  
Furthermore it would limit how open people are to actually using the API.

So with that in mind it's presumable that the protocol provider 
implementations will stick to where the protocol server resides.  For 
the directory project it makes sense to keep the LDAP protocol provider 
here.  I would not want the LDAP provider to leave the Directory 
project.  This would not make sense as you would probably agree.

I like your motives for the reorg but I think we need to thining about 
the big picture.  Then again with svn we can arrange and then 
rearrange.  However I don't want to waste time rearranging to often.

Alex


Mime
View raw message