Gui Service

I've been trying to push the idea of GUI's as a service, NOT as an API tied to a specific language and/or OS. That's so 90's. The concept keeps popping up in different topics such that I wish to consolidate the idea on a single topic rather than re-explain it. The advantages of a service include but are not limited to:

Less re-retraining when making GUI's for another language or OS.
No need to reinvent library-creation for each programming language. A COBOL application should be able to use a widget implemented in Eiffel and vice verse, for example, so that we don't need to recode much for different languages. Most existing GUI engines fail badly here because they tie their architecture to the object model of a specific language.
- CORBA for GUIs?
- CORBA has a bad reputation as being convoluted and verbose for even simple stuff. But it would be interesting to study such if it existed.
Better debugging: the communication between the app language and the GUI could be monitored and logged to trouble-shoot.
Better GUI scripting for similar reason to debugging "above".
Higher usage means bugs get fixed earlier than per-language GUI's because there are more users.
Smaller install files because the GUI engine/library doesn't have to included with app or language.
May facilitate machine partitioning such that the GUI engine may be on one machine and the app on another.
PowerOfPlainText - the protocol or GUI language would be human-readable

ProgrammingLanguageNeutralGui talks about something similar, but doesn't really address the "service" issue.

--top

I think you're trying to reinvent DisplayPostscript.

Where's the event-handling architecture described? I agree it may be better for vector graphics interaction, but is not really a widget engine.

I didn't see any mention of event-handling architecture in the list above. However, event-handling invariably needs to invoke application code, so it probably makes sense to make that part of the infrastructure language-specific.

The above list is primarily a benefits list, not a features list.

Even X11 is a `service`. I don't believe that distinction alone is worth much. Better to word this in terms of an architectural pattern, e.g. browsers provide the users more control over what is displayed.

I agree, but X-Windows has latency problems over HTTP because the server micro-manages too many activities. (If they've fixed it since, I haven't heard.)

NovemberEleven