Þ   briarpig  » gui

     I'm suggesting it's an interesting idea to blur the development and deployment environments — blur them a lot — so there's not really two different modes. This is common in IDEs (integrated development environments) structured as client apps, but rare with an IDE running as a server, as far as I know.

daemons

     I'd like to structure an IDE as a local server daemon process which is always running — except when you shut it down — and using one or more ports to communicate with one or more user interface processes. Obviously when using different ports, you can have as many local daemons as you want. So this model looks very conventional to a user, except there are more processes.

remote

     Given this arrangement, there's no reason why a daemon IDE must be local. It's just a server that might be local or remote. So there's no real reason why an IDE must be all that different from an HTTP server, which has exactly the same character. It's only when a web server is bound to privileged port 80 that it seems special, and merely because it's the well known HTTP port.

fusion

     I not only want an IDE to resemble an HTTP web server, I want one to be an HTTP server. The port(s) serving HTTP requests would be just one alternative way to talk to an IDE daemon. It's actually quite common to have a web interface as GUI to many network services, in lieu of having some more conventional (and presumably more expensive) client graphical interface.

browsing

     Basically you can use a web browser to browse anything that's willing to respond to the HTTP protocol. And this is really convenient when browsing things that normally don't have a GUI — suddenly you can do administrative tasks the same simple way one does other things in other web apps. But you could also do the same thing with apps that already have GUIs, like an IDE.

visibility

     Suddenly it might start seeming feasible to expose visibiliy into IDE internals that previously seemed too expensive to justify in a specialized hand-crafted ui. Now you don't need to justify anything: just expose the relevant data when a suitable HTTP request names the content with a URI. All an IDE needs to do is map information into a namespace addressable by URLs.

scripting

     Here's the really interesting thing: you don't need to decide statically (at compile time) what your IDE server is able to expose at runtime from a web interface. The mapped URL namespace can change dynamically at runtime, and you can generate whatever you want for any given HTTP request. What you send to the server at runtime in requests can dynamically change namespace(s) and related services.

webkit

Since I wrote the rest of this page, I became aware of WebKit, which looks like a good thing to try out.

     Choose one of these demos for sample code and related docs, developed together to motivate þ C++ code for this purpose.

     mu: toy, peg, imm, tag, box, symbol, token, number, bigint, class, method, reader, writer, eval, env, vm, gc, world, pcode, compiler, asm, lathe, lisp, smalltalk, design, weight, jar, card, harp, debug, profile

     thorn: todo, names, iovec, assert, log, run, hex, crc, buf, in, out, quote, escape, compare, file, deck, cow, arc, blob, tree, slice, rand, time, stat, heap, node, primes, page, book, pile, stack, atomic, lock, mutex, thread, map, meter, list, iter, ctype

ria

     Lately folks have been talking about RIA (rich internet applications) and the interaction between normal browser based web apps, and other kinds of client interfaces. Apparently some of the discussion is founded on the odd idea that non-web interfaces displace the use of HTTP protocol, when this doesn't necessarily follow.

parallel

     You can easily have a server with two (or more) simultaneous interfaces serviced in parallel, one by HTTP for browsers (or any other HTTP consumer) and others by any protocol you like. Nothing stops you from using one or all in some mixed fashion, with crossover between the them all, so it doesn't really matter which protocol you've been using when you send a new request.

both

     As an example, you could use both types of interfaces when developing a web server. Suppose your remote web server is actually running in your IDE, which also lets you connect via the protocol used by your local client app, which looks like other desktop IDEs. You can open a browser on your server and your IDE client too at the same time, and watch changes to web pages as you work in the IDE — live debugging. And given the web interface, you can still develop your server from any browser if you don't have access to your desktop.

migration

     If you really like your native desktop client ui, you might decide to start migrating parts of it to the web interface, by putting some of the smart pieces into Javascript (or Flash or whatever). Depending on how your desktop IDE works, you might be able to have it generate the javascript your server should return in HTTP, in order to get an ajax style look and feel in the browser. You could change the javascript returned dynamically, without a server restart.

graphs

     I once used to tell other developers that all applications were just big graphs of code and data distributed in certain patterns. You can walk through any path in the graph, either in code or the data, by serializing a representation of the nodes and arcs in the path using URI syntax. The only thing stopping such URLs from being useful in your servers is the code to interpret the URLs and act on them.

     A pending sibling page (wyv) is about possibilities along these lines with paths in virtual file systems. Of particular interest is changing server behavior by editing and versioning parts of paths understood as server URLs. The general idea might be familiar to Linux developers who recognize a taste of the proc file system here.

anticlimax

     Much of this material is obvious to lots of people who just haven't been looking at the details in quite this way. From them I'd expect yawns. But a few folks might be startled by possible options that come to mind which were always there, but not considered. Perhaps the longer you think about it, the more likely you are to realize you already knew all this.