[OWASP-ESAPI] Naming ESAPI (was "Re: ESAPI for RIA")
Kevin W. Wall
kevin.w.wall at gmail.com
Tue Nov 10 23:15:57 EST 2009
Jeff Williams wrote:
> client languages.
I agree. In fact, this is a bit off the 'ESAPI for RIA' topic (hence switching
Subject header), but I'd like to propose something of a convention for the
names we give the various flavors of ESAPI.
IMO, it can get confusing and we have not been at all consistent on this
mailing list and my concern is that this sloppiness will carry over to
For instance, for the Java implementation of ESAPI, I've seen all of the
following at various times:
ESAPI Java 2.0 and ESAPI Java 1.4
ESAPI for Java EE and ESAPI JavaEE
ESAPI 2.0 and ESAPI 1.4
Java ESAPI and Java ESAPI 1.4 and Java ESAPI 2.0
I am proposing that when we refer to a specific implementation _version_,
we use the convention of:
<prog_language> ESAPI <version>
and if no version is implied,
where <prog_language> is the programming language or environment that
it is intended to primarily be used in and not necessarily the implementation
language (though generally they are the same).
So, for example, we would have
Java ESAPI 2.0, Java ESAPI 1.4, Java ESAPI
.NET ESAPI 1.0, .NET ESAPI
(Don't even think about calling it ECMAScript ESAPI. ;-)
The reason that I prefer this versus the more common style of
ESAPI <prog_lang> <version>
is because their can be confusion as to whether or not <version>
refers to the ESAPI version or the programing language version.
(E.g., consider 'ESAPI Java 1.4' or the hypothetical 'ESAPI PHP 5.2'
or 'ESAPI Python 2.6'.)
I think this will cause less confusion to those new to ESAPI. I've already
faced this issue with Java ESAPI for those at my workplace.
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 OWASP-ESAPI