directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Betts <>
Subject Re: Interest in JXPlorer as a subproject of Directory
Date Mon, 25 Apr 2005 23:58:24 GMT
Hi Folks,

    gosh; what a lot of activity takes place while one' s asleep!  
Running through some of the questions that have been raised...

    Q1: How many active commiters are there?
    ans: Trudi (a colleague at CA) and myself do most of the work; due 
to the vagaries of our source control system it looks like I do a lot 
of the stuff she actually does.  Then there are a large number of 'one 
off' contributions from the user community.  People tend to use JX to 
do a job; when they find it doesn't they sometimes fix it up and send 
us the results.  So we've had a couple of people send us SSL fixes, 
someone sent us a GSSAPI module, we've had four or five people work on 
language translation files, and of course lots of small bug fixes.  
I've been a fascist about handing over commit rights though, and so 
have reviewed all the submissions myself (which creates a bottleneck 
I'd be happy to wriggle out of...).  So the answer is either '2' or 
'~20', depending on how you count :-).

   Q2: Will CA give up their IP rights?
   ans: They already have (check the licence) but I should be able to 
get them to write out something formal.  There's a lot of goodwill 
towards the Apache group in CA and we have commiters in other Apache 

   Q3: SQL-LDAP-JLDAP-SWT-SWING-Hybridization?
   ans: The SQL directory browser looks cool!  JX is architected to 
allow for different 'data brokers' (==providers) to connect to 
different data sources; so there is a broker for JNDI(= LDAP & DSML) 
and another for LDIF at the moment.  The architecture should allow for 
a 'SQL bridge' provider to be added pretty easily, and this would be 
very, very neat.  (There's a reasonable summary diagram of the 
architecture at:  Sometimes it's 
easier to write a jndi provider and use the JNDI broker (e.g. for 
DSML), sometimes it's easier to write a stand alone broker (e.g. for 
LDIF files).

     Re Swing/SWT - I'm not very thrilled with Swing, and if I had my 
time again I'd probably write it in SWT, but I don't know too much 
about it :-).

   Q4: Scripting support?
   ans: The internal code has support for LDIF 'change request' files, 
which I included for testing purposes.  (The overnight tests run a set 
of ldif change files through to put the client code through it's 
paces.)  This code can already be run stand alone; we could brush it up 
and extend it so that it could be used as a proper command line tool 
(at the moment you can only feed it ldif files, but it wouldn't be hard 
to allow for actual ldap mods to be entered on the command line as 
well, although it can be a bit verbose..).  While this is great for 
functionality and regression testing, I don't think JX makes a 
particularly good performance testing tool; I believe the LDIF change 
request code can generate on the order of 100s of requests a second, 
but many directories can handle 1,000s of requests a second.  For flat 
out performance testing small C programs are probably better??

   ... and now, a question from me; If we made JXplorer a subproject of 
Apache DS, would I still be able to maintain the domain as 
a 'front page' (and use it to direct people to the Apache subproject 
site), and would I still be able to ship the stand alone install 
packages for different platforms?  Lots of people use JXplorer for the 
big commercial directories (CA's eTrust, Sun One, etc.) and I need to 
be able to keep supporting them...



View raw message