On May 7, 2009, at 12:08 PM, devzero2000 wrote:

>
> Hmm, probably i have missed something :
>

Hehe, you're not alone. The "Java" in "JavaScript"
has nothing whatsoever to do with Sun(trademark) Java(trademark).

JavaScript is actually a pleasant little language with syntax
more similar to C than Java. Lots and lots of people
(including me before I started) get confused by the misnomer.

ATM, the main usage cases for JavaScript are largely
directly within browsers. There's a GNOME effort,
and a few more that I'm aware of, but none are
very far advanced.

Browsers have a very peculier application niche because
of the risk of virus infections and such.

So there are very few usage cases for "traditional" scripting
using JS. Its all about Ajax and HTML embedding and browser
related issues dealing with browsers and the WWW.

The closest analogue to what RPM is attempting with JavaScript
is currently called "server-side" scripting using JavaScript.

There's a Wiki and proposals and more that have been talked
about for years (afaict), but there are no strong conventions
for file paths and modules and more when extending JavaScript
that I've been able to find.

(aside)
There appears to be some way to extend JavaScript from remote
URI's with signature verification. But the downloaded content is likely
more javascript for "portability", not the extensions written
in C that are currently being built as rpm/js/libjsm.so. So far
I also haven't found a dlopen() mechanism for javascript worth
stealing. But I haven't looked very hard yet.

"jsm" == "JavaScript Modules" is the acronym I'm using. Apologies
if my acronyms are obscure, just ask. E.g. the "sw" in rpmsw
is "Stop Watch" because its used for benchmarks, the "sx" in rpmsx is
"SELinux Xattr's", etc, etc, etc.

But the usage case for JavaScript is very different than other  
"traditional" interpreters
like Perl and Python and Ruby and Tcl.

<snip>

>
> But probably none should have both 32/64 version  of libjsm.so.

The usage case for libjsm.so applies iff two multilib versions
of rpm are installed simultaneously. So far, there hasn't
really been a need for two rpm multilib executables simultaneously
installed (there is a need for multilib rpm libraries to be installed
side by side, but libjsm.so is a module, not a library, so the
issue of path choice conventions gets murkier).

hth

73 de Jeff

>
> ______________________________________________________________________
> RPM Package Manager                                    http://rpm5.org
> Developer Communication List                        rpm-devel@rpm5.org