directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <>
Subject Re: [Triplesec] Thinking of a quick rewrite
Date Tue, 03 Jul 2007 12:34:02 GMT
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
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
   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
   Use triggers and stored procedures instead of a custom interceptor for
   referential integrity.  Add extension objectClasses for permissions to
enable the
   backing use of various kinds of 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

   Migrate installers/boostrappers to support the Tanuki based changes being

   introduced into the 1.5.x branch by Chris.  Handling migration of Jetty
   ApacheDS core.  Rewrite some existing configuration and web demo
   applications to leverage CiD and utilize the new Kerberos clients that
   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
try to formulate something we can discuss in another email a few days

How does this breakdown in labor sound so far?  Comments? Suggestions?


On 7/3/07, Pierre-Arnaud Marcelot <> wrote:
> I'm also interested in.
> I'll be happy to give you a hand.
> Pierre-Arnaud
> On 7/3/07, Alex Karasulu <> 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 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
> >
> >

View raw message