Re: GSoC 2011

[Fattom Riddle <fattom dot riddle at gmail dot com>]

Dear Per

Thanks for your specific comments!!!
It clears lots of questions.

But in my original thought, I don't imagine (2) a communication protocol.
I am not sure what a communication protocol does.

I think there are several steps to process the task.
1. A browser send my input lines(scheme syntax) through POST/GET to server.
2. Server eval the inputs and return result (XML or JSON format ).
3. A browser get the pure text results and show.

So does a communication protocol mean we should have a request format in step1?
Or you mean the web console can show rich results but not pure text results?

Otherwise, should we have a configuration to define which IP address
can access the web console?

Best regards,
Evans


> 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/
>