X over the Web.

Daniel Dardailler - X Consortium, Inc.
One Memorial Drive - CAMBRIDGE, MA 02142-1301 - U.S.A.
Phone: (617) 374 1000 x133 - Fax: (617) 374 1025

 daniel@x.org - http://www.x.org/people/daniel

Keywords:: X Window System, Embedding, Remote Execution, RX Document type.

Abstract

This document presents some ideas on how to architect a system that would allow remote programs (such as X clients) to be activated and render themselves directly onto Web browser screens, thereby offering Web information providers a much better and finer control over the exact presentation of their documents, or with the ability to demonstrate real applications or products thru the Web.

For a full-length paper discussing all aspects of the problem: http://www.x.org/people/daniel/xweb.html

New data on the Web

We introduce a new document type, the RX document, to give Web browser system enough information to activate the remote program, with indication on which UI protocol to choose, embedding support, size hints, etc.
In HTML, RX document pointers can be found in the same context as any type of image files (gif, xbm, etc), namely ANCHOR (toplevel mode) or IMG (inline, or embedding mode).

The first line of an RX document describes the server side activation script url (a CGI script probably):ACTION. It's followed by a list of Display Protocol specific data: UI_PROTOCOL (could be x11, windd, etc), LOCATION (with execution protocol information), GEOM_HINT, EMBEDDABLE, LOGO (alternate url to use).

Example of an RX document supporting two different UI protocols:
ACTION http://www.x.org/actions/webdemo20 UI_PROTOCOL x11 LOCATION spcd file://soleil.x.org/xprograms/webdemo20 GEOM_HINTS 500x400 EMBEDDABLE yes LOGO file://www.x.org/icons/xwebdemo20.xbm UI_PROTOCOL windd LOCATION local file://www.x.org/os2programs/webdemo20 GEOM_HINTS 300x200 EMBEDDABLE no LOGO file://www.x.org/icons/webdemos2.gif

The following figure presents the general architecture involving RX documents:

The sequence of actions in the above picture is initiated by a browser (Mosaic, netscape) finding an RX reference in an HTML document.

the browser GET the rx document using a regular HTTP query.
the httpd daemon serves this RX document, as Mime Content-type application/rx.
the browser spawns an external RX agent viewer, passing it the rx document and other information such as display id, window id for embedding.
the rx agent asks the http server to process the action script (with the rx data).
the http server activates the CGI script, as indicated by the rx agent.
the script, using all the information necessary in the RX document (ui protocol, exec protocol, etc), activates the remote client.
the remote client connects back to the browser Display/Window, and does its rendering.

Embedding

The non-embedding case of handling RX documents can be implemented without any change in the browser or the http server code.

on the httpd side, add an entry in the server extension map file that binds ".rx" suffixes to the MIME Content-Type "application/rx".
on the browser side, simply add an entry into the .mailcap file ("application/rx; rx %s") to bind the RX type to an the Rx agent.

For the embedding case, there is a clear need for supporting embedding in a Web browser beyond the current case of remote execution. It just hasn't taken real shape yet.

If that mechanism was in place, then "rx" would just becomes an instance of an external-for-embedding viewer handling remote execution rather than MPEG or something else.

The discussions I have had so far on the Web mailing list show an interest in extending the mailcap syntax (rfc1524) so that one can specify a new keyword, embed= , which would be used to pass the embedding context (Window id, session id, etc).

Other issues wrt embedding include: session management (life of the program?), using OLE/OpenDoc, using CCI.

Security

It's often the case that direct X connectivity is not allowed between two given hosts, i.e. a firewall machine disallows it. The X Security working group is currently studying a proxy X server approach, ala xscope, where the X proxy could guarantee a secure X connection from the remote X program to the browser session (where private information usually resides) without changing the browser X server. Roughly, it's about looking closely at the X Protocol and determining which requests should be blocked, what inter-client interchange can be allowed, etc.

Conclusion

Beside its specific purpose, this effort is worth pursuing because it relies on several "independent" areas to really become operational: Seamless embedding in the Web browser, Embedding in X, X security, Remote execution, and X performance over slow connection. My hope is that this effort can help making some of that happen sooner rather than later...