The D Windowing System

Combined Executables Plan

One potential problem with the three part separation of concerns (viewer, manager, application) is that it is a pain to install. Well, it really isn't too bad, but it isn't as easy as it should be. Specifically, you can't just say 'here, download my exe and run it'. You have to say 'download this exe... and if you don't have it, the manager exe and the viewer exe and the dlls they might need'.

Moreover, there are potential performance increases to be had by combining the processes in certain cases. Now, there is a trade off in stability to be had, but this can be kept under control with testing.

Combining aspects is optional, and doesn't have much effect on the actual design. It is just a performance and deployment implementation detail. You'd be free to keep all separate programs too.

Manager + Viewer

The first combination that is possible is building a viewer into the manager. This has two advantages:

If you want to run programs locally, you just get the manager and run it, then your applications. No need for a third viewer program, though, of course, you can still use them for attaching when you are on a remote computer.
b) Performance might be significantly boosted when local. It could cut out the manager -> display protocol calls and instead just do it. Since client to manager is already a fast connection, this takes out the biggest block of slowness. It could do all kinds of tricks to further improve upon it. Low latency programs could hence be written for the DWS. While they wouldn't be low latency when connected remotely, you'd at least still be able to connect to them remotely.

There's some downsides too. First off, the viewer built in might just suck visually; I'll probably build it out of basic components to keep the size down. External viewers are easier to customize and increased dependencies on them are acceptable. This isn't too bad though, and is a solvable problem.

Another downside, one that's more significant, is if the viewer crashes for some reason, it takes down the manager too... which can take down all the applications. (Note: the API library could be improved, so apps don't need to die when the manager dies, but some stuff might still be lost.) With an external viewer, if it dies, just restart it and you're back to where you left off.

But, all in all, I think it has enough potential to go through with it before a final release.

Application + Manager

This one is a little weirder. The application and manager would still be separate processes, but they'd be bundled together in the same exe and live and die together.

What I mean by that is:

User downloads app.exe and runs it
App tries to connect to an already running manager. If there isn't one, it fork()'s itself and runs the manager in one process, and proceeds in the other.
User uses the app.
When he is done, he closes it. The manager, seeing no more open connections, terminates itself. Why? I find lingering processes that I didn't ask for to be quite annoying. If the manager is implicitly started, it should also implicitly die when its services are no longer required.
If he started a second app when app #1 was already running, it would attach to the existing manager. Only when both are dead will the manager off itself.

Since they are different processes, the crash safety remains the same. This is just ease of deployment and use by the end user. There's little to lose!

But, it isn't without its downsides. If the manager is packed with each app, that's going to be a lot of code duplication. There's two ways to mitigate this: bundle it with the API library, so dws.dll includes the manager image too, or just keep the manager fairly small.

I'm against shared libraries generally. Making users get a dll is a bit of a hassle, defeating the deployment ease of combining the manager and app in the first place.

Now, if there is a shared lib, that's the place for it, though all its internal functionality needs to be private. Then, you just point the user to the one dll and your app. That isn't so bad.

But, without it, as is the reality right now, we'd want to keep the cost low by keeping the manager small. Well, luckily, the manager actually is a fairly small program! It's job is to route requests and events to and from the proper displays and apps, and provide a single point to which users can connect. That's really not much. Most the code in there right now is the output of the code generator - half of which is also used in the client API.

So it isn't that bad. But, if I combined a viewer with the manager, which would give best results for a 'just run it' deployment, that might increase the size. If I keep it simple, however, this shouldn't be that bad. Most GUI code would be wrapped up in core operating system libraries, so the viewer needn't be a large program either.

This probably means using basic OS functionality for it, which on Linux, probably means ugliness, but not necessarily. Besides, if you hate it, just run an external viewer for prettiness. It'll be fine on Windows, however.

How does this impact the web app killer aspect?

There's some things that a standalone manager might want to do that an implicit manager most certainly should not do. One of them is multi user session support. How do you deal with this?

Easy: the necessary code to support this just won't be compiled into the built in manager. It could also take flags to lock it down further, possibly set by default. I'll go more into this as it starts to be implemented.

Conclusion

While there are trade offs, packing everything together does have some advantages which I find compelling. With this plan, DWS could directly compete with things like GTK, while at the same time, being able to live right next to it in harmony by using a gtk viewer. The ease of deployment is huge though: regular end users would never need to know it uses a different system until they are interested in the specific advantages offered here. (End users could also use viewers to run hosted applications, but that doesn't go away here. It is the best of both worlds.)

It isn't something I'll be implementing terribly soon, but I will be implementing all this eventually.