dmd support for IDEs + network GUI

[Adam D. Ruppe]

On Mon, Oct 12, 2009 at 09:06:38PM -0400, Nick Sabalausky wrote:
> Excellent! Sounds exactly like what I had in mind. I'll definately want to 
> keep an eye on this. Any webpage or svn or anything yet?

Not yet. I've discussed it on random forums (in various states of development)
but haven't written up anything cohesive at all. I'd tar up my code as it
is right now, but it is a huge mess with outdated notes and my real passwords
just hardcoded in there.... it isn't suitable to go public at all, sadly.

I'll try to fit in a few hours to clean it up over the weekend though.

> Have you given any thought to security? 

A little bit, but not a lot. I was thinking the viewer could be as locked
down as it wants*, but I've just been considering it an implementation detail
so far.

* Any app should be able to gracefully handle permission denied errors on
  file writing, so it shouldn't be hard to code up.

The viewer could also run as a restricted user, using the operating system's
protections to keep it in check.

> How do you have the client-side working from the perspective of a new user? 
> Ie, Do they still need to install each app (or at least each app's client) 
> individually, or is it just a one-time install of the DWS library?

It is just a one time install of the viewer, if you want to run remote
programs. If you want to run programs on your local box, you need to get
the library (well, not really, since it is statically linked, but conceptually)
and the app manager, which runs in the background.

The manager seems like an unnecessary step, but it abstracts the app and
the viewer from each other. The app connects to the manager on localhost
and gives it the instructions to forward to the viewer.

Next, the viewer also connects to the manager. The manager presents it with
a list of active tasks. The viewer selects a task to attach, and then the
manager shoots its current state down to the viewer, allowing the user
to use the program.

If the viewer crashes, no big deal - just restart it and pick up where you
left off.


But anyway, from the end user perspective, he just needs to grab the viewer
and connect to the right server.

> If the 
> latter, how do they find/launch a remote program? I ask because one of the 
> things that web-app fans like about web-apps is that they're "no-install", 
> at least beyond the installation of the platform (ie, browser) itself. But 
> I've always felt there's no technical reason why it shouldn't be possible to 
> have a link to, for instance, 
> "dws://www.somedomain.com/apps/someGUIApp?cmdlineparams" and have that 
> launch the client's remote-GUI toolkit on that "someGUIApp".
> 

Exactly. The way my current implementation works is you just run the
viewer and connect it to the server, using plain old TCP (tunneled over
SSH for auth and encryption right now, but that might change)


The process looks something like this:

 > Connect
 < App #1 "Notepad" running, App #2 "IM" running

 The user can view this in a variety of ways. My Qt implementation gives a
 list widget, which the user double clicks the one he wants.

 > Attach app #1
 < CreateWindow, Create text widget, set text widget contents, etc.

 The user now sees the program and interacts with it. Or, he can launch a 
 new program -

 > Exec app "/app/notepad"
 > CreateWindow, .....


While my implementation currently uses a GUI list, it could just as well
be a command line or a URL.

Eventually, I'd like to make it Just Work on hyperlinks - it should be easy
enough to rig something up so it downloads the viewer and connects all
transparently to the user.


-- 
Adam D. Ruppe
http://arsdnet.net