Gui Engine Goals

Goals of a potential GUI-engine standard.

HTTP-friendly - Works well with the latency patterns of HTTP
Programming language neutral - at least as much as possible (ProgrammingLanguageNeutralGui)
- One possible way to achieve such is a CLR-like language, such as GuiMachineLanguage.
Encourages (or enforces) separation between the display and the data to be displayed. The typical MVC example of an analog and digital clock view being updated from the same data should be simple.
- May be outside the scope of an "engine". See discussion.
Availability of a data-flow model (as in spreadsheets and CellsLibrary?) to minimize explicit state changes.
- This is more of a strategy than a goal. Perhaps reword it as: 'Minimize Explicit State Management (KillMutableState): '.
- Example? - were spreadsheets not mentioned?
Consistent rendering across screen resolutions/DPI. Implies a system like CairoGraphicsLibrary or DisplayPostscript.
- "Consistent" is often in the eye of the beholder
Ability to migrate displays/window across systems. An application should be able to run on a server and be displayed on a client and the display should be able to move from client to client. Ideally, the user should not need to perform any specific 'cleanup' on one client machine before accessing it from another (since it's easy to forget to do so). Even better if the display can be rendered on multiple clients at once (e.g., to enable screen/window sharing)
Self-managing "widgets". For example, text-boxes that accept user input without a round-trip to the server for each character. And, preferably input validation such as size and character filters.
Supports both coordinate/percent-based placement and "auto-flow" and/or nested type positioning.
- It's possible such an engine could leave relative positioning up to higher-level and/or server-side tool-kits, although this could lead to slower re-size response time. But it could compensate by having good memory of user-specific preferences.
Free. Open. FreeAsInBeer. FreeSoftware. Initial implementation may be commercial, but ability of community to create a high quality free open-source implementation is ideally not hindered by patents and proprietary aspects. Neither the server nor the browser are restricted.
Abstraction. Ability to define display templates, then apply them repeatedly. Abstraction may be provided in-document, but even better if can be represented as cacheable, fetchable references to remote URIs.
Extensible Widget Set. New widgets can also be defined, complete with input, output, and display characteristics, exposed properties for manipulation, with defaults. This may require having more 'primitive' access than simple composition and abstraction from other full widgets. Something like SVG may work as a basis. It is guaranteed that no matter what the original definer adds, something will be missing. Allowing an extensible widget set can help recover from this... and, indeed, one might be able to define the original widgets using the same mechanism.
Initial Composition. From the service application provider's perspective, applications are defined by composing smaller applications, and the result of doing so can further be composed by the same, uniform mechanism.
Analysis and Accessibility. The 'document' or 'application' is accessible to analysis such that it can heuristically made accessible to the blind, or people with small mobile screens, or people who read and speak different languages, etc. without requiring the users beg the application service provider for pittance.
Stylization & Secondary Composition. The ability for users to shape, link, and embed applications rather than be subject to the whims and stylistic ventures of the service application providers. The ability, also, to achieve this through other applications provided across the network (e.g. so a user could develop a portal to other applications, and necessary for a 'web-top' desktop that follows users from kiosk to kiosk).
Live / Real Time. At both the document definition and the browser, it is easy to hook 'live' data sources to the document or application, such that the application user sees a continuously updated 'view' of the service. The updates achieve low latency without horrendous networking costs - which will likely involve designing PublishSubscribeModel directly into the associated network protocol.
Secrecy-Secure. People can't hack the connection between server and application and steal any sensitive data or listen to any sensitive conversations, and also can't hack-the-browser in the event the user is utilizing public Internet services (net-cafe and such). For the most part, this means securing the network connection and having a clean design. Even better if service-provider also can be assured that secrecy protocols are not violated: may require associating trust certs with browsers/platforms and such in order to ensure a service doesn't provide sensitive data to a platform or kiosk that isn't authorized for it. Ideally Graceful Degradation in the face of secrecy protections.
Capability-Secure. Avoid need for passwords wherever possible. This requires some discipline for identifying application instances... in particular, identifiers for active services and applications cannot be forgeable and cannot be obtained outside of a validated secure network connection. In practice, this means identifiers carry both a random string of about 160 bits and a hash of a public key for the hosting server, and that the protocol is modified to validate the server before sharing the random string (not very challenging, but only EeLanguage does this by default right now). Users that require significant security can simply carry around a smart-card with the initial capabilities they need; others can simply 'bookmark' active applications, possibly in another shared application.
Zoomable. Two aspects. First, the processing and network cost to keep an application active is a function of its screen real-estate and current level of user interaction with the application. In particular, it is NOT a function of the number of open applications. Space cost, OTOH, may be a function of applications. Second, the display elements must be defined in a zoomable language... e.g. favoring SVG over raster images. Raster images might still be supported, of course, but the first-class support should be given to the scalable images.
Server-Scalable. The processing and network cost to maintain an application is a function of its activity.
Delay and Disruption Tolerant (Robust + Resilient): Useful work, such as reading documents, performing edits-to-be-processed-later, and reviewing the most recent available data across application pages, may still continue during the disruption. When the network recovers, connections will be established, updates distributed appropriately, and no undefined behaviors will occur. (By extension, this includes tolerance to persistence, and greatly helps with zoomability.) This is aided by avoiding 'events' where feasible, and instead favoring a shared-space model (e.g. something like a TupleSpace, not necessarily shared state). It also means careful attention to user-input, and is helped a lot (in terms of the ability to continue doing useful work) by the ability to mobilize some code to be near the user. If plugins and scripting-languages are used, delay and disruption tolerance must be extended through them as well.
Graceful Degradation: In the face of heavy network traffic or a denial-of-service attack, services degrade in such an order so as to continue providing the most value for the least network effort. E.g. pretty pictures for the background go quickly, and video downgrades. This likely requires the ability for the programmer of the application or document definition to put some 'importance' rankings on different data and on user input capabilities, probably with reasonable defaults for fallback. Requires that this capability extends to all scripts and plugins, if any are needed. Resilience here, too, such that when the traffic is available again, it gracefully upgrades.
Robust against programmer error: doesn't crash, doesn't enter undefined states, fails safe and secure, doesn't enter infinite processing loops that consume tons of CPU resources, doesn't enter infinite network loops.
Persistence Friendly: Browser may persist inactive pages and restore them easily.
Caching Friendly: Significant portions of application components, such as widget-sets and abstractions, can be cached, pre-processed or pre-compiled, and shared between users, between application instances, and even between applications.
Animated: Supports declaration of temporal display events, to be interpolated by the browser (as opposed to requiring repeated update events from the server). E.g. one might declare a 2-second transition from transparent to opaque while sliding a frame in from the side.
Audio & Video: Support for sound and video in a common manner, ideally declared relative to temporal events similar to animation. Ability to attach sounds to events, like pressing buttons, without waiting for feedback from a potentially high-latency server. A common set of codecs for these, similar to how HTML has default support for JPEG, plus support for more generic input, similar to how HTML has support for SVG.
Undo-friendly. Easy to write services and GUIs to these services that have 'undo' capability, that make the user aware of what can and cannot be undone, and makes 'undo' easy to achieve in a consistent way. Must extend through any scripting languages and plugins to whatever degree those must be utilized to achieve common applications.
Multi-User Friendly. Users can not only share reference to an application, but they may have different active views of the application (i.e. one may have it minimized while another has it fully active), and they can readily identify where one another utilize the application (e.g. words added to a textbox might initially appear in another color before fading to a common one, possibly shading for apparent areas of user-focus) in order to prevent/reduce multiple users from conflicting in their labors. Further, some sort of default multi-headed merge for edit conflicts is provided for shared applications, e.g. as a common easy-to-utilize widget.
Interpretation Friendly: Can readily be translated into other display formats. Doesn't require compiling down to bytecode of any sort. Doesn't require a specific programming language runtime for simple displays (ignoring potential need for plugins).
Pretty / Eye Candy: Can readily take advantage of graphics card and 2D acceleration by browsers that wish to go this extra mile. Perhaps the ability for these browsers to take advantage of higher 'level of detail' that might otherwise be degraded in an interpretation-only environment.
Data Driven: No history of 'events' is needed by the server or the client; wholly driven by 'current state'. The cost to maintain an application is proportional to its complexity and available data, not its lifetime (except insofar as its lifetime affects its available data). This is useful for migration of client from machine to machine. A case to beware of, though, is client-side scripts and plugins. Some restrictions on the design for client-side code and plugins is necessary to avoid keeping any local data except of the sort that can simply be regenerated by interaction with the server.
Anti-cheating, DRM friendly: GUI and App Servers resist copyright and license violations for the usage of restricted shared media. Similar technologies can be used to prevent cheating in applications that represent video-games. Servers have access to a trusted computing base on the client machines (i.e. unforgeable dongles, smart-cards, or chips that can answer challenges and may have certs assigned to them). Ability also for servers to challenge one another, and for clients to challenge servers.
Minimal or Lightweight Client: possible to implement a client where most or all logic processing for user-inputs and 'document-object' updates occurs server-side in a manner that is consistent across servers. This does not preclude the possibility that a bells-and-whistles client could cache logic and display components locally in order to reduce apparent latencies. The latter would be an 'optimized' version; i.e. insofar as possible, the semantics should be identical.
- This goal is usefully compatible with many other goals, such as the ability to migrate an application from one client machine to another, disruption tolerance with well-defined recovery, and the ability to support multiple simultaneous views and users for an application.
- This goal is not incompatible with animations and transitions, but may require some care in the integration (i.e. declarative animations).

Please only include brief summaries in this list. Put discussion below.

Discussion:

How do you measure 'HTTP-friendly'? Why is 'HTTP-friendly' a goal? Are you aiming for 'HTTP-compatibility' (the ability to run the GUI atop HTTP protocol in particular), or (if HTTP-protocol itself is just an example) should you really break it down into goals regarding bandwidth and latency between 'display and server providing data-to-be-displayed'?
- X-Windows is an example of something that is "compatible" with HTTP, but not HTTP-friendly because it is not designed with fairly long latency in mind. Ideally the engine should be able to work with a wide variety of latency and bandwidth characteristics. In the shorter term, HTTP-friendly is the main goal because that is what the current infrastructure supports.
- The issue I have with your 'definition' is that you seem to be equating latency patterns with HTTP-friendliness. To me, HTTP-friendly suggests also: (a) compatibility with the HTTP security model. (b) compatibility with the HTTP handshake protocol. (c) compatibility with the HTTP 'no long-term connections' design. (d) compatibility with HTTP cookies model (that is part of HTTP, not HTML, just so you know). (e) compatibility and design around the basic six-message set (GET, PUT, POST, DELETE, UPDATE, HEAD, plus a few peripherals) and their expected safety and idempotence properties. So, to me, when you say "HTTP-friendly - works well with latency patterns of HTTP', I think: "either the left side is poorly named or the right side is grossly underspecified".
How do you measure 'Programming Language Neutral'? Seriously.

I suggest that, unless contributors wish to produce another PipeDream page like KillerUserInterface, every goal should (as part of its definition) be objectively measurable (put a number on it) or qualifiable (e.g. via proof, rubric). Further, we should explicitly separate 'Goal definitions' (which name and define goals) from 'Goal sets' (a weighted set of compatible goals that some contributor thinks represents 'GUI done right'). After all, there may be incompatible goals among the definitions.

I also find the title a bit painful. 'GUI engine' in literature, colloquially, and on the Internet, pretty much means 'display framework and widgets set', like Motif or GLO or various Desktop Environments. It usually excludes anything further behind the scenes.

What alternative would you suggest?

GuiSystemGoals?. Has a more end-to-end feel (server, app-developer, browser, display-engine, and user) whereas 'GUI engine' rarely refers to more than the display-engine.

I'm not particularly fond of DRM, but I understand the motivations of those who are. The technology is very good for other privacy management, and for ensuring need-to-know information only reaches those who need-to-know.

Re: "Encourages (or enforces) separation between the display and the data to be displayed. The typical MVC example of an analog and digital clock view being updated from the same data should be simple."

That is an IDE and/or application development pattern, not necessarily a concern of the "GUI engine". Clock shape and style is a domain issue.

I interpreted it as basically being a statement of ImmediateModeGui or data-driven: the data is managed separately from the display thereof. "Clock shape and style", to me, are presentation issues, independent of data (up to precision), and potentially independent of application. TopMind may need to clarify; the above description seems to be ambiguous.