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:
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
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
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.0 mechanism.
Triplesec Installers Team
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
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:
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
How does this breakdown in labor sound so far? Comments? Suggestions?
I'm also interested in.
I'll be happy to give you a hand.
Pierre-ArnaudOn 7/3/07, Alex Karasulu < firstname.lastname@example.org> 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
(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.