1
IVLE - Imported Code (Investigation)
2
====================================
7
In this document we look at various libraries and code around the Internet
8
which we might use in IVLE.
13
There are a few JavaScript consoles available (written in JS, for JS).
15
We need one that can handle Python. There are two options here: one that just
16
works as a terminal to any Unix shell, or one specifically for Python which
17
might have better command completion like the JavaScript shells.
19
Our prototype uses WebShell at the moment.
21
### Discussion: Full terminal vs console emulation ###
23
There are 2 possibilities open to us: we can either emulate a full terminal
24
(able to run vim and other curses-style applications), or just a basic console
25
emulator which only allows for cooked command-line input.
27
Joshua and friends are basic command-line emulators, while WebShell and
28
AjaxTerm are full-blown terminal emulators.
30
The important difference is speed. The full terminal emulators send keystrokes
31
to the server and get as a response a "diff" of characters on the screen.
32
*Note that* this means even when you're just typing away, you can't see
33
what you've typed until the server has processed the text and sent back
36
A console emulator would be able to accept a line of user input on the client
37
side without sending anything to the server. It could then transmit the line
38
(as string text, not character strokes) and the server could then send back
39
the response (as string text, not individual character updates). This is a
40
huge amount faster and I recommend it if we don't need vim and the like.
46
[WebShell](http://www-personal.umich.edu/~mressl/webshell/).
49
This is what we use in the PynApple prototype.
51
Looks a bit heavy (has a clunky iPhone interface - might drop down to its
52
lowest-common denominator, Ajaxterm).
56
[AjaxTerm](http://antony.lesuisse.org/qweb/trac/wiki/AjaxTerm) is a nice
57
lightweight option for the "full terminal emulation" option, but it doesn't
58
plug into Apache - it runs its own web server. This is unacceptable really.
60
Says its based on [AnyTerm](http://anyterm.org).
64
[AnyTerm](http://anyterm.org) is very very similar to AjaxTerm but it plugs
65
into Apache instead. Unfortunately it is written in C++, as an Apache module.
68
I haven't been able to get it to compile yet.
70
This isn't really desirable for the end product but we can use it for now to
71
get a console working quickly.
73
### Client-side (line) shells ###
77
[ajaxPHPterm](http://sourceforge.net/projects/ajaxphpterm/) is about what
78
we're looking for. It is a rather simple ajax screen which presents a terminal
79
using just an HTML text page and a text input box.
81
It simply sends the text to the server and when the server responds, it prints
84
It runs bash but can't run any curses apps. It also can't yet run the Python
85
interpreter or any interactive apps (try "cat" with no arguments - nothing
86
happens). This should be easy to fix.
88
I think we can work from this (possibly rewrite from scratch, in Python, but
89
based heavily upon this). I would like to change:
91
* Text field into JavaScript interacting directly with the keyboard, allowing
92
us to do tabs and things. (Though this then kills copy+paste).
93
* Support interactive applications (though only console apps, not curses).
94
* Support colour and other ANSI codes (currently just prints the ANSI codes
95
directly into the HTML).
96
* Change use of pre into normal text to allow word wrapping. (Not how real
97
terminals work but it's nice enough). Question: Do we want a hard 80-char
98
wrap like real terminals or is it okay to soften this to a browser-wide word
103
[Joshua](http://blogrium.com/2006/01/28/joshua/) is a web-based JavaScript
104
console ([online demo](http://progrium.com/dev/ijs/)). We need a Python one.
106
#### JavaScript Shell 1.4 ####
108
[JavaScript Shell](http://www.squarefree.com/shell/shell.html)
109
Also JavaScript based.
113
[Termlib](http://www.masswerk.at/termlib/).
114
Ajax shell, looks very generic (no default language or connection). Has
117
Restrictive license (noncommercial).
122
Two online (JavaScript-based) editors are [CodePress](http://codepress.org)
123
and [EditArea](http://www.cdolivet.net/editarea/).
125
We have used EditArea in the prototype. Crunchy uses EditArea.
127
[Comparison](http://www.virtualroadside.com/blog/index.php/2007/06/08/codepress-vs-editarea/).
129
It seems like EditArea is superior (and I agree from trying them out). Note
130
that "AutoComplete" in CodePress is just autocompleting brackets, not
131
"IntelliSense" style.
133
Oh, and CodePress doesn't support Python syntax. That's a bit of a
136
EditArea seems a bit bulky. Can we trim it down a bit (especially for the
139
Another one is [CodeMirror](http://marijn.haverbeke.nl/codemirror/). This is
140
very lightweight but again doesn't support
141
Python syntax (seems only JavaScript, probably difficult to add other
142
syntaxes). Also slow to update highlighting.
147
What we now want is a workspace browser, not a repository browser. This allows
148
us to have just a single browser for both the students permanent and temporary
149
files (see design/subversion.txt).
151
Most web clients are repository browsers, not workspace.
153
What we need is an interface quite like TortoiseSVN but for the web.
157
We have been using [Polarion](http://www.polarion.org/) [WebClient for
158
SVN](http://www.polarion.org/index.php?page=overview&project=svnwebclient)
163
Nice feature-wise. Backend written in Java. Lots of confusing buttons
164
everywhere (perhaps not good for entry-level students).
166
### Our own browser? ###
168
Considering writing our own browser?
172
* I haven't yet found a workspace browser for the web.
173
* We can tailor it to the needs of new students (simple interface, different
174
terminology, "file browser" paradigm instead of repository paradigm).
176
This task is quite distinct from a repository browser. A repository browser
177
goes in through the svn protocol or something like that. A workspace browser
178
needs direct access to the file system AND the svn client API.
180
So we aren't writing an SVN browser at all, but a web-based file browser with
183
(Are there any web-based file browsers we can adapt?)
185
Seems as though writing our own would be simple enough when weighed up against
186
finding one and augmenting it.
188
It would be acceptable to do page loads for interactions with the server, but
189
I'd like viewing (without making changes to the server) to be done using
190
JavaScript (it wouldn't need to load data from the server).
194
1. We load all the data about the directory tree from the server (ick).
195
2. We do a page load when the user navigates to another directory.
196
3. We use Ajax for just one activity: getting data about another directory
197
from the server (so we can do an Ajax "ls").
199
(If we're going to use Ajax for this, might we as well just send data such as
200
updates via Ajax as well, or is this more complicated somehow?)
202
### SVN Web Control (SWC) ###
204
[SVN Web Control](http://svn-web-control.sourceforge.net/) seems to be similar
205
to what we're looking for - it gives you "webspaces" which are like workspaces
206
on the web. So this is a SVN workspace browser, not a repository browser.
208
Implemented in PHP. Awful documentation.
210
Gives errors when I try to run and the documentation is just API docs, no
211
installation guide... Scratch this?
213
Web-based file browser
214
----------------------
216
I made a separate category here for web-based file browsers which we can
217
possibly build into a Subversion workspace client.
219
There are many online file browsers. We'd prefer one written in Python but I
220
haven't found any yet.
222
Alternatively, do we want to use WebDAV? (I'm not familiar enough with WebDAV
223
to know its limitations).
225
### Online File Browser ###
227
[OFB](http://filebrowser.mbsoftware.pl/quick-start). PHP. Live demo available.
230
Uses Ajax. Looks and feels nice and stable.
232
Dependency on ["Smarty" template engine](http://smarty.php.net/).
234
We do not want to use its auth. It can be disabled, but then anyone can use
235
it. Can we plug in our own user system? How easy would it be to add buttons,
241
[Crunchy](http://code.google.com/p/crunchy/) is an interactive Python tutorial
242
system. We haven't yet used it anywhere in the prototype but it's similar to
243
our "reference / tutorial" section.
245
Crunchy goes through a specially-prepared HTML page and augments it with
246
interactive Python boxes. These let you type single Python commands into an
247
interactive console (much more limited than the consoles such as Joshua) and
248
see ther results (it runs Python on the web server). It also provides edit
249
boxes for more involved samples.
251
The edit boxes use EditArea.
253
### Do we want to use this? ###
255
The console mode could be useful for very small examples. (But for just
256
"trying things out" a dedicated console is more useful).
258
For most examples I expect we'll just be using the editor mode of Crunchy. I
259
feel in this case we might as well just put our own edit boxes on there and
260
save the overhead of integrating Crunchy.
264
Crunchy seems to be intended for an individual to download and run. It sets up
265
its own web server and behaves like a user application (which happens to run
266
in the browser), not a web application. For instance, it displays a "close"
267
button hovering over the top of the screen. May require some modification to
268
integrate it as a web app.
added
removed
doc/notes/imports.txt
