← Back to branch summary

~azzar1/unity/add-show-desktop-key

« back to all changes in this revision

Viewing changes to doc/notes/imports.txt

  • Committer: William Grant
  • Date: 2009-01-13 01:36:15 UTC
  • Revision ID: svn-v3-trunk0:2b9c9e99-6f39-0410-b283-7f802c844ae2:trunk:1123
Merge setup-refactor branch. This completely breaks existing installations;
every path (both filesystem and Python) has changed. Do not upgrade without
knowing what you are doing.

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/notes/imports.txt
 
1
IVLE - Imported Code (Investigation)
 
2
====================================
 
3
 
 
4
    Author: Matt Giuca
 
5
    Date: 4/12/2007
 
6
 
 
7
In this document we look at various libraries and code around the Internet
 
8
which we might use in IVLE.
 
9
 
 
10
Console
 
11
-------
 
12
 
 
13
There are a few JavaScript consoles available (written in JS, for JS).
 
14
 
 
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.
 
18
 
 
19
Our prototype uses WebShell at the moment.
 
20
 
 
21
### Discussion: Full terminal vs console emulation ###
 
22
 
 
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.
 
26
 
 
27
Joshua and friends are basic command-line emulators, while WebShell and
 
28
AjaxTerm are full-blown terminal emulators.
 
29
 
 
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
 
34
the updated screen.
 
35
 
 
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.
 
41
 
 
42
### Full terminal ###
 
43
 
 
44
#### WebShell ####
 
45
 
 
46
[WebShell](http://www-personal.umich.edu/~mressl/webshell/).
 
47
Based on Ajaxterm.
 
48
 
 
49
This is what we use in the PynApple prototype.
 
50
 
 
51
Looks a bit heavy (has a clunky iPhone interface - might drop down to its
 
52
lowest-common denominator, Ajaxterm).
 
53
 
 
54
#### AjaxTerm ####
 
55
 
 
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.
 
59
 
 
60
Says its based on [AnyTerm](http://anyterm.org).
 
61
 
 
62
#### AnyTerm ####
 
63
 
 
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.
 
66
Yuck.
 
67
 
 
68
I haven't been able to get it to compile yet.
 
69
 
 
70
This isn't really desirable for the end product but we can use it for now to
 
71
get a console working quickly.
 
72
 
 
73
### Client-side (line) shells ###
 
74
 
 
75
#### ajaxPHPterm ####
 
76
 
 
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.
 
80
 
 
81
It simply sends the text to the server and when the server responds, it prints
 
82
it to the screen.
 
83
 
 
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.
 
87
 
 
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:
 
90
 
 
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
 
99
  wrap?
 
100
 
 
101
#### Joshua ####
 
102
 
 
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.
 
105
 
 
106
#### JavaScript Shell 1.4 ####
 
107
 
 
108
[JavaScript Shell](http://www.squarefree.com/shell/shell.html)
 
109
Also JavaScript based.
 
110
 
 
111
#### Termlib ####
 
112
 
 
113
[Termlib](http://www.masswerk.at/termlib/).
 
114
Ajax shell, looks very generic (no default language or connection). Has
 
115
floating windows.
 
116
 
 
117
Restrictive license (noncommercial).
 
118
 
 
119
Text Editor
 
120
-----------
 
121
 
 
122
Two online (JavaScript-based) editors are [CodePress](http://codepress.org)
 
123
and [EditArea](http://www.cdolivet.net/editarea/).
 
124
 
 
125
We have used EditArea in the prototype. Crunchy uses EditArea.
 
126
 
 
127
[Comparison](http://www.virtualroadside.com/blog/index.php/2007/06/08/codepress-vs-editarea/).
 
128
 
 
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.
 
132
 
 
133
Oh, and CodePress doesn't support Python syntax. That's a bit of a
 
134
deal-killer.
 
135
 
 
136
EditArea seems a bit bulky. Can we trim it down a bit (especially for the
 
137
tutorial sheets).
 
138
 
 
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.
 
143
 
 
144
Subversion Client
 
145
-----------------
 
146
 
 
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).
 
150
 
 
151
Most web clients are repository browsers, not workspace.
 
152
 
 
153
What we need is an interface quite like TortoiseSVN but for the web.
 
154
 
 
155
### Polarion ###
 
156
 
 
157
We have been using [Polarion](http://www.polarion.org/) [WebClient for
 
158
SVN](http://www.polarion.org/index.php?page=overview&project=svnwebclient)
 
159
in the prototype.
 
160
 
 
161
Apache license.
 
162
 
 
163
Nice feature-wise. Backend written in Java. Lots of confusing buttons
 
164
everywhere (perhaps not good for entry-level students).
 
165
 
 
166
### Our own browser? ###
 
167
 
 
168
Considering writing our own browser?
 
169
 
 
170
Advantages:
 
171
 
 
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).
 
175
 
 
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.
 
179
 
 
180
So we aren't writing an SVN browser at all, but a web-based file browser with
 
181
SVN client support.
 
182
 
 
183
(Are there any web-based file browsers we can adapt?)
 
184
 
 
185
Seems as though writing our own would be simple enough when weighed up against
 
186
finding one and augmenting it.
 
187
 
 
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).
 
191
 
 
192
This means either:
 
193
 
 
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").
 
198
 
 
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?)
 
201
 
 
202
### SVN Web Control (SWC) ###
 
203
 
 
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.
 
207
 
 
208
Implemented in PHP. Awful documentation.
 
209
 
 
210
Gives errors when I try to run and the documentation is just API docs, no
 
211
installation guide... Scratch this?
 
212
 
 
213
Web-based file browser
 
214
----------------------
 
215
 
 
216
I made a separate category here for web-based file browsers which we can
 
217
possibly build into a Subversion workspace client.
 
218
 
 
219
There are many online file browsers. We'd prefer one written in Python but I
 
220
haven't found any yet.
 
221
 
 
222
Alternatively, do we want to use WebDAV? (I'm not familiar enough with WebDAV
 
223
to know its limitations).
 
224
 
 
225
### Online File Browser ###
 
226
 
 
227
[OFB](http://filebrowser.mbsoftware.pl/quick-start). PHP. Live demo available.
 
228
MIT license.
 
229
 
 
230
Uses Ajax. Looks and feels nice and stable.
 
231
 
 
232
Dependency on ["Smarty" template engine](http://smarty.php.net/).
 
233
 
 
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,
 
236
etc?
 
237
 
 
238
Crunchy
 
239
-------
 
240
 
 
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.
 
244
 
 
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.
 
250
 
 
251
The edit boxes use EditArea.
 
252
 
 
253
### Do we want to use this? ###
 
254
 
 
255
The console mode could be useful for very small examples. (But for just
 
256
"trying things out" a dedicated console is more useful).
 
257
 
 
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.
 
261
 
 
262
### Notes ###
 
263
 
 
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.
 
269
 
 
270
MIT license.
 
271