If DWS is to kill web apps, it must do what they do at least as well as they do it. One of their stronger points is that anonymous users can connect and get to their own session of the application to use. With some kind of authentication, or even just client side session IDs in cookies, they can go back to where they left off later.
We can do way better.
First, let's discuss how the manager works under normal (non-web app killing) situations, with users who exist on the operating system. Then, we'll go into anonymous sessions, and finally, internally authenticated users.
Here, the manager doesn't listen on TCP ports at all. Instead, it creates local machine endpoints, protected by operating system permissions, so only the user who spawned it can access it. A viewer on localhost can just access this socket directly, since it is running as the appropriate user. A remote viewer must ssh into the box as the user, and set up some forwarding to talk to the manager.
The manager itself doesn't do any authentication: it depends on the underlying operating system to do it for it, and it depends on the OS' protections to keep other users out.
The benefits here are that it runs as a limited user, it doesn't needlessly duplicate operating system protections, and it gets encryption. The downside is the wrapping slows things down a wee bit when remote, but not my much. It is still plenty fast.
FIXME: how will all this work on Windows?
Things are much simpler for anonymous users. If the manager allows it, it will listen on a TCP port to allow random viewers to connect. They need no authentication at all: they just connect and are presented with the task list.
You can use TCP to get the same thing you get over the OS authenticated channel (such as how my DWS demo is set up now), but the real benefit here is if it spawns a new session for each new viewer that connects. Hence, multiple users can be connected to it by TCP at once and work separately from each other.
The way this works, as an implementation note, is for the manager to fork itself entirely to manage the new user. The main manager thus is just a gateway.
On a perfect operating system, the manager could fork itself and create an OS subuser all at once, but the perfect operating system doesn't exist yet. This means all managers run as the same OS user, which really has to be somewhat locked down, but maybe some magic could keep files going. Hmmm...
The next step from anonymous users is to be able to authenticate a returning user. If he starts a session and would like to come back to it later, he should have a way to do that. Simply sending a username and password could do the trick - it is good enough for web apps, so it can be good enough for me too.
The gateway manager might have to be fairly different than the standard manager. I'm thinking now that it should in fact be a wholly separate program.
On anonymous connections, the local file access on the viewer might be problematic. While the user could instruct his viewer to shut that feature off, we might want to take it a step further, and have it either off by default for all these, or maybe even prohibited at the manager level - hence protecting a user with a broken viewer too.
But, what if he wants to upload a file to the server, like he can with web apps? Or what if he wants to download a file from the server? Both of those do imply some level of local file access, and both need to be permitted.
I think these might warrant some protocol extensions, but it requires further thought.