ServerJS overlap with JSAN
Kevin Dangoor
A few months ago, I started a project that is currently called "ServerJS":
Background: http://www.blueskyonmars.com/2009/01/29/what-server-side-javascript-needs/
Current project page: https://wiki.mozilla.org/ServerJS
Our goal is to create a standard library for JavaScript that puts it
on equal footing with Ruby, Python and Java in non-browser contexts.
We're making good progress with people implementing the evolving
standard on Rhino, SpiderMonkey and v8. The first thing we did was
create a standard for modules:
https://wiki.mozilla.org/ServerJS/Modules/SecurableModules
These modules have lots of good properties. As the name implies, they
can be loaded into secure sandboxes (and someone did just that
yesterday). They don't necessarily have access to modify globals. In
server environments, leaving off a "var" does not automatically create
a new global. *Plus* they can be loaded in the browser as well (see
the Notes section on the page above). Some of the people in the
ServerJS group are also in the ECMAScript TC-39 working group, so they
also tried to steer the proposal in a direction that looks similar to
a module format proposed for ES-Harmony.
Right now, we're also in the process of figuring out a packaging
strategy. I have a number of goals in mind, based on my experiences
with Python packaging pitfalls and with earlier use of CPAN. Some of
my goals:
1. cross-platform (Windows, Mac, Linux, etc.)
2. cross-interpreter (be able to handle packages for the various
standard library implementations and the underlying interpreters)
3. easy to grab packages from a known server/set of servers
4. easy to also have your own server serving up packages
5. easy to install from a directory of packages
6. the ability to have multiple versions installed
7. in development, you'd run the latest versions of libraries
8. in production, you'd run a specific set of versions, locked down
via a requirements file that is separate from the code
9. scripts are generated to automatically select the right versions of
libraries (see virtualenv in Python for an example of this. it's very
cool and useful)
10. creators of most packages need not use a language other than JS to
specify package metadata and do build scripting
At the moment, I see three primary contenders for making this happen:
1. rolling our own
2. RubyGems
3. CPAN
#1 is not palatable because it's a lot of work.
#2 and #3 are viable, and #3 is obviously where there would be a lot
of overlap with the OpenJSAN project. I don't know if Malte Ubi is on
this list, but he's the one that clued me in that this project has
sprung back to life.
It is possible that OpenJSAN's focus on libraries for the browser may
not be compatible with our more general "JavaScript scripting" focus.
But, I wanted to be sure that you're aware of what we're up to in
ServerJS. It is also possible that our efforts may fit together
perfectly :)
Kevin
--
Kevin Dangoor
work: http://labs.mozilla.com/
email: k...@blazingthings.com
blog: http://www.BlueSkyOnMars.com
David E. Wheeler
> These modules have lots of good properties. As the name implies, they
> can be loaded into secure sandboxes (and someone did just that
> yesterday). They don't necessarily have access to modify globals. In
> server environments, leaving off a "var" does not automatically create
> a new global. *Plus* they can be loaded in the browser as well (see
> the Notes section on the page above). Some of the people in the
> ServerJS group are also in the ECMAScript TC-39 working group, so they
> also tried to steer the proposal in a direction that looks similar to
> a module format proposed for ES-Harmony.
Sounds awesome.
> Right now, we're also in the process of figuring out a packaging
> strategy. I have a number of goals in mind, based on my experiences
> with Python packaging pitfalls and with earlier use of CPAN. Some of
> my goals:
>
> 1. cross-platform (Windows, Mac, Linux, etc.)
> 2. cross-interpreter (be able to handle packages for the various
> standard library implementations and the underlying interpreters)
> 3. easy to grab packages from a known server/set of servers
> 4. easy to also have your own server serving up packages
> 5. easy to install from a directory of packages
> 6. the ability to have multiple versions installed
> 7. in development, you'd run the latest versions of libraries
> 8. in production, you'd run a specific set of versions, locked down
> via a requirements file that is separate from the code
> 9. scripts are generated to automatically select the right versions of
> libraries (see virtualenv in Python for an example of this. it's very
> cool and useful)
> 10. creators of most packages need not use a language other than JS to
> specify package metadata and do build scripting
A documentation standard and searchable archive of all modules are
also really important. CPAN would be dead without search.cpan.org. And
a testing standard would be good, too.
> At the moment, I see three primary contenders for making this happen:
>
> 1. rolling our own
> 2. RubyGems
> 3. CPAN
>
> #1 is not palatable because it's a lot of work.
Amen to that.
> #2 and #3 are viable, and #3 is obviously where there would be a lot
> of overlap with the OpenJSAN project. I don't know if Malte Ubi is on
> this list, but he's the one that clued me in that this project has
> sprung back to life.
>
> It is possible that OpenJSAN's focus on libraries for the browser may
> not be compatible with our more general "JavaScript scripting" focus.
> But, I wanted to be sure that you're aware of what we're up to in
> ServerJS. It is also possible that our efforts may fit together
> perfectly :)
Well, JSAN came about in part because of a blog entry I wrote on
[JavaScript namespacing], which I adopted when writing [Test.Simple].
Since then, a number of people contributed various patches for
Test.Simple to get it to work in SpiderMonkey, Rhino, and Director, as
well as a browser. So I think that this makes a good precedent for
being platform-neutral. And in fact, other than providing an interface
to run Test.Simple-based tests in Test.Harness.Browser, openjsan.org
doesn't really care where individual JS libraries are designed to run.
Of course, since most folks use JS for browser work, the vast majority
of our libraries are browser-based. But key to the CPAN-style of
repository is not really caring what platform code is written for, or
the quality of the code for that matter.
[Test.Simple]: http://openjsan.org/doc/t/th/theory/Test/Simple/
[JavaScript namespacing]: http://justatheory.com/computers/programming/javascript/emulating_namespaces.html
That said, openjsan.org has been working towards providing ways for
Web developers to easily use JSAN libraries on their sites. So it has
been having that focus, and that will likely continue, I expect
(though I'm not really involved in it). Overall, I think that the goal
is to make openjsan a great repository for well-tested, well-
maintained JavaScript libraries that are easy to install and use (and
their documentation is readily available). That doesn't stand in the
way of it being implementation-specific, and that's a good thing.
In short, I think there is definitely room for collaboration here, if
you're interested and the main JSAN developers are interested. Sound
good to you?
Best,
David
Kevin Dangoor
On Thu, May 28, 2009 at 1:17 PM, David E. Wheeler <da...@justatheory.com> wrote:
> A documentation standard and searchable archive of all modules are
> also really important. CPAN would be dead without search.cpan.org. And
> a testing standard would be good, too.
I had actually forgotten about "documentation standard". I've been
using Python consistently for the past 4 years, and the docstrings in
Python are always just there... JS definitely could use a doc standard
for modules.
I didn't list searchable archive of modules, but I'm definitely aware
that that's key!
> Well, JSAN came about in part because of a blog entry I wrote on
> [JavaScript namespacing], which I adopted when writing [Test.Simple].
> Since then, a number of people contributed various patches for
> Test.Simple to get it to work in SpiderMonkey, Rhino, and Director, as
> well as a browser. So I think that this makes a good precedent for
> being platform-neutral. And in fact, other than providing an interface
> to run Test.Simple-based tests in Test.Harness.Browser, openjsan.org
> doesn't really care where individual JS libraries are designed to run.
> Of course, since most folks use JS for browser work, the vast majority
> of our libraries are browser-based. But key to the CPAN-style of
> repository is not really caring what platform code is written for, or
> the quality of the code for that matter.
Yeah, people will naturally figure out what works well. For our needs,
we do care about which platforms a particular package is designed for
(and whether it's source or binary).
> That said, openjsan.org has been working towards providing ways for
> Web developers to easily use JSAN libraries on their sites. So it has
> been having that focus, and that will likely continue, I expect
> (though I'm not really involved in it). Overall, I think that the goal
> is to make openjsan a great repository for well-tested, well-
> maintained JavaScript libraries that are easy to install and use (and
> their documentation is readily available). That doesn't stand in the
> way of it being implementation-specific, and that's a good thing.
>
> In short, I think there is definitely room for collaboration here, if
> you're interested and the main JSAN developers are interested. Sound
> good to you?
Yes, indeed. At this stage, I'm taking a look at the JSAN code on
github and also at how RubyGems work to see which one is closer to our
goal. I think the two have different strengths and weaknesses relative
to where we're headed. Great to know that things are alive and kicking
here!
David E. Wheeler
> I had actually forgotten about "documentation standard". I've been
> using Python consistently for the past 4 years, and the docstrings in
> Python are always just there... JS definitely could use a doc standard
> for modules.
Agreed. There's JSDoc, but as Markdown fanatic, I hate it. ;-) All of
the Test.Simple docs are written in POD (as are most JSAN modules, I
believe), and Nickolay Platonov is working on pluggable documentation
support in Module::Build::JSAN, I believe.
> I didn't list searchable archive of modules, but I'm definitely aware
> that that's key!
Oh yeah.
> Yeah, people will naturally figure out what works well. For our needs,
> we do care about which platforms a particular package is designed for
> (and whether it's source or binary).
Yeah, if a library isn't generic, and targets a particular platform or
environment, it should say so. Of course, the more libraries that
don't care where they run, the better. But on the back end, there
might be libraries that need to use I/O, and of course they can't run
in the browser. So flagging support in the interface (preferably in
the searchable site) is important.
> Yes, indeed. At this stage, I'm taking a look at the JSAN code on
> github and also at how RubyGems work to see which one is closer to our
> goal. I think the two have different strengths and weaknesses relative
> to where we're headed. Great to know that things are alive and kicking
> here!
We really want to improve OpenJSAN, with the goal of having it be as
open a repository as possible (or, at least, that has been the goal in
the past and no one has yet said differently; YMMV). RubyGems seems
okay, but I suspect you know where my biases are.
But what about the rest of yous? Nickolay? John?
Best,
Davi
Nickolay Platonov
IMO the biggest strength of OpenJSAN is that its already working system, with decent codebase.
Yes, there are an obviously places to improve, but improving something is much simpler, than coding from scratch.
Let me comment your goals with respect to current state of OpenJSAN project:
1. cross-platform (Windows, Mac, Linux, etc.)
OpenJSAN is as cross-platform as perl itself.
2. cross-interpreter (be able to handle packages for the various
standard library implementations and the underlying interpreters)
3. easy to grab packages from a known server/set of servers
There is already written JSAN::Shell, which offers a command-line interface for working with packages.
JSAN::Shell is available on CPAN.
4. easy to also have your own server serving up packages
After the migration to Catalyst will be finished, whole OpenJSAN infrastructure will be installable from CPAN )
5. easy to install from a directory of packages
A feature to add into JSAN::Shell
6. the ability to have multiple versions installed
Currently supported via several @INC paths
7. in development, you'd run the latest versions of libraries
8. in production, you'd run a specific set of versions, locked down
via a requirements file that is separate from the code
9. scripts are generated to automatically select the right versions of
libraries (see virtualenv in Python for an example of this. it's very
cool and useful)
10. creators of most packages need not use a language other than JS to
specify package metadata and do build scripting
Well, metadata can be specified in any format/language, but we need a building tool anyway.
Since JS have no IO it have to be written in another language. Current buliding tool in OpenJSAN is Module::Build::JSAN.
Documentation standard (currently supported only POD parsing, there are plans to add more parsers)
Testing standard (a number of testing platforms, plus some results on JSAN::Prove - analog of usual prove for testing in browsers)
As you can see most of your goals are already achievable. Surely, some work needs to be done to match them all.
As David said, OpenJSAN is an open project and you are welcome to contribute the features important to you.
I think will be much better to have one excellent JS repository, than two just good.
Regards, Nickolay
Kevin Dangoor
On Sun, May 31, 2009 at 5:57 AM, Nickolay Platonov <nick...@gmail.com> wrote:
> Well, metadata can be specified in any format/language, but we need a
> building tool anyway.
> Since JS have no IO it have to be written in another language. Current
> buliding tool in OpenJSAN is Module::Build::JSAN.
Well, *your* JS might not have IO. Mine does (we're slowly converging
on the binary and file APIs) :)
In using a package manager written in a language other than JS, my
thinking has been that you'd use the package manager to install an
interpreter+stdlib with all of the build scripts written in the
language native to the package manager (Perl or Ruby). Once you've
done that, any packages you install for that interpreter can use JS
for the build scripts.
David E. Wheeler
> In using a package manager written in a language other than JS, my
> thinking has been that you'd use the package manager to install an
> interpreter+stdlib with all of the build scripts written in the
> language native to the package manager (Perl or Ruby). Once you've
> done that, any packages you install for that interpreter can use JS
> for the build scripts.
A native, easy-to-install interpreter would be really nice. At this
point, the advantage to using Perl (or Ruby) is that it's available
pretty much everywhere. I haven't tried to install Spidermonkey for a
while, but I didn't get too far when I did try.
That said, I'd *love* to see a standard interpreter widely
distributed. That would make installing and running tests really easy
and clean, especially if there's I/O. Even Browser-based libraries
could be tested in such an environment with suitably mocked DOM objects.
Best,
David
Nickolay Platonov
Thanks for the comments, Nickolay.
Well, *your* JS might not have IO. Mine does (we're slowly converging
On Sun, May 31, 2009 at 5:57 AM, Nickolay Platonov <nick...@gmail.com> wrote:
> Well, metadata can be specified in any format/language, but we need a
> building tool anyway.
> Since JS have no IO it have to be written in another language. Current
> buliding tool in OpenJSAN is Module::Build::JSAN.
on the binary and file APIs) :)
In using a package manager written in a language other than JS, my
thinking has been that you'd use the package manager to install an
interpreter+stdlib with all of the build scripts written in the
language native to the package manager (Perl or Ruby). Once you've
done that, any packages you install for that interpreter can use JS
for the build scripts.
Well, since we are talking about the JS with IO then this is also the way to go, why not.
Marvin Humphrey
> Well, since we are talking about the JS with IO then this is also the way to
> go, why not.
I like the idea. :)
I probably a half-decent JS hacker, though, and I don't know where to find
JS-with-io. STFW turned up a bunch of FAQs about browser security. I'm sure
I'd have succeeded eventually, but I became persuaded that a point needed to
be made.
How about a link, one that'll have to feature prominently on the openjsan.org
homepage?
Marvin Humphrey
Kevin Dangoor
I'm hoping to get a new website up soon. We're actually blessed with
an unusual environment and competition in JavaScript, so the ultimate
goal is that you'll have not one but at least 3 interpreters to choose
from (possibly with different bundled libraries and such).
It's worth noting that Rhino is perhaps the easiest JavaScript to get
started with today, because you have trivial access to all of Java.
SpiderMonkey and v8 are much faster and have much smaller memory
footprints, though, so those are also attractive platforms that people
are building on.