Project reorganization proposal

[Emmanuel Lecharny <el...@apache.org>]

Hi guys,

it's now one week ApacheConference EU is over and we had time to recover 
(barely) from this very interesting event. As Alex is still in Paris, we 
also had time to share some ideas about the internal project 
organization (I'm specifically refering the source base, not about the 
people and roles here). Let me now share those ideas with the dev list.

We currently have a few 'top level' projects :
* Apache DS 1.0
* Apache DS 1.5
* Studio
* Triplesec

Those are the projects a user can see on the web site. It's maybe time 
to change that a bit. We could have something like :
* LDAP Client-API
* ApacheDS
  o ADS 1.0 (will die some day ...)
  o ADS 1.5 (won't survive 2.0)
  o ADS 2.0 (soon !)
* Studio
* Kerberos
* Triplesec

- The LDAP client-API will be a new project, marked as 'WiP' (Work in 
Progress).
- Kerberos may deserves its own project at some point, if we have 
aenough committers working on it. Obviously will be marked as WiP. The 
big advantage wpuld be to potentially bring more visibility to this project
- Triplesec should also be marked as WiP, or even better, 'prototype'.

Now, let's think about the inner modules. The new client-API will 
contain a lot of shared code. Here are the elements I see can be part of 
the client-API :
o Entry
o Connection
o LDIF
o DSML
o DN
o RDN
o AttributeTypeAndValue
o ObjectClass
o AttributeType
o Syntax
o MatchingRule
o Message (all the LDAP requests)

Then we can change the dependencies : the client-API will depend from 
shared, and all other modules will depend on both client-API and shared. 
That does not change drastically the ApacheDS project though.

May be we can rename Client-API to Apache LDAP API too, as the server 
will depend on the client-API.

wdyt ?



-- 
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org

Re: Project reorganization proposal

[Alex Karasulu <ak...@gmail.com>]

Hi all,

On Fri, Apr 3, 2009 at 1:44 PM, Emmanuel Lecharny <el...@apache.org>wrote:

> We currently have a few 'top level' projects :
> * Apache DS 1.0
> * Apache DS 1.5
> * Studio
> * Triplesec
>
> Those are the projects a user can see on the web site. It's maybe time to
> change that a bit. We could have something like :
> * LDAP Client-API
> * ApacheDS
>  o ADS 1.0 (will die some day ...)
>  o ADS 1.5 (won't survive 2.0)
>  o ADS 2.0 (soon !)
> * Studio
> * Kerberos
> * Triplesec
>

I was thinking of offlining tsec but I think after 2.0 it will be easier
than ever to resusitate her.  +1 to a Kerberos project to attract more
talent and users specifically into Kerberos and clients for Kerberos.


>
> - The LDAP client-API will be a new project, marked as 'WiP' (Work in
> Progress).
> - Kerberos may deserves its own project at some point, if we have aenough
> committers working on it. Obviously will be marked as WiP. The big advantage
> wpuld be to potentially bring more visibility to this project
> - Triplesec should also be marked as WiP, or even better, 'prototype'.
>

+1

A year from today we can re-evaluate what to do with projects whose status
have not yet changed.


>
> Now, let's think about the inner modules. The new client-API will contain a
> lot of shared code. Here are the elements I see can be part of the
> client-API :
> o Entry
> o Connection



>
> o LDIF


Would like to leave LDIF handling code in shared.  I don't know if this is a
good idea though.  This is not really client related nor server related.
Both the client and the server will use this.


>
> o DSML



>
> o DN
> o RDN
> o AttributeTypeAndValue
> o ObjectClass
> o AttributeType
> o Syntax
> o MatchingRule
> o Message (all the LDAP requests)
>

I think all of these have as much a reason to be in shared as they do in the
client package.  Also I think that you might want to have some simpler API
in the client then just taking what's in shared and pushing it into client.
Reason being is most of this stuff has been crafted for server use although
it certainly can be used for the client.

I just think we're better off just creating what seems to be a redundant set
of classes for client but just keeping it all really simple and specialized
rather than trying to make something work for more than one scenario.

Alex

Re: Project reorganization proposal

[Emmanuel Lecharny <el...@apache.org>]

Christine Koppelt wrote:
> Hi Emmanuel,
>
> the Kerberos stuff is quite broken atm mainly due to a lack of
> reliable unit tests (for example [1]) and the whole
> bigbang-mina2-merging thing. So far it's not such a big thing to fix
> it. I started with it last week and at the moment it's at least
> possible again to start the server and obtain TGTs (will write another
> mail about this after doing a bit more tests), but I fear if there is
> another big reorganisation of the whole codebase it would be much
> harder to fix.
>   
First, I would like to thank you for having made the server working again !

About the reorg, it's nothing but urgent. It's just a proposal, and 
unless the server is back to normal, I don't think we want to mess 
around the classes and such. My perception is that until we have a 
correct configuration system working, we won't move, and it might take 
at least a couple of month.

> My suggestion: Fix the stuff, so that the server has at least the
> kerberos functionality it had back in 1.5.1, and, more important, add
> unit-tests that reliable test the whole functionality. 
Totally +1 with that !
> If we then have
> at least 2+x (x>=0) committers for it, I will support this proposal.
>   
Can I vote more than once ? ;)
> I'm willing to work on the Kerberos server further, but don't have
> that much time atm. Kiran, it would be great if you could also have a
> look at it.
>   
FYI, I have started to rewrite a big part of the codec. I started 2 
years ago, and never had time to finish, due to some personnal issue. 
But I still have all the code I have modified, which represent around 
70% of the necessary modifications. I have partially started to inject 
those modifications into trunk, but only 20% is done.

Although, I would like everyone to consider another idea : creating a 
new JIRA for kerberos (DIR-KERBEROS) where we can store all the kerberos 
related issues. Does it make sense to you guys ?

Thanks a lot Christine !

-- 
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org

Re: Project reorganization proposal

[Christine Koppelt <ck...@apache.org>]

Hi Emmanuel,

the Kerberos stuff is quite broken atm mainly due to a lack of
reliable unit tests (for example [1]) and the whole
bigbang-mina2-merging thing. So far it's not such a big thing to fix
it. I started with it last week and at the moment it's at least
possible again to start the server and obtain TGTs (will write another
mail about this after doing a bit more tests), but I fear if there is
another big reorganisation of the whole codebase it would be much
harder to fix.

My suggestion: Fix the stuff, so that the server has at least the
kerberos functionality it had back in 1.5.1, and, more important, add
unit-tests that reliable test the whole functionality. If we then have
at least 2+x (x>=0) committers for it, I will support this proposal.
I'm willing to work on the Kerberos server further, but don't have
that much time atm. Kiran, it would be great if you could also have a
look at it.

regards,

Christine

[1] http://issues.apache.org/jira/browse/DIRSERVER-1341



2009/4/3 Emmanuel Lecharny <el...@apache.org>:
> Hi guys,
>
> it's now one week ApacheConference EU is over and we had time to recover
> (barely) from this very interesting event. As Alex is still in Paris, we
> also had time to share some ideas about the internal project organization
> (I'm specifically refering the source base, not about the people and roles
> here). Let me now share those ideas with the dev list.
>
> We currently have a few 'top level' projects :
> * Apache DS 1.0
> * Apache DS 1.5
> * Studio
> * Triplesec
>
> Those are the projects a user can see on the web site. It's maybe time to
> change that a bit. We could have something like :
> * LDAP Client-API
> * ApacheDS
>  o ADS 1.0 (will die some day ...)
>  o ADS 1.5 (won't survive 2.0)
>  o ADS 2.0 (soon !)
> * Studio
> * Kerberos
> * Triplesec
>
> - The LDAP client-API will be a new project, marked as 'WiP' (Work in
> Progress).
> - Kerberos may deserves its own project at some point, if we have aenough
> committers working on it. Obviously will be marked as WiP. The big advantage
> wpuld be to potentially bring more visibility to this project
> - Triplesec should also be marked as WiP, or even better, 'prototype'.
>
> Now, let's think about the inner modules. The new client-API will contain a
> lot of shared code. Here are the elements I see can be part of the
> client-API :
> o Entry
> o Connection
> o LDIF
> o DSML
> o DN
> o RDN
> o AttributeTypeAndValue
> o ObjectClass
> o AttributeType
> o Syntax
> o MatchingRule
> o Message (all the LDAP requests)
>
> Then we can change the dependencies : the client-API will depend from
> shared, and all other modules will depend on both client-API and shared.
> That does not change drastically the ApacheDS project though.
>
> May be we can rename Client-API to Apache LDAP API too, as the server will
> depend on the client-API.
>
> wdyt ?
>
>
>
> --
> --
> cordialement, regards,
> Emmanuel Lécharny
> www.iktek.com
> directory.apache.org
>
>
>

Re: Project reorganization proposal

[Felix Knecht <fe...@apache.org>]

Emmanuel Lecharny schrieb:
> Hi guys,
> 
> it's now one week ApacheConference EU is over and we had time to recover
> (barely) from this very interesting event. As Alex is still in Paris, we
> also had time to share some ideas about the internal project
> organization (I'm specifically refering the source base, not about the
> people and roles here). Let me now share those ideas with the dev list.
> 
> We currently have a few 'top level' projects :
> * Apache DS 1.0
> * Apache DS 1.5
> * Studio
> * Triplesec
> 
> Those are the projects a user can see on the web site. It's maybe time
> to change that a bit. We could have something like :
> * LDAP Client-API
> * ApacheDS
>  o ADS 1.0 (will die some day ...)
>  o ADS 1.5 (won't survive 2.0)
>  o ADS 2.0 (soon !)
> * Studio
> * Kerberos
> * Triplesec

+1 (including Groovy API)
+1 for Apache LDAP API

Regards
Felix

Re: Project reorganization proposal

[Stefan Seelmann <se...@apache.org>]

Hi,

> Those are the projects a user can see on the web site. It's maybe time
> to change that a bit. We could have something like :
> * LDAP Client-API
> * ApacheDS
>  o ADS 1.0 (will die some day ...)
>  o ADS 1.5 (won't survive 2.0)
>  o ADS 2.0 (soon !)
> * Studio
> * Kerberos
> * Triplesec

I think this structure makes sense.

But as the projects depend on each other we must make sure that we don't
break one project when we change another. In the past we had the problem
that shared was changed and this change broke studio. When we have more
subprojects this could happen more likely. I think the best solution
would be to define clear and stable APIs between the projects, something
we just started with the Client API.

Kind Regards,
Stefan

Re: Project reorganization proposal

[Stefan Zoerner <st...@labeo.de>]

Emmanuel Lecharny wrote:
 > ...
> Those are the projects a user can see on the web site. It's maybe time 
> to change that a bit. We could have something like :
> * LDAP Client-API
> * ApacheDS
>  o ADS 1.0 (will die some day ...)
>  o ADS 1.5 (won't survive 2.0)
>  o ADS 2.0 (soon !)
> * Studio
> * Kerberos
> * Triplesec

Good idea. Having different versions of ApacheDS toplevel (as it is 
currently the case) makes it hard to maintain the documentation. Your 
approach is better w.r.t. segregating general parts (e.g. "New to 
LDAP?") from version specific stuff (e.g. configuration)

> - The LDAP client-API will be a new project, marked as 'WiP' (Work in 
> Progress).

Groovy LDAP would find a place here as well (marked as WiP as well), as 
you have already suggested.

> ...
> 
> May be we can rename Client-API to Apache LDAP API too, as the server 
> will depend on the client-API.
> 
> wdyt ?
> 

I like your ideas.
+1

Greetings from Hamburg,
     Stefan

Re: Project reorganization proposal

[ayyagarikiran <ay...@gmail.com>]

hi Emmanuel,

    This sounds good

> Those are the projects a user can see on the web site. It's maybe time 
> to change that a bit. We could have something like :
> * LDAP Client-API
> * ApacheDS
>  o ADS 1.0 (will die some day ...)
can we take this completely off
> * Kerberos
> * Triplesec
> 
+1 for both, I think in our roadmap we have plans to improve kerberos and I am interested to work on it
    as soon as we are done with replication

> - The LDAP client-API will be a new project, marked as 'WiP' (Work in 
> Progress).
> - Kerberos may deserves its own project at some point, if we have 
> aenough committers working on it. Obviously will be marked as WiP. The 
> big advantage wpuld be to potentially bring more visibility to this project
> - Triplesec should also be marked as WiP, or even better, 'prototype'.

> May be we can rename Client-API to Apache LDAP API too,
Apache LDAP API would be a good option, but anyone has any catchy name(s) in their mind ;)

Kiran Ayyagari

Re: Project reorganization proposal

[Pierre-Arnaud Marcelot <pa...@marcelot.net>]

On Fri, Apr 3, 2009 at 2:17 PM, Emmanuel Lecharny <el...@apache.org>wrote:

>
>>  Oops ! May be a good idea to put it into the LDAP API ? We may have API
> for Java, Groovy, C#, ...


Very good idea!

P-A

Re: Project reorganization proposal

[Emmanuel Lecharny <el...@apache.org>]

Pierre-Arnaud Marcelot wrote:
> Hi Emmanuel,
> On Fri, Apr 3, 2009 at 1:44 PM, Emmanuel Lecharny <el...@apache.org>wrote:
>
>   
>> Hi guys,
>>
>> it's now one week ApacheConference EU is over and we had time to recover
>> (barely) from this very interesting event. As Alex is still in Paris, we
>> also had time to share some ideas about the internal project organization
>> (I'm specifically refering the source base, not about the people and roles
>> here). Let me now share those ideas with the dev list.
>>
>> We currently have a few 'top level' projects :
>> * Apache DS 1.0
>> * Apache DS 1.5
>> * Studio
>> * Triplesec
>>
>> Those are the projects a user can see on the web site. It's maybe time to
>> change that a bit. We could have something like :
>> * LDAP Client-API
>> * ApacheDS
>>  o ADS 1.0 (will die some day ...)
>>  o ADS 1.5 (won't survive 2.0)
>>  o ADS 2.0 (soon !)
>> * Studio
>> * Kerberos
>> * Triplesec
>>     
>
>
> This looks good.
> +1
>
> What about Stefan's Groovy LDAP?
>   
Oops ! May be a good idea to put it into the LDAP API ? We may have API 
for Java, Groovy, C#, ...

Wdyt ?

-- 
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org

Re: Project reorganization proposal

[Pierre-Arnaud Marcelot <pa...@marcelot.net>]

Hi Emmanuel,
On Fri, Apr 3, 2009 at 1:44 PM, Emmanuel Lecharny <el...@apache.org>wrote:

> Hi guys,
>
> it's now one week ApacheConference EU is over and we had time to recover
> (barely) from this very interesting event. As Alex is still in Paris, we
> also had time to share some ideas about the internal project organization
> (I'm specifically refering the source base, not about the people and roles
> here). Let me now share those ideas with the dev list.
>
> We currently have a few 'top level' projects :
> * Apache DS 1.0
> * Apache DS 1.5
> * Studio
> * Triplesec
>
> Those are the projects a user can see on the web site. It's maybe time to
> change that a bit. We could have something like :
> * LDAP Client-API
> * ApacheDS
>  o ADS 1.0 (will die some day ...)
>  o ADS 1.5 (won't survive 2.0)
>  o ADS 2.0 (soon !)
> * Studio
> * Kerberos
> * Triplesec


This looks good.
+1

What about Stefan's Groovy LDAP?


> - The LDAP client-API will be a new project, marked as 'WiP' (Work in
> Progress).
> - Kerberos may deserves its own project at some point, if we have aenough
> committers working on it. Obviously will be marked as WiP. The big advantage
> wpuld be to potentially bring more visibility to this project
> - Triplesec should also be marked as WiP, or even better, 'prototype'.
>
> Now, let's think about the inner modules. The new client-API will contain a
> lot of shared code. Here are the elements I see can be part of the
> client-API :
> o Entry
> o Connection
> o LDIF
> o DSML
> o DN
> o RDN
> o AttributeTypeAndValue
> o ObjectClass
> o AttributeType
> o Syntax
> o MatchingRule
> o Message (all the LDAP requests)
>
> Then we can change the dependencies : the client-API will depend from
> shared, and all other modules will depend on both client-API and shared.
> That does not change drastically the ApacheDS project though.
>
> May be we can rename Client-API to Apache LDAP API too, as the server will
> depend on the client-API.
>

Just like Kiran, I think the name "Apache LDAP API" really rocks!

Regards,
Pierre-Arnaud