This is the mail archive of the kawa@sourceware.org mailing list for the Kawa project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GSoC 2011


On Fri, Apr 8, 2011 at 3:03 AM, Per Bothner <per@bothner.com> wrote:
> On 04/07/2011 10:28 AM, Jamison Hope wrote:
>>
>> I think if you implemented a generic browser-based remote REPL for Kawa,
>> and not specifically a communications layer for a MUD client, that could
>> provide you with your web interface while also adding some fundamental
>> capability to Kawa that we are interested in seeing.
>
> Agree 100%. ?Some further notes:
>
> Kawa already includes a telnet library - see the classes kawa/Telnet*.java.
>
> Regardless, for a "web mud client" I don't see where telnet comes in - at
> least not for communicating to the web browser. ?(I guess it might come
> in when communicating with a MUD server.) ?I suspect the best thing to use
> for communicating between the application and the browser is HTML5
> "websockets"
> - they're not quite standardized yet, but some browsers support them in
> prototype form.
I try websockets before.
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.

>
> 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^^?

>
> An interesting related follow-on project is something like the old XMLterm:
> http://www.xml.com/pub/a/2000/06/07/xmlterm/index.html
> The brower end (including JavaScript and webscocket protocol) would be
> the same, but the application end could be a C/C++ API talking to a PTY
> interface. ?It could probably be also done from Java, perhaps with some
> native code to start a pty.
>
> (The XMLterm successor should be a separate project, but it would be
> good to keep it in mind when designing the protocol.)
> --
> ? ? ? ?--Per Bothner
> per@bothner.com ? http://per.bothner.com/
>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]