GSoC 2011

[Fattom Riddle]

Dear Per:

I think you mean you want the browser show the rich UI result.
So, we have a communication protocol to handle this?

But, how does the rich ui result work?
I mean it's easy to show rich ui result, but it's hard to assign an
event on a rich ui result.
For example, how to make a button which can show alert message?

Best Regards,
Evans


On Fri, Apr 8, 2011 at 9:03 AM, Per Bothner <per@bothner.com> wrote:
> 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/
>