A picture is worth 1000 words:
I don't get it. Why is this different than X, VNC, or Citrix?
The way most remote desktops work is by running an application locally and sending the graphical data over the network. So they're sending (compressed) pixel data across the wire. NTW doesn't.
To understand the difference, think of a client/server chess program. The X way of handling this would be to run the program, and any time what would appear on the screen changes, it would send the new graphical data over the network to the player's screen. Any time the user clicked on his view of the program (to move a piece, for example) X would have to update its data, recompute how the board would look, and send that back.
The ntw protocol does not send graphical data, leaving it completely up to the Client to draw widgets. So the NTW way of doing things would be more like sending messages like "Pawn at d2 to d4."
Why is this better? Well, one reason is that network latency is a huge barrier to UI responsiveness with the X method. The user won't ever see the result of his interaction with the program until a message has been sent back to the remote X program and then that program sends a message back. (Synchronous communication). So if sending a message back and forth takes 1 second, the user will see a 1 second delay each time he clicks or types something. Note that increasing bandwidth does not affect this problem, as it's the latency that's the problem. (Although NTW data is extremely compact bandwidth wise also)
NTW uses asychronous communication in the overwhelming majority of cases. Since the NTW Client is responsible for the graphical data, it can update the graphics immediately upon receiving an event from the user, and then send a message to the NTW server indicating what happened. So a button will always "click" immediately, even though the actual state on the server make take a second or so to update.
No, no, and no. In each of these cases, the UI is separated from the "application data and logic," so the developer has to develop a UI in addition to, and separately from, the actual program that does things. In these cases, the User still has to download the UI portion and store it locally in order to run the program. If the UI or application code changes significantly, the User also needs to download a new version of the UI. This also tends to enforce the "sequence of forms" or "wizard" style of application, which is what NTW tries very hard to avoid. (XUL is actually much more client-based than described here.)
No. Actually, as far as clients go, it's relatively fat, although we prefer to say it's big-boned. Unless an application is storing a huge amount of user data, the GUI portion usually takes up much of the program's memory footprint. Since the client is responsible for all of the drawing, the user won't see much of an advantage memory wise to running an NTW application over a local one.
What's the advantage then? Well, the server's memory footprint is tiny. The current ntw-demo program which includes all of the widgets currently implemented takes up about as much memory as /bin/sh, and about half that of an ssh daemon. So, a single server with 512MB of RAM can serve over 500 instances of the ntw demo program without swapping and with zero loss of responsiveness on the Client side.
When it finally does start swapping processes out, no responsiveness is lost, as GUI programs remain idle most of the time, and the server will only run those that receive data from the network. So technically speaking, the only limit to the number of applications that can run concurrently is available swap space. This brings the maximum number well into the thousands.
The potential number of clients for the Lisp and Java servers are much greater, due to the fact that no new processes are created to handle new clients, so the memory footprint is generally much smaller. So the limit there usually is the number of sockets you can have open.
Isn't this all very complicated for the developer?
No more compicated than learning and using a traditional GUI toolkit. The NTW developer API is a simplified version of GTK and Java Swing, so if you're familiar with those, you'll feel right at home.
The entire network portion is hidden from the developer, so he can code just as he normally would code for a local app.
That's so simple, this must have been done before.
We think so too, and we can't understand why nobody has, or if they have, why we haven't heard about it. The closest thing in theory is probably Display Postscript or NeWS. However, those were still concerned with having drawing code on the server side, even if it was mostly interpreted by the client. NTW has NO drawing code on the server side.
Why should we care about this? Can't we just use XUL or EJB?
NTW is a very different technology than EJB, XUL, X, Citrix, etc, and we're not trying to say that nobody should use those tools. If they fit what you want to do, be our guest.
If you're interested in serving thousands of remote clients with a single, inexpensive server, and having the users of those clients be unable to distinguish between your app and one compiled and running locally, NTW is for you.
Is speed the only benefit?
There are many more benefits to our approach.
The first is portability. Since NTW is a network protocol, any language or computer architecture that can write bytes to the network can use it. The first NTW test over the Internet, for example, was done with FreeBSD serving a Windows XP client. We'll be developing server bindings for multiple languages too. The C server library is the reference implementation, and Java and Python versions are soon to follow. We're also very interested in developing Scheme and Lisp implementations.
The second advantage is persistence. The NTW protocol can be used to write to disk just as easily as writing to the network, so we can save the exact state of applications to disk, very compactly. This way, if a user disconnects or his computer crashes or power goes out, he can resume his application in the state that he left it upon reconnection.
Finally, the Client program is all the user needs to run any NTW app, so the developer can deploy apps on a server, just like a web page. There's no need for the user to download each program separately, so bug fixes and feature releases can be made completely transparent to the user.
I know C, Java, Python, Lisp, Scheme, and bf. How can I help?
Subscribe to the ntw-devel mailing list, and read the archive. It's a great way to get up to speed with the project. Also read the protocol documentation on this web site, and browse over the code. The protocol is currently in a state of flux and will be for the next couple of months, so it's a moving target for language implementors, but any code or patches are extremely welcome.
The latest version is always in CVS. We try to keep the code clean and compiling with no warnings.