Re: Questionning some parts of the configuration, proposal

>> 3) LdapService
>> This class is now used only once in the ApacheDS class, as we don't need
>> to define one instance to manage LDAP and another one for LDAPS : both
>> are managed through a different transport. As a consequence, a flag is
>> removed (enableSSL) : this flag depends on the SSL enabled transport
>> presence.
>> The getPort() method has been completed with a getportSSL() which
>> returns the LDAPS associated transport port. The getPort() now returns
>> the port for the non SSL transport.
>>    
> Would be good to rename it to _LdapServer_, just to be consistent to the
> naming of the other servers.
>  

>  
>> 4) ApacheDS
>> This class encapsulated the LdapServer and all the other servers. As a
>> direct consequence of the transports modifcations, I have move dmost of
>> the specific configuration up to the LdapService. The second impact is
>> that we don't need to instanciate twice the LdapService (one for LDAP
>> and anotherone for LDAPS), plus the reference to DirectoryService is now
>> useless, as it's already present in the unique LdapService instance.
>>    
> Emmanuel and I just discussed on IRC, it should be possible to get rid
> of the ApacheDS class because it just grouped the LdapServices.
>  

>  
>>  <dnsServer>
>>    <tcpTransports>
>>      <tcpTransport port="8053"/>
>>    </tcpTransports>
>>    <udpTransports>
>>      <udpTransport port="8053"/>
>>    </udpTransports>
>>    <directoryService>#directoryService</directoryService>
>>  </dnsServer>
>>    
>
> This transports configuration looks a bit chatty. A simpler solution
> could be:
>
> <...Server>
>   <transports>
>     <tcpTransport .../>
>     <udpTransport .../>
>   </transports>
> </...Server>
>
> Or
>
> <...Server>
>   <tcpTransport .../>
>   <udpTransport .../>
> </...Server>
>