Open main menu

CDOT Wiki β

Create Local MXR

Project Name

Create Local MXR

Project Description

Many developers without highspeed network access would like to be able to use MXR but can't. This project will build a lightweight, installable Windows package that gives the full functionality of MXR locally. This will also include a Prism front-end specific for the task of using this local MXR.

Resources: MXR source, patches to lxr in the tree

Project Leader(s)

Project Contributor(s)

  • None

Project Details

  • Project begun in conjunction with Mozilla Developer Resource Kit project.
  • I'm not sure the best way to do this, in terms of having a usermode, lightweight web server that can run this on Windows. We could use something like lighttpd or one of the other small servers for win32. Ideally, this could run as an app vs. a service--people won't want to install a service just to search source code.
  • Win32 port of lighttpd is here. 1.3M download, 5.34M installed. Takes ~3.3M RAM on startup.
  • Need DB_File. I tried to get this working with msys-perl |perl -MCPAN -e 'install DB_File'| but it doesn't seem to work for me. So I installed ActivePerl, and get it that way |ppm install DB_File|.
  • Index db file size for an index of a fresh trunk checkout = ~77.8MB
  • Wondering about adding syntax highlighting. Various JS libs exist for this:
  • Might make sense to have the web app control the web server via nsIProcess, so it can start/stop it intelligently.
  • Another option to consider is a self-hosting web server using httpd.js. Waldo has a patch to add cgi capabilities. UPDATE: This has landed on trunk, but it's not a good option according to Jeff (from an email asking about using the new js-cgi stuff for this project):

Well, first, the server's CGI is only CGI done in JS, so you'd have to call out to Perl or what-have-you to use the existing code of MXR. Second, the server doesn't expose as much information as is exposed in a CGI environment, some because it requires a bit of pre-configuration of the server (the APIs could be added, but it'd either be a fair number or a config file, neither of which is all that great for usability). Third, the server doesn't allow you to access the body of requests, so, for example, you can't process the body of POST requests yet, so you can't handle most form submits.
The server was mostly designed for mocking a set of static files onto a web server for testing purposes (and not much more than that) without needing to run a full-fledged local web server, to get correct file paths and such (and at a specific host if you set up proxying correctly, a la Mochitest). Full dynamicity was never really a goal, and POST requires a fair amount more pain than you'd expect as I'm unable to use threads in the server due to non-threadsafe components. I'd suggest sticking with what you have, more or less, because this sounds like more than the server really was meant to do.

  • PRISM build instructions are here.
  • Use shjs.js to do syntax highlighting of source.
  • Blogged on my progress to date, showing MXR working, and re-done as an extjs app.
  • Spoke with justdave about source for mxr:
To get the source, use hg clone File bugs in Webtools/LXR and attach patches, CC justdave, timeless, and bsmedberg on them
  • Need to deal with chars in filenames when creating ids in elements: $^_-/.{}0123456789aAbBcCdDeEfFgGhHiIjJkKlLmMnNoOpPqQrRsStTuUvVwWxXyYzZ
  • Considering doing an extension with a binary web browser app included. See this discussion of tiny web servers, and also the Prism Firefox Extension, which shows the model for containing binary apps and using nsIProcess to start/stop.