by Kevin Dangoor, May 4 2009
- Plugins that feature both client and server components
- Code sharing between client and server
- Better support in Bespin
- Possible speed improvements
The following sections will dive into these advantages in more detail.
Many features for Bespin can be implemented purely on the client side. Certain features require access to the server in order to work properly or well. For example, any cross-domain access needs to go through the server. Another example is the Quick Open feature which allows you to incrementally search through the filenames to find matching files. To work quickly enough, the server needs to maintain a list of the files in the project that allows for quick searching. This was easy enough to do, but there was no way this could be implemented as a plugin.
The problem faced in making plugins with the current Python server is that there is no way, at the time of this writing, to reliably write secure, performant Python code. The C Python runtime just wasn't made for it, and the PyPy project is still to experimental and slow.
Over time, we anticipate having the Bespin project code packaged up in a variety of ways for a variety of uses. One example would be to use Appcelerator Titanium or something similar to package up Bespin for use on the desktop. We could do that today, but you would immediately lose the version control system support (as one example of a feature with a significant server side component). Even Quick Open currently relies on server code which would need to be duplicated in new JS code.
Better support in Bespin
To make this possible, the likely best approach to building the JS server will be to start it off as a near line-by-line port of the Python. This will make it much easier to integrate changes from the Python code as they are made. Additionally, the unit tests should also be ported from Python to ensure that the server's behavior remains intact.
As of this writing, the authoritative source for the Bespin JS server is on hg.mozilla.org
Currently, Irakli Gozalishvil is actively working on the JS backend and he maintains a fork at GitHub.
We are closely monitoring the Hg-Git project to allow us to easily collaborate seamlessly via both Mercurial and Git. As of the end of April, this project was not quite able to handle Bespin.
Once enough of the standard library is built, we can freely switch between Rhino, SpiderMonkey and v8 (and possibly even JSCore) as needs dictate.
Other Projects in Use
We have a number of projects that we depend on, but we do not yet have an automated process in place to install these dependencies. Further, many are under active development, so tracking the source is beneficial.
Narwhal provides a multi-interpreter standard library implementation and includes Rhino.
Jack builds on Narwhal to provide some useful utilities for building webapps. It includes a simple web server.
JsDoc Toolkit will be used for documenting the code.
Helma NG may be a source of useful code and inspiration, but at this time is too tied to Rhino for our purposes. Helma NG is a good package and is following along with the ServerJS work, which is why it is good to follow. Helma NG is also available on GitHub.
jsUnity is an actively developed JS test framework that should be seriously considered. The author appears accommodating of requests from ServerJS. Also worth noting: Ondrej Zara wrote a test runner that is somewhat similar to what we get from Nose. We can run tests file-by-file, but we will ultimately need a test runner that can discover and run our entire collection of tests.
Database Storage Thoughts
It is not 100% clear at this time what the best approach for storing users and their social graph will be. Some options:
- Helma's filestore is a simple way to get going. However, it likely doesn't feature all of the parts of the RDBMS we're using (cascading deletes?) and may not scale up to the level we need.
- Direct JDBC is an option. ServerJS will almost certainly come up with an interface like JDBC. The Nitro web framework (built on Jack) already features an interface on top of JDBC and may be a fine approach. Note that the drawback is that working at this level will make it harder to use one database engine during development and another in production, as we do today in Python.
Apache Derby is likely a good choice for a development database. We are presently using MySQL in production.
To start with, all discussion related to the Bespin JS Server will take place on the bespin-core mailing list.