[Esapi-user] [Esapi-dev] What can I do next for ESAPI?

Kevin W. Wall kevin.w.wall at gmail.com
Sun Aug 1 23:33:53 EDT 2010

Chris Schmidt wrote:
> I concur that #1 [breaking out ESAPI core and components into modules
> and/or separate jars] is far more important and needs to happen first - I would
> also contest that making any other serious enhancement before that happens
> would not be the best way to go. There is already quite a bit to do in
> separating all the pieces of esapi into components.

I think this should be the top longer-term priority, but I think it will
be a major architectural shift and thus I can't see it happening until
ESAPI 3.0 (or at least ESAPI 2.1).

I was mostly looking for things that could be done in no more than a
month of my free time. Bug fixes and small incremental improvements
are probably best if they are to go into 2.0.

I don't have any problems trying to start on requirements / specs for
the next release that is aimed at breaking out the ESAPI dependencies
so one doesn't have to drag in half the Java universe just to use
one component such as the ESAPI encoders.  If we want to start working on
that now, I think the first order of business is what do we want to use
for the dependency injection (aka, IoC)--e.g., PicoContainer, Spring,
roll-our-own, etc. There are pros & cons of each. And probably the
second order of business is what release should we plan it for 2.1 or
3.0, if only because we need a branch to build it on and more importantly
we need to know how much change is acceptable? (IMO, in keeping with standard
FOSS release strategy, if it existing changes ESAPI interfaces, it has to go
in 3.0; if not release 2.1 is acceptable.)

Anyone have any opinions on this? I'd like to hear from the ESAPI user
community (both current and likely future users) as well as ESAPI developers.

Also, note to Jim and Jeff: Is there anything that I can do to assist the
NSA code inspection to move forward? E.g., write up something describing the new
crypto design, etc.? I think *what* I wanted reviewed was already described but
am willing to embellish that as well if it will help.

Kevin W. Wall
"The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents."        -- Nathaniel Borenstein, co-creator of MIME

More information about the Esapi-user mailing list