[Prev][Next][Index][Thread]
RELNOTES.HTML
http://www.x.org/consortium/R6.3doc/relnotes/RELNOTES.html
just discovered the X consortium has released X11R6.3 a month ago. now
looking for XFree's next release info
3. What Is New in Release 6.3
This section describes changes in the X Consortium distribution since
Release 6.1.
All libraries, protocols, and servers are compatible with Release 6 and
Release 6.1. That is, R6 and R6.1 clients and applications will work
with R6.3
libraries and servers. Most R6.3 clients will work with R6.1 and R6
libraries except those that use the new interfaces in libICE, libXext,
and libXp.
The major new functionality in R6.3 is support for World Wide Web
integration, protection of data from ``untrusted'' client connections, a
bandwidth- and
latency-optimized protocol for using X across the Internet, a print
protocol following the Xlib API, and support for vertical text writing
and user-defined
characters in the Xlib implementation.
3.1. OS Support
The following platformshave a newer operating system version supported:
System R6.1 R6.3
AIX 4.1.4 4.2
Digital Unix 3.2C 4.0A
HP-UX 10.01
IRIX 5.3 6.2
Solaris 2.4 2.5
UnixWare 2.02
We also built on the following platforms, however full support is not
guaranteed:
System R6.1 R6.3
FreeBSD 2.1.0 2.1.6
Linux 1.2.13 2.0
SCO Open Server 5.0
SunOS 4.1.3 4.1.4
Windows NT 3.5 4.0
3.2. New Standards
The following are new X Consortium standards in Release 6.3. Each is
described in its own section below.
Low Bandwidth X Extension
RX: X Remote Execution MIME type
Security Extension
Application Group Extension
Print Extension
Proxy Management Protocol
3.3. Low Bandwidth X Extension
The Low Bandwidth X extension (LBX) defines several compression and
local caching techniques to improve performance on wide area networksand
also on slower-speed connections. These reduce the amount of protocol
data transported over the network and reduce the number of
client-to-server
roundtrips required for common application startup operations.
LBX was referred to as X.fast in some materials but we elected to not go
through the implementation and change all the names. To avoid any
confusion
with an external name different from the internal name in the
implementation, we elected to drop the ``X.fast'' moniker.
LBX is implemented in two pieces; an X server extension and a proxy
application. The X server extension provides the new optimized protocol.
The
proxy application, lbxproxy, translates a normal client X protocol
stream into an LBX stream. This permits any existing applicationto gain
the benefit of
the optimized protocol with no changes. Theproxy is especially useful
when multiple applications are running on thesame local area network
separated
from the X server by a slower network.In this case the full benefit of
the local cache is shared by each application using the same proxy
process.
The specification for LBX is in xc/doc/specs/Xext/lbx.mif (FrameMaker
interchange source) and xc/doc/hardcopy/Xext/lbx.PS.Z
(compressedPostScript).
3.4. RX: X Remote eXecution
The remote execution (RX) service specifies a MIME format for invoking
applications remotely, for example via a World Wide Web browser. ThisRX
format specifies a syntax for listing network services required bythe
application, for example an X display server. The requesting Web browser
must
identify specific instances of the services in the request to invoke the
application.
The distribution contains a helper program (xrx) and a Netscape
Navigator plug-in (libxrx) that demonstrate this protocol. The plug-in
requires Navigator
3.0.
We have only been able to test the plug-in on HP-UX, IRIX, Digital
Unix,and Solaris2. Netscape Navigator binaries for other (UNIX)
platforms are either
not available at all or were not available in time to be included in the
testing for this release.
The specification for the RX mime type is in xc/doc/specs/RX/RX.mif
(FrameMaker interchange source) and
xc/doc/hardcopy/RX/RX.PS.Z(compressed
PostScript).
The following section describes the procedure to set up your environment
and try the examples provided in this distribution.
3.4.1. Preparing Your Web Server
In order to demonstrate the RX helper program and the RX Netscape
plug-in you need to have access to an HTTP server to install ``common
gatewayinterface'' (CGI) scripts. While CGI programs can be written in
any compiled or interpreted language, the sample CGI programs in the
distribution
are written in perl.
If you don't currently have a web server the NCSA server is a good one
to try. Binaries for various systems are available at:
http://hoohoo.ncsa.uiuc.edu/docs/setup/PreExec.html
If you don't have perl you can get the source code from:
ftp://prep.ai.mit.edu/pub/gnu/perl-4.036.tar.gz
You need to install the HTML, RX, and CGI sample files into your
server's HTML and CGI directories. The process can be partially
automated by adding
the following definitions to your site.def or host.def file:
WebServer defines the hostname and port of your web server, for example
#define WebServer www.myorg.org:8001
HtmlDir defines the path at which HTML and RX documents are installed,
for example
#define HtmlDir /usr/local/etc/httpd/htdocs
CgiBinDir defines the path at which CGI programs are installed, for
example
#define CgiBinDir /usr/local/etc/httpd/cgi-bin
ProxyManager defines the transport scheme, hostname, and port for CGI
programs to contact the Proxy Manager. See the proxymngr man pages for
further details. Typically the proxy manager host will be the same as
your web server, for example:
#define ProxyManager tcp/www.myorg.org:6500
Then make the Makefiles and build the directories with the
followingcommand sequence:
cd xc/programs/xrx/htdocs
xmkmf ../../.. programs/xrx/htdocs
make
make install
cd ../cgi-bin
xmkmf ../../.. programs/xrx/cgi-bin
make
make install
These directories are not automatically built or installed by the
toplevel Makefile because they install outside the ProjectRoot.
You also need to configure your web server so that files with the
extension name ``rx'' are of the MIME type ``application/x-rx''. See
your HTTP server's
configuration documentation for the right procedure to do so.
3.4.2. The RX Helper Program
The helper program, xrx, may be used with any Web browser to interpret
the new RX document type.
The RX helper program is installed in <ProjectRoot>/bin
(e.g./usr/X11R6.3/bin/). You will need to configure your web browser to
use it for RX documents
by adding a line to your $HOME/.mailcap:
application/x-rx; /X11/bin/xrx %s
You may need to refer to your web browser's documentation for exact
instructions on configuring helper applications.
The helper program is activated by your browser as soon as you retrieve
any document of the MIME type application/x-rx. All you need to do is to
point
your browser at the URL: http://your.web.server/xload.rx
The application (i.e. xload) should appear on your DISPLAY as a
newtop-level client. The client will be running on your web server host
and connected
to your X server. If your X server supports the SECURITY extension the
client will be running as an untrusted client.
3.4.3. The RX Netscape Navigator Plug-in
The Navigator plug-in supports all the functions of xrx and in addition
uses the new XC-APPGROUP extension, if your X server provides it, to
cause the
remotely launched application to be embedded within the browser page
from which it was launched.
The HTML page links to an RX document via the EMBED tag, a Netscape
extension to HTML. The RX document provides the plug-in with the list of
services the application wants to use. Based on this information,the
plug-in sets the various requested services, including creating
authorization keys,
and passes the relevant data to the application through an HTTP GET
request of the associated CGI script. The Webserver then executes the
CGI script
to start the application.
To be able to use the RX plug-in you need Netscape Navigator 3.0.
Binaries for various systems can be found at:
http://home.netscape.com/comprod/mirror/client_download.html
To complete the installation of the Netscape plug-in, find the file
named libxrx.so.6.3 or libxrx.sl.6.3 (or similar, depending on your
platform) in
<ProjectRoot>/lib (e.g. /usr/X11R6.3/lib) and copy it to either
/usr/local/lib/netscape/plugins or $HOME/.netscape/plugins. Do not
install the symlinks
libxrx.so or libxrx.sl; they may confuse Netscape.
You should remove or comment out the line you may have previously added
in your mailcap file to use the RX helper program, otherwise the plug-in
will
not be enabled. (The usual comment character for mailcap is ``#''.)
If you are already running Netscape Navigator, you need to exit and
restart it after copying the plug-in library so the new plug-in will be
found. Once this
is done you can check that Navigator has successfully loaded the plug-in
by checking the ``About Plug-ins'' page from the Helpmenu. This should
show
something like:
RX Plug-in
File name: /usr/guest/netscape/plugins/libxrx.sl.6.3
X Remote Activation Plug-in
Mime Type Description Suffixes Enabled
application/x-rx X Remote Activation Plug-in xrx Yes
The plug-in will be activated by Netscape Navigator as soon as you
retrieve any document of the MIME type application/x-rx. Several samples
are
included in the distribution. The most basic one is xload. All you need
to do is point your browser at the page:
http://your.web.server/xload.html
If something goes wrong check on the all the previous steps listed above
and try again. Once xload is working you can try some of the other
examples in
the distribution such as bitmap.html or dtcm.html.
3.4.4. Trying Embedding With an Old X Server
The Netscape Navigator plug-in, libxrx, will work with an X server that
does not contain the application group or security extensions. The
application will
be started as a separate top-level client.
If you wish to try out the embedding facilities without replacing your
desktop X server, you may use the Xnest server.
A typical Xnest session would look like the following:
% Xnest :11% xterm -display :11
These two commands start a ``nested'' server and a terminal emulator
within that server. Your favorite window manager and Netscape Navigator
can
now be executed from the nested xterm window. You may wish to first
disable access control in the nested server by running ``xhost +'' inthe
nested
xterm.
3.4.5. Setting Up Your Own Applications To Run Over The Web
Based on the examples provided in the distribution it should be easy to
set up your web server to run your own applications. Every application
requires 3
additional files to identify it to Web browsers:
myapp.html: An HTML page to present the application embedded
myapp.rx: The RX document describing the application
myapp.pl: The CGI script to start the application
Note that the separate ``.rx'' file could be omitted by implementing the
CGI script such that if it is invoked without a QUERY_STRING it will
return the RX
content. We decided not to do so in the distributed examples for purpose
of clarity.
The xload demo provides a good starting point. Simply make a copy of
each of the files xload.rx, xload.html, and xload.pl. Then look inside
them for
every instance of ``xload'' and change it to whatever is appropriate for
your application.
You will not be able to run the dtcm demo unless you have dtcm (a CDE
component) installed on your web server host. This example shows how a
CGI
script would look when an X Print server is requested. The script
dtcm.pl is, for that reason, slightly more complicated than other
examples.
3.5. Security Extension
The SECURITY extension contains new protocol needed to provide enhanced
X server security. This extension adds to the X protocol the concepts of
``trusted'' and ``untrusted'' clients. The trust status of a client is
determined by the authorization used at connection setup. All clients
using host-based
authorization are considered ``trusted''. Clients using other
authorization protocols may be either trusted or untrusted depending on
the data included in
the connection authorization phase.
The requests in the security extension permit a trusted client to create
multiple authorization entries for a single authorization protocol. Each
entry is
tagged with the trust status to be associated with any client presenting
that authorization.
When a connection identifying an ``untrusted'' client is accepted, the
client is restricted from performing certain operations that would steal
or modify data
that is held by the server for trusted clients. An untrusted client
performing a disallowed operation will receive protocol errors. Such a
client may be
written to catch these errors and continue operation.
When a client is untrusted, the server will also limit the extensions
that are available to the client. Each X protocol extension is
responsible for defining
what operations are permitted to untrusted clients; by default, the
entire extension is hidden.
The specification for the SECURITY extension is in
xc/doc/specs/Xext/security.tex (LaTeX source) and
xc/doc/hardcopy/Xext/security.PS.Z (compressed
PostScript).
3.5.1. Untrusted Application Behavior
Most applications work normally when run as untrusted clients, but since
the security extension changes the semantics of certain parts of the
Xprotocol, it
is no surprise that some clients behave differently when untrusted. We
note the following significant behavior changes, separated into two
categories:
changes that we expect could disappear or mutate if the implementation
were improved in a future release, and changes we expect are permanent,
legitimate defenses against data loss or leakage.
3.5.1.1. Behaviors That Are Implementation-Dependent
The following behaviors when running the respective applications as
untrusted are not mandated by the security design but are side effects
of limitations
in the current implementation.
oclock is square because the SHAPE extension hasn't been marked secure
yet. Similarly, Xaw applications that use oval buttons will have
rectangular
buttons instead.
Any application that depends on an extension other than XC-MISC, LBX,
orBIG-REQUESTS will have different behavior, as no other extensions are
currently marked secure. The core clients affected are xieperf and all
the xkb utilities.
emacs exits with a Window error when trying to use the
QueryPointerrequest on the root window when you click in a buffer.
FrameMaker, and xwd -root both exit with a Window error when trying to
use the GetWindowAttributes request on a window manager frame window.
All the remaining changes are involved in some way with window
properties. Some of these behaviors can be modified with changes to the
SecurityPolicy file; see the Xserver man page.
Several clients exit with a Window error when trying to use the
DeleteProperty request on various properties on the root window. These
include xcmsdb
-remove, xprop -root -remove, and xstdcmap -delete.
xprop exits with an Atom error when attempting to access protected
properties.
The following two changes require, in addition, a ``trusted selection
intermediary'' to provide selection transfer from untrusted to trusted
clients (and
vice-versa). R6.3 does not include such a trusted intermediary.
xterm exits with an Atom error when it tries to store the property value
during a selection transfer (paste) to a trusted selection requester.
The ``copy 0 to PRIMARY'' button of xcutsel does not work.
Selection transfer from untrusted clients to trusted clients fails when
the untrusted client attempts to use SendEvent to generate the
SelectionNotify event
for the requester. Most requesters will treat this as a transfer timeout
and continue. Xt-based applications will create an additional Atom each
time such a
transfer is attempted.
3.5.1.2. Behaviors That Are Not Likely To Change
The following behaviors represent actions performed by the applications
that are disallowed by design.
editres will fail when pointed at a trusted client when it tries to read
window properties on a window owned by that client.
Xnest exits on startup with an Access error as it tries to use the
ChangeKeyboardControl request.
The new generate option to xauth fails because untrusted applications
are not allowed to create additional authorizations.
xhost cannot be used to modify the host access list.
xmag gets an unending stream of Drawable errors as it tries to use
thePolyRectangle request on the root window. If you click to select
alocation to
magnify, xmag gets a Drawable error as it tries to use the GetImage
request on the root window. xmag could be modified to exit gracefully
under these
conditions.
netscape exits on startup with a Drawable error when trying to use the
GetImage request on the root window.
xmodmap exits with an Access error when trying to use the
ChangeKeyboardMapping request.
xset with the b, c, led, or r options exits with an Access error when
trying to use the ChangeKeyboardControl request. With the bc option, it
can't find the
MIT-SUNDRY-NONSTANDARD extension and exits gracefully.
xsetroot exits with a Window error when trying to use the
ChangeWindowAttributes request on the root window.
3.6. Application Group Extension
The application group extension (XC-APPGROUP) provides new protocol to
implement Application Groups (``AppGroups''). The AppGroup facility
allows other clients to share the SubstructureRedirect mechanism with
the window manager. This allows another client called the ``application
group
leader'', such as a web browser, to intercept a MapRequest made by a
third application and reparent its window into the web browser before
the window
manager takes control. The AppGroup leader may also limit the screens
and visuals available to the applications in the group.
Users who have an XC-APPGROUP enhanced X server and an RX plug-in for
their Netscape Navigator web browser can run programs remotely over
the web and have the output appear as part of the presentation in their
web browser.
The only way for an application to become a member of an AppGroup is by
using an authorization generated using the new security extension.
Whenever an application connects to the server, the authorization that
it used to connect is tested to see if it belongs to an AppGroup. This
means that
the Authorization data must be transmitted to the remote host where the
application will be run. In the case of RX, HTTP is used to send the
Authorization. Sites who have concerns about sending unencrypted
authorization data such as MIT-MAGIC-COOKIE-1 via HTTP should configure
their
web servers and web browsers to use SHTTP or SSL.
The specification for the XC-APPGROUP extension is in
xc/doc/specs/Xext/AppGroup.mif (FrameMaker interchange source) and
xc/doc/hardcopy/Xext/AppGroup.PS.Z (compressed PostScript).
3.7. Print Extension
The print extension supports output to hardcopy devices using the core
Xdrawing requests. The print extension adds requests for job and
pagecontrol
and defines how specific printer attributes are communicatedbetween the
server and printing clients. Printer attribute specifications are
modeled after the
ISO 10175 specification.
An X client that wants to produce hardcopy output will typically open
asecond connection to an X print server, produce a print job, and
thenclose the print
server connection. The print server may be the sameprocess as the
display server (the term ``video server'' is sometimesused) although the
implementation provided in R6.3 does not completelysupport video and
print servers in the same binary.
The specification for the print extension is
inxc/doc/specs/XPRINT/xp_proto.mif (FrameMaker interchange source)
andxc/doc/hardcopy/XPRINT/xp_proto.PS.Z (compressed PostScript).
Thelibrary API specification is in
xc/doc/specs/XPRINT/xp_library.mif(FrameMaker interchange source)
andxc/doc/hardcopy/XPRINT/xp_library.PS.Z (compressed PostScript).
3.7.1. Running an X Print Server
The print server is simply an X server with the print extension and
special DDX implementations. The X Print Server is started like any
otherX server.
Here is a sample command line for use with a typical configuration:
% Xprt :1 -ac
The options used in the example are:
:1 On a host that is running a video display server you will need to
specify a different display from the default.
-ac Disable access control, since no simple mechanism for sharing keys
is provided.
The X print server supports the following additional options:
-XpFile Points to the directory containing the print server
configuration files.
XPCONFIGDIREnvironment variable specifying alternative location of the
print server configuration files.
The print server, Xprt, is built only if the config option XprtServer
isYES. Four printer DDXen are provided, each with a separate
configoption to control
whether or not it will be included: XpRasterDDX,XpColorPclDDX,
XpMonoPclDDX, XpPostScriptDDX; see xc/config/cf/README.XprtServer
defaults to
the value of BuildServer (i.e. Xprt will be built by default on all
platforms that build a full X server). XpRasterDDXand XpMonoPclDDX
default to NO.
XpColorPclDDX and XpPostScriptDDXdefault to YES.
The print server is configured through a directory of configurationfiles
that define printer model types and instances of printer models.An
example
configuration tree is provided inxc/programs/Xserver/XpConfig/. See also
xc/doc/specs/Xserver/Xprt.mif(FrameMaker interchange source) and
xc/doc/hardcopy/Xserver/Xprt.PS.Z(compressed PostScript) for further
instructions on configuring Xprt.
3.7.2. Specifying The Print Server To A Client
By convention, clients locate the print server using the
environmentvariable XPRINTER. The syntax of XPRINTER is an augmented
DISPLAY; i.e.
printerName@host:display
where ``printerName'' is one of the printer instances listed in theprint
server configuration files. The use of XPRINTER and its syntax isan
application
convention only; there is nothing in the suppliedlibraries that uses (or
parses) this environment variable.
3.8. Proxy Management Protocol
The Proxy Management Protocol is an ICE based protocol that provides
away for application servers to easily locate proxy services such as
theLBX
proxy and the X firewall proxy.
Typically, a service called a ``proxy manager'' is responsible
forresolving requests for proxy services, starting new proxies
whenappropriate, and
keeping track of all of the available proxy services. The proxy manager
strives to reuse existing proxy processes wheneverpossible.
The Proxy Management Protocol is described in xc/doc/specs/PM/PM_spec.
3.9. Configuration
As in R6.1, the top-level Makefile is no longer over-ridden by the
firstbuild. Instead a new file xmakefile is created. Thus is it not
necessary totake any
additional steps to reset the builds.
The file xc/config/cf/README provides more guidance on how to write
anImakefile, including a list of variables that may be set in
anImakefile. This file is
strongly recommended reading for Imakefileauthors.
The LaTeX text processor is supported as of R6.1. If you have LaTeX
onyour system, turn on HasLatex to have the MakeLatexDoc rule use it.
Also since R6.1, with System V Release 4 (SVR4) compilers we now use the
-Xa (ANSI C with native extensions) compiler flag rather than -Xc
(limitenvironment to that specified in the standard). This provides
access tothe full richness of the platform. Unfortunately, it also
defines thepreprocessor
symbol __STDC__ to 0, instead of 1 as specified by thestandard.
Therefore we use "#ifdef __STDC__" in our sources rather than"#if
__STDC__". On
HP-UX systems we use the -Ae compiler option insteadof -Aa, also to
access the full environment offered by the platform.
As in R6.1, the imake variables InstallXdmConfig, InstallXinitConfig,and
InstallAppDefFiles suppress\tab overwriting existing files; if the
filesdidn't
previously exist, the files are always installed. This interpretation
makes bootstrapping a new system easier than in R6 and earlierreleases.
A new configuration build option, GzipFontCompression, has been added
touse gzip rather than compress for font compression. It defaults to NO.
The build creates a new directory xc/exports into which the headerfiles,
libraries, and certain build utility binaries are symlinked. This
greatly simplifies
Imakefile construction and supports multipledevelopment projects (such
as X, Motif, and CDE) on a single system.
Imake rules and template files for building Motif and CDE were
contributed by the OSF CDE/Motif project and are included in R6.3.
-------------------------------------------------------------
Ira Abramov <ira@scso.com> Scalable Solutions
SITE Web Presence ("webspace for rent") http://www.site.co.il
Beeper 91826 at 058-212121 FAX (972)2-430-471
POBox 3600, Jerusalem 91035, Israel Tel (972)2-6426822
http://www.scso.com/~ira Check out: http://www.linux.org.il