Use-cases for GPSEE
Christoph Dorn
and wish to mention GPSEE specifically.
To highlight GPSEE in the best possible way I am looking for a list of
use-cases for the platform.
I would greatly appreciate a **comprehensive braindump** of the
various places GPSEE is going to go in the short and long term and
what is generally possible. The idea is to inspire a new audience and
paint a picture of why someone would choose and invest in GPSEE.
I would imagine this list would include (please include status of use-
case):
* Command-line scripts (implemented)
* Bash scripting (under development)
* Embedded in RPM5 (under development)
* Apache module (planned)
* Standalone webserver (planned)
* Toaster oven controller (possible)
If you have links to various different examples/integrations/
discussions I would be happy to include them but that is not
necessary.
If you are interested in helping me promote CommonJS by mentioning
GPSEE, an implementation that seeks to be CommonJS compliant, please
respond ASAP. Sorry about the short notice!
Thanks!
Christoph
[1] - http://wakanday.org/
Jeff Johnson
On Oct 4, 2011, at 12:55 PM, Christoph Dorn wrote:
>
> * Embedded in RPM5 (under development)
I can only speak to this issue.
I chose JS embedding originally because JavaScripts was
suggested by Ralf Engelshcall: he packaged js-1.6 and
also created/hosts the @rpm5.org web site.
The rationale for choosing JS as an embedded language were
quite murky and complex, but basically boiled down to
There are more JS "programmers" than all other languages combined.
Even if that statement isn't literally true atm, the trend towards
browsers and JS is certainly true.
My own private motivation (and handicap from another POV) is that
JS == C
In most ways I -- as an experienced C programmer -- could start
using JS instantly. OTOH, there's lots more to JS than being
an approx. C interpreter, ymmv, I'm just stating my needs.
So I needed to learn JS binding as rapidly as possible. There's
currently 35+ classes of varying quality in @rpm5.org CVS.
I just changed most of the code to the JS 1.8.5 interface.
While most of the modules are likely of limited use solely to RPM,
there are a couple of modules that are lijkely of more interest:
1) Berkeley DB bindings (~95% complete, I used for prototyping
rpmdb schema changes).
2) Bloom filters -- while its trivial to implement a Bloom filter,
the hash generation is computationally intensive and likely better
done in C rather than JS for serious usage
3) Digests/crypto -- RPM implements >120 digests, including
all of the NIST SHA3 finalists. Implementing digests efficiently
needs SSE* and other optimizations, implementing JS is just painful.
RPM now also has 4 libraries (BeeCrypt/NSS/OpenSSL/Libtomcrypt)
with an API that will be tied into JS as I proceed. Note that
the crypto is *not* X.509 certs but rather OpenPGP format.
All/any of the above could be uncoupled fropm RPM and made available to
anyone interested without difficulty. And if no interest, well, my purpose
is RPM+GPSEE+JS "rapid application development. And the benefit of GPSEE is
* written in C
* has modules
* Wes Garland knos *a lot* about JavaScript
I hope the above helps your talk. If not well .. that's fine too.
Wes Garland
I would imagine this list would include (please include status of use-
case):
* Command-line scripts (implemented)
* Bash scripting (under development)
* Embedded in RPM5 (under development)
* Apache module (planned)
* Standalone webserver (planned)
* Toaster oven controller (possible)
Bash scripting -- The "shellalike" module was designed to allow us to port shell scripts from shell (e.g. bash) to JavaScript without significant refactoring, only syntax changes. While CAY pipelines have some limitations, we've largely achieved that overall goal -- there is very little that is expressible in shell that's not expressible with gsr -- and I'm thinking of "big programs" written in shell (yes, there are tonnes in "industry"), not little one-liners.
Embedding -- RPM5 is an instance of where I see GPSEE embedding going. We started our investigation in JavaScript as a highly flexible runtime configuration language. We have proprietary software written in C that links with libgpsee.so to "ask questions" that are answered by scripts written in JS. These scripts are much easier to maintain than C programs, in particular with regard to production deployment. In turn, we can ship updated heuristics, etc, for our software in the form of JS modules. Kind of like................add-ons for firefox, actually! (except that our software has nothing to do with the web)
One of the key design requirements behind GPSEE is also that it is about the same effort to use as SpiderMonkey, but it comes with a module system and some important modules out of the box. The key here is that the modules can be written in *native* code (C, C++), for low-level interfacing, but present a common C ABI and work from the JS user's POV like any CommonJS module. We also ship both Mozilla's js-ctypes FFI (on distros supporting it) and the GPSEE FFI. The Mozilla code is a lot like Python's CTypes, while the GPSEE code is a little more rigid in some ways, but guarantees portable access to the POSIX C library across architectures.
So, say, you are writing a program like ... a MIDI sequencer. And say you decide you want to allow MIDI note data to be manipulated by JS. You embed GPSEE (via libgpsee) in your program, and you let users run JS scripts. You create some modules in C which can interface directly your MIDI card, and others which talk to internal data structures of your program. Then you figure out a way in your UI to kick off a CommonJS program, and suddenly your program has the full capabilities of GPSEE -- CommonJS modules, I/O, modules written by 3rd party users, the whole nine yards. You can trigger events based on your MIDI sequencer's event loop, whatever you want.
One big problem I see in native-language JS binding -- especially with SpiderMonkey -- is that everybody has the same set of problems to solve -- I/O, database, modules, etc, and nobody is sharing.
I want to be the guy that solves modules and adds compatibility between products. Right now, for example, the authors of JSExt and JSlibs cannot share libraries, even though the "inside code" would be virtually identical, because there is no "API" to do so. GPSEE solves that problem: if both authors were to port their libraries to GPSEE's API and a CommonJS idiom, we'd all be able to use each other's libraries. And the porting exercise tends to be ridiculously easy, since we use basically SpiderMonkey's API with a few extra bits thrown in for compatibility and organization.
So - pretty much anything that has SpiderMonkey in it right now could have GPSEE functionality without much effort. This includes APE, the AJAX Push Engine -- I have a fork on github which is under development but stable. It's a good little event-loop Comet server (which means we have to be careful around blocking I/O!)
At PageMail, are writing literally ever kind of code imaginable with GSR these days - websockets clients, mail servers, batch reports, etc. Hardly anything is not written in JS these days. But GSR, the CommonJS script runner is only the beginning! I foresee lots of great applications out there!
Wes
Wesley W. Garland
Director, Product Development
PageMail, Inc.
+1 613 542 2787 x 102
Wes Garland
All/any of the above could be uncoupled from RPM and made available to
anyone interested without difficulty.
Once we ship JS 1.8.5 and GPSEE-0.3, I'd like to revisit that. It seems to me we should be able to have RPM packages which install GPSEE modules; uncoupling these and some of the stuff which doesn't really belong in GPSEE-proper (curses?), making them packages that install .so files etc in a place where GPSEE can find them would be pretty cool.
Wes
--