jakarta-bsf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Victor J. Orlikowski" <...@dulug.duke.edu>
Subject Re: re-organizing the BSF source tree
Date Fri, 13 Jun 2003 06:43:59 GMT
On Wed, May 07, 2003 at 01:13:09PM +0600, Sanjiva Weerawarana wrote:
> I'd like to re-org the src tree. Are there any willing helpers?
> I think we need the usual structure:
>     jakarta-bsf/
>         src/
>         samples/
>         lib/
>         [whatever other stuff at the top level]
>     jakarta-bsf/src/
>         org/
>             apache/
>                 bsf/
>                     ...
> What's in the taglib, bsf_debug, jsdb directories? How should those
> fit in?

My apologies for the late entry into the discussion; it is only
recently that I have been able to resolve some issues related to
this very topic.

Indeed, the source tree needs a complete re-org; I am certainly
willing to help, or do it myself if no one else beats me to it
(and no one objects to my stance on the issue).

These are my thoughts on the issue:
1) bsf_debug and jsdb need to go. The debug interface, as it
currently exists, is shameful, in performance and usefulness.

2) The taglib directory also needs to go. With JSP 2.0 upcoming, I
believe that BSF has a limited role, if any, in JSPs - EL does a
*much* better job in its place. The taglib in this source tree was
a modification to support the aforementioned debug interface.
Hence, it needs to go. I would argue that the currently existing
BSF taglibs (in the taglibs project) need killing too, based on
the my belief that BSF and JSPs really shouldn't mix (performance
is abysmal, confusion stemming from having two separate contexts
in the form of the generated servlet and the language engine
executing script code within it, etc.)

3) Debug hooks need to be ripped out of the original BSF source,
and we thereby return to the code as it was in 2.2, modulo some

As to what should be in the source before another release passes
us, is a means, as suggested around January, for languages to be
auto-detected at runtime, so that we do not have to incorporate
every language engine under the sun into BSF. This makes life
easier from a maintenance standpoint, as well as permitting
language authors to release their languages and engines under
their desired licenses, since we do not force them to submit the
engine into BSF under the ASF license.

Beyond that, I think the CodeBuffer needs fleshing out, and error
reporting needs improvement - rather than a full blown debug

A few other desired features come to mind. However, this covers
the majority of what I consider to be the direction BSF needs to
be sailing.

Victor J. Orlikowski   | The Wall is Down, But the Threat Remains!
orlikowski@apache.org  | vjo@dulug.duke.edu | vjo@us.ibm.com

View raw message