IVLE - Imported Code (Investigation) ==================================== Author: Matt Giuca Date: 4/12/2007 In this document we look at various libraries and code around the Internet which we might use in IVLE. Console ------- There are a few JavaScript consoles available (written in JS, for JS). We need one that can handle Python. There are two options here: one that just works as a terminal to any Unix shell, or one specifically for Python which might have better command completion like the JavaScript shells. Our prototype uses WebShell at the moment. ### Discussion: Full terminal vs console emulation ### There are 2 possibilities open to us: we can either emulate a full terminal (able to run vim and other curses-style applications), or just a basic console emulator which only allows for cooked command-line input. Joshua and friends are basic command-line emulators, while WebShell and AjaxTerm are full-blown terminal emulators. The important difference is speed. The full terminal emulators send keystrokes to the server and get as a response a "diff" of characters on the screen. *Note that* this means even when you're just typing away, you can't see what you've typed until the server has processed the text and sent back the updated screen. A console emulator would be able to accept a line of user input on the client side without sending anything to the server. It could then transmit the line (as string text, not character strokes) and the server could then send back the response (as string text, not individual character updates). This is a huge amount faster and I recommend it if we don't need vim and the like. ### Full terminal ### #### WebShell #### [WebShell](http://www-personal.umich.edu/~mressl/webshell/). Based on Ajaxterm. This is what we use in the PynApple prototype. Looks a bit heavy (has a clunky iPhone interface - might drop down to its lowest-common denominator, Ajaxterm). #### AjaxTerm #### [AjaxTerm](http://antony.lesuisse.org/qweb/trac/wiki/AjaxTerm) is a nice lightweight option for the "full terminal emulation" option, but it doesn't plug into Apache - it runs its own web server. This is unacceptable really. Says its based on [AnyTerm](http://anyterm.org). #### AnyTerm #### [AnyTerm](http://anyterm.org) is very very similar to AjaxTerm but it plugs into Apache instead. Unfortunately it is written in C++, as an Apache module. Yuck. I haven't been able to get it to compile yet. This isn't really desirable for the end product but we can use it for now to get a console working quickly. ### Client-side (line) shells ### #### ajaxPHPterm #### [ajaxPHPterm](http://sourceforge.net/projects/ajaxphpterm/) is about what we're looking for. It is a rather simple ajax screen which presents a terminal using just an HTML text page and a text input box. It simply sends the text to the server and when the server responds, it prints it to the screen. It runs bash but can't run any curses apps. It also can't yet run the Python interpreter or any interactive apps (try "cat" with no arguments - nothing happens). This should be easy to fix. I think we can work from this (possibly rewrite from scratch, in Python, but based heavily upon this). I would like to change: * Text field into JavaScript interacting directly with the keyboard, allowing us to do tabs and things. (Though this then kills copy+paste). * Support interactive applications (though only console apps, not curses). * Support colour and other ANSI codes (currently just prints the ANSI codes directly into the HTML). * Change use of pre into normal text to allow word wrapping. (Not how real terminals work but it's nice enough). Question: Do we want a hard 80-char wrap like real terminals or is it okay to soften this to a browser-wide word wrap? #### Joshua #### [Joshua](http://blogrium.com/2006/01/28/joshua/) is a web-based JavaScript console ([online demo](http://progrium.com/dev/ijs/)). We need a Python one. #### JavaScript Shell 1.4 #### [JavaScript Shell](http://www.squarefree.com/shell/shell.html) Also JavaScript based. #### Termlib #### [Termlib](http://www.masswerk.at/termlib/). Ajax shell, looks very generic (no default language or connection). Has floating windows. Restrictive license (noncommercial). Text Editor ----------- Two online (JavaScript-based) editors are [CodePress](http://codepress.org) and [EditArea](http://www.cdolivet.net/editarea/). We have used EditArea in the prototype. Crunchy uses EditArea. [Comparison](http://www.virtualroadside.com/blog/index.php/2007/06/08/codepress-vs-editarea/). It seems like EditArea is superior (and I agree from trying them out). Note that "AutoComplete" in CodePress is just autocompleting brackets, not "IntelliSense" style. Oh, and CodePress doesn't support Python syntax. That's a bit of a deal-killer. EditArea seems a bit bulky. Can we trim it down a bit (especially for the tutorial sheets). Another one is [CodeMirror](http://marijn.haverbeke.nl/codemirror/). This is very lightweight but again doesn't support Python syntax (seems only JavaScript, probably difficult to add other syntaxes). Also slow to update highlighting. Subversion Client ----------------- What we now want is a workspace browser, not a repository browser. This allows us to have just a single browser for both the students permanent and temporary files (see design/subversion.txt). Most web clients are repository browsers, not workspace. What we need is an interface quite like TortoiseSVN but for the web. ### Polarion ### We have been using [Polarion](http://www.polarion.org/) [WebClient for SVN](http://www.polarion.org/index.php?page=overview&project=svnwebclient) in the prototype. Apache license. Nice feature-wise. Backend written in Java. Lots of confusing buttons everywhere (perhaps not good for entry-level students). ### Our own browser? ### Considering writing our own browser? Advantages: * I haven't yet found a workspace browser for the web. * We can tailor it to the needs of new students (simple interface, different terminology, "file browser" paradigm instead of repository paradigm). This task is quite distinct from a repository browser. A repository browser goes in through the svn protocol or something like that. A workspace browser needs direct access to the file system AND the svn client API. So we aren't writing an SVN browser at all, but a web-based file browser with SVN client support. (Are there any web-based file browsers we can adapt?) Seems as though writing our own would be simple enough when weighed up against finding one and augmenting it. It would be acceptable to do page loads for interactions with the server, but I'd like viewing (without making changes to the server) to be done using JavaScript (it wouldn't need to load data from the server). This means either: 1. We load all the data about the directory tree from the server (ick). 2. We do a page load when the user navigates to another directory. 3. We use Ajax for just one activity: getting data about another directory from the server (so we can do an Ajax "ls"). (If we're going to use Ajax for this, might we as well just send data such as updates via Ajax as well, or is this more complicated somehow?) ### SVN Web Control (SWC) ### [SVN Web Control](http://svn-web-control.sourceforge.net/) seems to be similar to what we're looking for - it gives you "webspaces" which are like workspaces on the web. So this is a SVN workspace browser, not a repository browser. Implemented in PHP. Awful documentation. Gives errors when I try to run and the documentation is just API docs, no installation guide... Scratch this? Web-based file browser ---------------------- I made a separate category here for web-based file browsers which we can possibly build into a Subversion workspace client. There are many online file browsers. We'd prefer one written in Python but I haven't found any yet. Alternatively, do we want to use WebDAV? (I'm not familiar enough with WebDAV to know its limitations). ### Online File Browser ### [OFB](http://filebrowser.mbsoftware.pl/quick-start). PHP. Live demo available. MIT license. Uses Ajax. Looks and feels nice and stable. Dependency on ["Smarty" template engine](http://smarty.php.net/). We do not want to use its auth. It can be disabled, but then anyone can use it. Can we plug in our own user system? How easy would it be to add buttons, etc? Crunchy ------- [Crunchy](http://code.google.com/p/crunchy/) is an interactive Python tutorial system. We haven't yet used it anywhere in the prototype but it's similar to our "reference / tutorial" section. Crunchy goes through a specially-prepared HTML page and augments it with interactive Python boxes. These let you type single Python commands into an interactive console (much more limited than the consoles such as Joshua) and see ther results (it runs Python on the web server). It also provides edit boxes for more involved samples. The edit boxes use EditArea. ### Do we want to use this? ### The console mode could be useful for very small examples. (But for just "trying things out" a dedicated console is more useful). For most examples I expect we'll just be using the editor mode of Crunchy. I feel in this case we might as well just put our own edit boxes on there and save the overhead of integrating Crunchy. ### Notes ### Crunchy seems to be intended for an individual to download and run. It sets up its own web server and behaves like a user application (which happens to run in the browser), not a web application. For instance, it displays a "close" button hovering over the top of the screen. May require some modification to integrate it as a web app. MIT license.