A Web-enabled, Monad front end: Monad hosting.

Preston wrote a piece, pointing to an interesting Web application called "WebCmd". WebCmd makes your browser act like a console window. You type in commands, it executes them on a remote server, and returns the results. Currently, a-i-studio accomplishes the web-based interactivity via Javascript, with the heavy lifting performed by a server-side Perl script that executes commands.

It's a neat idea, and leads to even better ones (as Preston pointed out.) If we could have a fully-functioning web terminal over SSL, who needs SSH? In addition, who needs to worry about having access to a terminal emulator in order to securely administer thier machine? Although it appears that this demo gets us 90% of the way to running VI, it's really more like 0.01%

Like I said earlier, WebCmd makes the front end appear to be responsive using Javascript. You see characters as you type them, you can backspace, and you see a flashing cursor (for a few examples.) However, no interaction with the remote machine actually happens until you press the 'Enter' key. At that point, WebCmd batches your input and sends it off to the server. Then, it collects the response and displays it for you.

This falls quite short of the infrastructure required to support an interactive program such as VI. Let alone Emacs 🙂  There's no support for cursor positioning, keyboard polling, and much more. For the Unix world, take a gander at the feature set of the VT100 Terminal Emulation Requirements. For the Windows world, look at the Win32 Console API. To make a fully interactive web-enabled front-end, you would need to implement the equivalent of cmd.exe in Javascript. The performance would be atrocious. So in the end, it's attainable -- but at a very large cost. Once you're done writing that much Javascript, you're likely to start rocking back and forth, whilst arguing with yourself.

However, all is not lost. If we drop the requirement (and support) for the high-degree interactivity, a web-enabled front end does become a useful administration utility. SSL secures the data in transport, and protects you from man-in-the-middle attacks. By using Windows authentication (along with the appropriate permission sets on the server,) you can even prevent users from doing things they shouldn't.

This is a scenario that Monad allows you to accomplish much more cleanly than simply redirecting standard input and output from a console application. At its core, we've designed the Monad engine to be hosted by other applications. As long as the host application implements the functions from the hosting interface (below,) it can run and host most Monad cmdlets.

For example, our MSH.EXE is simply a host for Monad. Several enthusiastic members on BetaPlace have written a GUI host for Monad. Exchange 12 is built on Monad. And to bring this all full circle: one of the members in our team wrote a proof-of-concept ASP.Net host for Monad.

[Edit: Monad has now been renamed to Windows PowerShell. This script or discussion may require slight adjustments before it applies directly to newer builds.]

5 Responses to “A Web-enabled, Monad front end: Monad hosting.”

  1. Preston L. Bannister writes:

    At the risk of sounding overly-retro, the distance to a AJAX version of ‘vi’ is less than you think. You don’t need cursor positioning (you have HTML). You don’t need keyboard polling (client-side Javascript can move the cursor). What you *do* need is a way to tell the server-side about changes to the text.

    Flip this around. Think of ‘vi’ as simply a fancy wrapper around ‘ed’. All you really need is a means to send the equivalent of ‘ed’ commands to the server.

    Looked at from another viewpoint, this is an old/solved problem. The old Burroughs and IBM mainframes used terminals with a "forms" or "block" mode, where cursor movement was local, and explicit "send" keys were used to send cursor location, lines, or whole pages (which reduced the interactive load on the mainframe). One of the professors at UCI (Meehan) cooked up a full screen editor (a novelty in the late-1970’s) that I believe took advantage of the "page" mode in the terminals we used to allow local cursor movement.

    Yes, this would be a very mutated version of ‘vi’, but we have a lot more than 0.01% :).

  2. Lee Holmes writes:

    There’s no doubt that you can implement a lot of great applications in Javascript. VI is one of them, although I would probably prefer the Rich Text form that I compose my blog posts in. It still couldn’t be truly interactive with the server, but you could accomplish text editing remotely. So, if we’re talking about implementing individual programs to implement individual tasks, then yes — we’re much further than 0.01% along. However, as a general remote administration framework, you’ve gained nothing.

    Even if you build an app to enable remote text editing via a web browser, you still can’t automate the _actual_ VI program, or Emacs, or Top, or pretty much anything else. For general remote administration, WebCmd is about 0.01% of the way towards allowing you to use VI (without any specific VI hooks.)

    And you’re right… this problem was solved a long time ago. As I linked to in the post, the VT100 terminal protocol (amongst many others) allowed you to work with fully interactive programs. SSH operates in exectly this way. However, it does require a very low latency connection, and that both your client and server application speak the same protocol. Like I said, it’s doable — but only after implementing the equivalent of cmd.exe in Javascript.

  3. Mike Hoskins writes:

    You might want to have a peek at this open source project: JS/UIX: http://www.masswerk.at/jsuix/

    I first saw this project at Slashdot: http://developers.slashdot.org/article.pl?sid=05/06/16/1212215&tid=130&tid=108

    It is a Unix-like command line for JavaScript. It does not network (AJAX can fix that), but it does do much of the Unix command line, including vi, environment variables, in-memory "files," redirection, piping, shell, Unix commands, directories, etc. It’s pretty cool.

    I’m waiting for somebody to implement ssh or at least telnet over SSL via AJAX and have a VT100 terminal back to a server, all over http, to avoid firewall problems.

  4. kkc writes:


  5. Mike Bergsma writes:

    Did it. VT200 emulation. Pure AJAX. SSL It was difficult to say the least. It launches with a CGI script, or it is downloadable.


Leave a Reply