jakarta-bsf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sanjiva Weerawarana" <sanj...@watson.ibm.com>
Subject Re: re-organizing the BSF source tree
Date Sun, 15 Jun 2003 17:30:36 GMT
"Victor J. Orlikowski" <vjo@dulug.duke.edu> writes:
> 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.

No problem - better late than never!

> 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

Can you give me more info on "EL"? I am not familiar with it ..

> 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
> bugfixes.

Big +1 to this! 

> 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
> interface.
> 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.

Sounds great. If we get going on some of these I'm quite certain
we will attract a vibrant community for this project. I will be
happy to do what I can!


View raw message