This is the mail archive of the
kawa@sourceware.org
mailing list for the Kawa project.
Re: GSoC 2011
On 04/07/2011 05:28 PM, Fattom Riddle wrote:
On Fri, Apr 8, 2011 at 3:03 AM, Per Bothner<per@bothner.com> wrote:
I think Websockets is almost the same as AJAX. Because Websockets
can't talk to Telnet or MUD, I have to make an adapter between them
too. Otherwise, if I have made an adapter to AJAX, it's easy to make
it work to Websockets.
AJAX doesn't support the needed bi-directional asynchronous
communication very well: At any time the user may perform an action that
sends
a command to the server. And at any time the server might finish some
action that requires updating the display. Think "type-ahead" - the user
may type a new command before the previous one finishes. And there needs
to be a way to abort a command if it is an infinite loop.
Plus AJAX is much more overhead.
What might be a useful is to support a generic read-eval-print package
that can be called from multiple languages and applications, including
MUDs. We can support/mentor it, if you commit to getting it usable for
Kawa first ...
Do you mean that when I implement Web REPL, I should think how to make
the MUD syntax as a plugin of Web REPL?
Of course not only for MUD syntax, but multiple languages^^?
Yes and no.
There are multiple parts of the project:
(1) Browser-side: A JavaScript library to manage the display, and react
to events.
(2) A communication protocol: At the very least we need to have the
server send
commands to insert text (as well as general XML/HTML) at the current
insertion point,
and have the browser send "input lines" to the server. Being able to
move the
insertion point, and delete/update nodes at server request is also
desirable.
Being able to send lower-level keyboard and mouse events to the server
could also be useful. Allowing using of ANSI terminal escape sequences
would be a convenient feature, especially if you wanted to implement an
"XML terminal". (This is not a priority, but you should allow for
the possibility that might be some command to move the insertion point.)
(3) The web server. If you have a well-defined protocol, you could have
multiple implementations of the server, in different languages: An "XML
terminal"
might be written in C/C++, and controls a PTY. A MUD client would talk to
a MUD server. A Kawa server would fire up a read-eval-print loop. (Similar
other other languages.)
(4) Invocation: It would be convenient to have a command or shell script
that starts up both a browser window and the web server. May be this could
be based on xulrunner or similar. (This is an optional enhancement, not
required.)
Doing (1), (2), and (3) should be doable in a Summer. You could probably
do both the Kawa REPL and the Mud client. However, we primarily care
about the Kawa REPL, so if you want us to mentor you, that is what you
will be evaluated on, and what you need to focus on. So you should change
the proposal to reflect that, if this seems interesting to you.
Note that Kawa has some support for a builtin web server:
http://www.gnu.org/software/kawa/XML-tools.html
There is even some aborted attempts at the Repl-in-a-browser:
See gnu/kawa/servlet/Repl*.java. However, it may be easier to first study
the Swing-based GUI in kawa/Repl*java. Basically, the idea is to replace
the "GUI toolkit" used in kawa/Repl*java to a "GUI" that uses a remote
web browser.
The Swing GUI is described in:
http://per.bothner.com/blog/2007/ReplPane/
--
--Per Bothner
per@bothner.com http://per.bothner.com/