This is great guys. I also talked to Stefan Seelmann on IRC and he's also interested in working on this. I'm thinking Chris might also be interested as well and he can chime in when he comes online. So for now I'll presume we have the following list of committers:
ckoppelt pamarcelot seelmann ersiner akarasulu ccustine Let me figure out the pieces we can chew off on this below. Just thinking out loud so please chime in. Configuration in DIT (CiD) Team --------------------------------------------- Members: pamarcelot seelmann akarasulu Aim: Move configuration parameters within the server.xml file into the DIT using a custom configuration schema for ApacheDS and Triplesec. For this pass the configuration need not be dynamic which can be retrofitted later. We can use smart defaults when the server starts so users can configure it then restart the server. In the process the Directory Studio guys on the team can expose these configuration parameters in the DIT with custom wizards in Studio however this is not the immediate aim of this effort. Triplesec Schema Team ----------------------------------- Members: akarasulu ccustine ckoppelt ersiner Aim: Redesign the Triplesec schema for cleanup and to support multi-realm configurations. Use triggers and stored procedures instead of a custom interceptor for maintaining referential integrity. Add extension objectClasses for permissions to enable the backing use of various kinds of java.security.Permission instances. Triplesec should be able to be used as a JSE policy store and eventually once we conclude on how as a JACC provider. Use new schema subsystem instead of the old 1.0mechanism. Triplesec Installers Team ------------------------------------ Members: akarasulu ccustine ?? Aim: Migrate installers/boostrappers to support the Tanuki based changes being introduced into the 1.5.x branch by Chris. Handling migration of Jetty into ApacheDS core. Rewrite some existing configuration and web demo applications to leverage CiD and utilize the new Kerberos clients that Enrique is working on. Although somewhat unrelated we have to move the Jetty integration code from Triplesec into ApacheDS so ApacheDS can leverage it and Triplesec becomes lighter. Triplesec Documentation Team --------------------------------------------- Members: akarasulu ?? Aim: Update all documentation to reflect the changes in Triplesec. I think these teams can start working with some good isolation and we will pretty much have all main issues in this list knocked out. Some things like the better use of Maven and logging are horizontal aspects that we can all manage as we deal with our individual issues. I am going to start working in the new triplesec area just moving some basic packages (libs) and doing the package renaming with a clean maven setup. We can work out of the following SVN base: https://svn.apache.org/repos/asf/directory/triplesec/rewrite I guess the next step is to look into some plan of attack for all this. I will try to formulate something we can discuss in another email a few days later. How does this breakdown in labor sound so far? Comments? Suggestions? Alex On 7/3/07, Pierre-Arnaud Marcelot <[EMAIL PROTECTED]> wrote:
I'm also interested in. I'll be happy to give you a hand. Pierre-Arnaud On 7/3/07, Alex Karasulu < [EMAIL PROTECTED]> wrote: > > Hi all, > > For the past couple days I've been looking at migrating Triplesec > packages and just > cleaning up the project as a whole since it is pretty much a prototype > as it stands > right now. There are a few things in Triplesec that I have problems > with: > > (0) bring all NOTICE and LICENSE files up to date with review > (1) It package names are not org.apache.directory.triplesec based > (2) It uses ApacheDS 1.0.3 and I would like to start using 1.5.x > (3) It has Jetty integration which I would like to move into ApacheDS > and inherit > (4) The schema is a mess and needs to be cleaned up as well as massaged > to not use > safehaus prefixes. > (5) server.xml file handling to reconfigure the server is a mess with > dom4j based loading > and rewriting so DIT based configuration can significantly clean up > this mess > (6) junit extensions for integration testing is causing issues on > windows and failing > even on linux due to some maven peculiarities with classloaders > (7) very poor logging > (8) lack of HOTP parameterization per account > (9) I would like to remove the interceptor used for referential > integrity and replace it > with triggers and stored procedures > (10) I want the maven build to work using all the tricks we learned to > stop maven > from changing under our feet with snapshotted plugins > (11) rework the installers to use Chris' work with Tanuki and the > various installers > > Right now I would like to build flexibility into the schema and the > format to support > multiple realms. Also I would like to consider flexibility to support > JACC however > it's not the primary aim for now and can be ignored for this quick > rewrite. > > After assessing where we are and what we have to do a rewrite may take > less effort > than wrestling with all the problems we have. Also note that some key > libraries need > not be completely rewritten. > > I have the month of July only to do this if I do set out to do it. I > also need some help > but this rewrite gives a bunch of us (especially the new comers) a > chance to get up > to speed with Triplesec. > > So now I have a few questions for the community: > > (1) Should we do this rewrite which will take a couple weeks off our > schedule but > may give significant advantages in the future? > (2) Who is interested in tackling this with me? > > If we have enough people and agreement then we can just jump in and get > started. > > Alex > >
