abstractui

Levels

 [GTK / Qt / ncurses / Win32 / FastCGI for HTML / ... ]  \
                         |                                \
                   [ UI Level ]------+                     \
                         |           |                      \
                         |       [ Macro Level ]             }
                         |           |                       } Client side
                  [ Glue Level ]-----+                      /
                         |                                 /
                  [ Comms Level ]                         /
                         |                               /
                         .
                         . <==   transport
                         .
                         |                                 \
                  [ Comms Level ]                           } Server side
                         |                                  }
                       [ ? ]                               /

UI Level

Considers UI elements. Might consider a tree something like

Application => [has metadata]
 |- Form *
     |- Region * => for layout purposes
         |- Control *
             |- Event *
             |   ==> send
             |- Method *
             |   <=> call/return
             |   <== call/ignore
             |- Property *
                 <== update
                 <=> query

Not all interface models would support all events/properties

Criticality - consider want vs. need

"CSS" style override; per-app per-interface hints. Beware of O(n*m) problem

Events are subscribed, not broadcasted

Event subscriptions might include parameters for filtering

This probably needs a lot of rethinking - how to make it sufficiently generic not to care about GTK / Qt / ... text ... speech-based interface? Menus..? More abstract things...

Macroing Level

Don't always want full network roundtrips for every UI operation

React to UI events; transform, reflect to properties/methods, throw higher-level events down to application

How powerful? Too little and it isn't useful. Too much and we hit the "JavaScript" problem - security, etc...

Language - open choice. Many scripting languages, maybe none suitable. Something custom?

Might not even be Turing complete. while(1) { }. Consider special classes of useful operation, rather than general purpose.

"Glue" Layer

(needs a better name)

Glue layer exists largely to tie up UI elements and application concepts.

A sufficiently powerful glue layer should be able to imply UI elements. I.e. not have to hand-generate a UI layout

Consider example in an IRC client:

1. IRC event on wire: :Bob!bob@bob.com PRIVMSG #test :Hello
2. Application level event: event=PRIVMSG user=Bob channel=#test message=Hello
3. Glue layer converts this into a UI update call: Append the text <Bob> Hello to the text box at 0x12345678

Considerations: Does glue layer know about specific UI type? Can it talk in specific e.g. GTK terms?

Comms Layer

UI talking to application on server. Try to talk to glue; i.e. in terms of the abstract application, not the concrete UI

Handles lots of issues:

• Addressing - Where is the application (server) hosted?
• User management / authentication
• Session persistence - think screen
• Session sharing - think screen -x
• Application management - what applications exist, how do I launch them?

Considerations

Possible UI types: Web, GTK2, Qt, Win32, "ncurses"-style TUI, raw commandline, raw RPC

Interactivty styles: display, request/response, duplex by state push, duplex by polling (do we care?)

Not all UI types go with all styles - cannot push state to commandline or RPC, Web only with JavaScript/AJAX/etc...

Access to resources. Clearly UI client has local video/keyboard/mouse access. Sound? More exotic IO devices? What of access to files? Needs bidirectional server/client trust model.

Client-local caching of "expensive" static resources - layout configurations, icons and other images, sounds,...

Pre-caching optimisations - optimse for latency/bandwidth/transmitted bytes/etc...

Examples / Exclusions

Possible types of application to build (and examples of existing applications):

• terminal emulator (xterm)
• simple database CRUD (jpilot)
• rich database CRUD (mail client)
• historic scrolling text (irssi, muck client, log tailer)
• text editing (vim)

Types of application we won't consider:

• Stateless applications with no "session" (calculator)
• Applications with complex custom UI (games)
• Applications with exacting graphics layout requirements (image editors)

Grey areas - do we want to go down this route?

• Almost-arbitrary canvas (web browser)
• Document edit (OO.o writer)

Random notes

Application has "here are my demands" list; so UI knows if it has sufficient functionallity to cope