Is this progressing? I imagine you guys already know this, but my
copy of triplesec used apacheds 1.5-snapshot from around january and
had what I consider a considerably improved persistence mechanism --
sort of like jdo except you enhance by hand.
I'm hoping to have some time to work on triplesec shortly....
thanks
david jencks
On Jul 9, 2007, at 4:52 AM, Emmanuel Lecharny wrote:
Hi Alex,
I'm +1 for any kind of way for the team to jump into the TSec train.
Having a prototype is a really valuable thing as it demonstrates what
is TSec, but now, if we are to using it more widely, we need to
transform this prototype into a product.
I would say that you should not get invorlved in tasks like 0 and 1,
as we can do that out of band (I already did it for ADS and MINA, it
took me a couple of day, but as I was brain dead, it was perfect)
Task 2 should not be a big issue, and it can helps to do the maven
migration (Task 10).
Task 3 is very important, and must be well documented, as we will use
it for other purposes. May be someone else in the team want to give a
hand ?
Anyway, i'm not 100% sure I will be able to help a lot in the next few
weeks, so please consider me as a little bit off.
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
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
