Remote Gui Protocols

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:

Protocols that rely on low-level transport (TCP/IP) and low-level client executable/library:

Protocols that rely on high-level transport (e.g. HTTP) and high-level runtime (e.g. scripting inside browser):

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:
There is a project named Vedga (former 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.]

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: 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.
See WebFormMethodologies, WebsitePatterns, BrowserAbuseSyndrome, ProgrammingLanguageNeutralGui, GuiMachineLanguage, GuiMarkupProposal
CategoryUserInterface, CategoryInternet, CategoryWebDesign CategoryGui

View edit of August 21, 2011 or FindPage with title or text search