This is to document and discuss various GraphicalUserInterface protocols that have come into existence or have been proposed to deal with distributed and/or standardized GUIs.
We need an HTTP-friendly GUI protocol in order to satisfy the requests of managers and users who want to make HTML-based Web pages look and act like GUIs found in applications built with VisualC++, GTK, VisualBasic, BorlandDelphi, PowerBuilder, KDE, etc. (BrowserAbuseSyndrome) HTML and its extensions (DOM, DHTML, JavaScript, etc.) act like an afterthought add-on rather than a solution.
Factors to compare by:
- Proprietary versus open standard
- Bandwidth and response-time requirements
- HTTP-friendly to avoid fire-wall bureaucracy
- Execution reliance - reliance on client-side ScriptingLanguage or TuringComplete execution language for app-specific functionality
- Maturity (road-tested)
- Target domain: business forms, games, CADD, etc.
- Base language type (XML, etc.)
Protocols that rely on low-level transport (TCP/IP) and low-level client executable/library:
- VirtualNetworkComputing (VNC) - Can be bandwidth intensive because it is generally an image mirroring technology, in contrast to techniques that treat screen widgets as abstract concepts.
- XwindowProtocol - heavy bandwidth requirements, does not rely on client-side scripting, not HTTP-friendly
- Of course, when dealing with X you have to be careful what you mean by "client" and "server". In X jargon, the "client" is the end-user application, which may run on a central machine; the "server" is the program running on the terminal which provides display and user-input services. In other words, many networks consist of ThinClients running X-servers providing UI services to X-clients running on large ComputeServers. Got that? Keep in mind that the context here is "remote".
- X protocol is also generally not appropriate for running over the Internet, for many reasons besides bandwidth. [Latency is the only real problem I can think of; even with good bandwidth a GUI is pretty sluggish when it takes 100ms just to send "mouse moved!" to the program. If you're thinking of security, tunneling over SSH is the normal thing to do.]
- Are you saying that what dogs X will also dog other protocols? X is too low-level from what I know. For example, each character you type has to make a round trip before it appears in a text box. An HTTP-friendly protocol would not need such a round trip (unless explicitly told to wait on or monitor such events).
- Any kind of sophisticated GUI requires at least the possibility of this sort of event model. X is pretty low-bandwidth, a dial-up line is fine. The latency is the issue and that will (and does) dog any streaming protocol. Batch protocols like HTTP have their own (different) problems.
- See ItsTheLatencyStupid
- The latency can be avoided if common processing is done on the X server. This is certainly true for text widgets: "each character you type" should not have to make a network roundtrip. Too bad that the BerlinProject? went nowhere and its ancestors InterViews and FrescoFramework are long dead.
- Note that X can be optimized for low bandwidth and/or high latency links quite well. Low bandwidth X (LBX) is quite old and already quite an improvement, NX from nomachine.com is rather recent and achieves miracles by cutting down on roundtrips.
- Remember, low bandwidth and latency are two different kinds of problems, sometimes related and sometimes not.
Protocols that rely on high-level transport (e.g. HTTP) and high-level runtime (e.g. scripting inside browser):
- GTW (GoogleWebToolkit)
- MozillaXul - XML-based, HTTP-friendly, relies on client-side-scripting
- XWT - XML-based, HTTP-friendly, relies on client-side-scripting
Other protocols:
At first glance, none of these are "protocols". For a second glance, defenders should explain otherwise, or split this list into protocol vs nonprotocol, or something:
- JavaApplet - heavy reliance on client-side executable. Tends to require entire app be loaded instead of dividing up by as-needed modules or screens. Interface awkward on some OS's.
- HTML alone - Has to be regenerated per communication
- HMTL+DOM+JS scripting, now called AjaxWebApplications -- HTTP-friendly, ...
- Curl
- SCGUI - XML-based, HTTP-friendly, does not rely on client-side scripting, immature
- Droplets
- Kenamea
- The Y Window System (http://www.y-windows.org/) -- still in its infancy, aspiring to replace X Window.
- ScalableVectorGraphics + JavaScript
- WHAT - Web Hypertext Application Technology (http://www.whatwg.org/) Still in the works
- NetworkAsComputer - Where the DataExchangeProtocol? is more like PeerToPeer than ClientServer and the application run on the local machine blends local execution, remote execution, and data exchange into a process patterned after HumanConversation?, using HumanConversationAlgorithm?s.
There is a project named Vedga (former Glan, sourceforge.net/projects/glan/) which offers unversal component-drawing client (somewhat like a player or browser) and all GUI is processed at the server (process per client). It is built on the Qt library and protocol thinks in terms of Qt objects, slots and signals -- high-level enough for protocol to be really fast. -- nuclight
What seems hardest to standardize are widgets such as editable grid widgets and tree/outline browser/editor widgets. These are the last that implementers "get right".
[There's a difference between a GUI protocol and a widget set. X Windows, for example, provides no widgets at all, only basic GUI services. The rest is handled at a higher level. At the other extreme, HTML/other markups provide ONLY widgets. Editable grids aren't especially difficult, but making a one-size fits all one is, if it's even possible.]
- And this is exactly what makes X sluggish! The widget kit is run on the client, therefore everything that is more sophisticated than static rectangular windows requires a network roundtrip. Some of that processing could easily be done on the server.
When I imagine a remote GUI protocol I image a set of widget primitives, but also the ability to represent more primitives that run locally. Using the browser as an example, the server would define it's custom tree-editor as a combo of html,css,and js that runs locally and quickly, then builds upon that new primitive.
There seems to be some debate about whether you need a TuringComplete scripting language embedded in the protocol to get decent performance over HTTP. Makes for an interesting debate.
Is being "HTTP friendly" a good thing? I would think that for many GUIs it most certainly is not. I don't want arbitrary applications to be able to make their GUI available through the firewall.
How are HTTP GUIs more dangerous than HTML interfaces, JavaScript, Java applets, Flash, etc?
I would think being HTTP friendly is important because of backward compatibility. If everyone is currently using HTML today, it would make sense to design a ComponentBrowser or RemoteGuiProtocol which offered HTML capabilities. My idea with a ComponentBrowser is that you could have one HTML component as just a part of the web browser. But not to base the entire browser on HTML. HTML could still be useful when creating documents. Another component that people might use is an RTF component or a component that used some markup similar to wiki's. No-one wants to create HTML just for simple pages, yet currently we are limited to having to do that.
We need to make a distinction between HTTP-based and HTML-based. They are not necessarily one and the same.
Judging things by their "HTTP friendlyness" is a stupid misdevelopment of the dotcom era. A simple port filtering firewall or even a http proxy is useless, because these days everything can be tunneled. It's actually worse than useless, because it forces protocols to insane contortions instead of simply opening a tcp connection. If it doesn't work through a firewall (whatever "it" is), it is the fault of the firewall.
Anyone here considered RichInternetApplication as a workable option to deliver high bandwidth of communication, without the deployment issues associated with client server apps?
Most producers and promoters of RemoteGuiProtocols that target HTTP appear to think so. Related: WebGuiWikiPoll.
I think it's not just about the GUI and a protocol for the GUI, though.
I think it's mainly about the following issues:
- The software that runs instructions from the server. HTML are the only current instructions from the server that the client reads (and javascript).
- the software that handles the instructions. Currently software handles HTML and JavaScript instructions. Yet clients like email who connect to the web never rely on HTML in structions.
- In other words, we don't need just HTML instructions, and the software that connects to the net does not have to display just HTML. It can display other things, and respond to other instructions. We just have to make some standards, so that everyone out there isn't going out and creating their own thin-clients everywhere (ComponentBrowser brings them all together).
Since HTML is simply parsed on the user's machine, we could still use HTTP as the protocol for something like a component browser. I think the problem is not mainly the protocol, since HTTP could do the job currently. I think the main problem is that people are too lazy and stubborn to think up and create a browser based on something other than HTML, since people have already done so much work in HTML. They keep extending HTML and extending it more, instead of deciding that the HTML e-brochure can only go so far before it looks ridiculous. The last ridiculous item I saw on an HTML website was a dropdown menu which took a few seconds to load (instead of instantly in a software application).
Moved discussion to ClientSideAppDataCaching.
I've toyed with the idea of the modification of predefined processes, attributes, using some InventedProcesses? and DataStructures in combination with a DesktopApplication? and a Desktop controlled WebSite to customize a User-Centric-Model of PersonalInformation?. There are some ideas here which I think I can use. I have always believed that if one is willing to do the hard work required, manageable problems can be solved by clever solutions. Through PositiveDialogue and careful attention to the suggestions and approaches which one will encounter while involved in, or while observing it, there always seem to be possible avenues of solution. While one may not be totally successful, Progress can be made, especially if one does not stop trying regardless of how slowly one might be moving toward that solution.
http://74.125.93.132/search?q=cache:FsmAgLDElaYJ:www.enterpriseinnovation.net/content/through-knowledge-focused-lens+It+does+not+matter+how+slow+you+go+so+long+as+you+do+not+stop.%22+Confucius&cd=5&hl=en&ct=clnk&gl=us
See WebFormMethodologies, WebsitePatterns, BrowserAbuseSyndrome, ProgrammingLanguageNeutralGui, GuiMachineLanguage, GuiMarkupProposal
CategoryUserInterface, CategoryInternet, CategoryWebDesign CategoryGui
Remote Gui Protocols