入り口に戻る

原文はこちら。

翻訳にあたって、オープンソースグループ・ジャパンの MIT ライセンスの訳を参考にした。

# Big Requests Extension(日本語訳)

## X Consortium Standard

### Bob Scheifler

X Consortium

X Version 11, Release 7.7

Version 2.0

Copyright © 1993, 1994 X Consortium

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE X CONSORTIUM BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

Except as contained in this notice, the name of the X Consortium shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Software without prior written authorization from the X Consortium.

X Window System is a trademark of The Open Group.

(訳)

(本ソフトウェアおよび関連する文書のファイル（以下「ソフトウェア」）の複製を取得した全ての人物に対し、以下の条件に従うことを前提に、ソフトウェアを無制限に扱うことを無償で許可する。これには、ソフトウェアの複製を使用、複製、改変、結合、公開、頒布、再許諾、および/または販売する権利、およびソフトウェアを提供する人物に同様の行為を許可する権利が含まれるが、これらに限定されない。)

(上記の著作権表示および本許諾表示を、ソフトウェアの全ての複製または実質的な部分に記載するものとする。)

(ソフトウェアは「現状有姿」で提供され、明示的であるか黙示的であるかを問わず、いかなる種類の保証も行われない。ここでいう保証には、商品性、特定目的への適合性、および権利の非侵害性に関する保証も含まれるが、これらに限定されるものではない。THE X CONSORTIUM は、契約、不法行為、またはその他の行為であるかを問わず、ソフトウェアまたはソフトウェアの使用もしくはその他に取り扱いに起因または関連して生じるいかなる請求、損害賠償、その他の責任について、一切の責任を負わない。)

(X Consortium の名称は、この表示に記載されている場合を除き、X Consortium の事前の書面による承認を得ずに、宣伝であろうとその他の形であろうと、ソフトウェアの販売を促進するもの、またはソフトウェアの使用その他の扱いを奨励するものに使用してはならない。)

(X Window System は The Open Group の商標である。)

## 第１章　概要

この拡張は、バイト長が 262140 を超えるようなプロトコル・リクエストの使用を可能にするものである。

X コア・プロトコル(本体のプロトコル)では、プロトコル・リクエストの最大長が 262140 バイトに制限されている。これは、リクエスト内の 4 バイト単位のデータの個数を表すのに 16 ビットの length フィールドを使っているためである。これによって、コア・プロトコルで大量の線や弧を結合する場合(PolyLine や PolyArc)に問題が起きる。なぜかというと、これらのリクエストを小さなリクエストに分割すると、必ず結合点のレンダリングが紊れてしまうからである。また、プロトコルの拡張に対しては一層の問題を引き起こす。例えば、3D グラフィクスのための PEX 拡張や、画像操作のための XIE 拡張(X Image Extensionのこと)などは、出力命令において長いデータのリストを送信する必要がある。

この拡張では、length フィールドを 16 ビット以上に拡張する仕組みを定める。プロトコル・リクエストの通常の 16 ビットの length フィールドの値が 0 である場合、リクエストの中のこの 16 ビットの length フィールドの直後に 32 ビットの追加フィールドが挿入され、ここに実際のデータ長(4 バイト単位)が入る。

たとえば、通常の `PolyLine` は次のように符号化される。

`PolyLine`
1 | 65 |  | opcode(命令コード)
1 |  |  | coordinate-mode
| 0 | Origin |
| 1 | Previous |
2 | 3+n |  |
4 | DRAWABLE |  | drawable
4 | GCONTEXT |  | gc
4n | LISTofPOINT |  | points

一方、拡張された length フィールドを持つ `PolyLine` は次のように符号化される。

`PolyLine`
1 | 65 |  | opcode(命令コード)
1 |  |  | coordinate-mode
| 0 | Origin |
| 1 | Previous |
2 | 0 |  | 拡張 length フィールドを持つことを表すフラグ
4 | 4+n |  | リクエストのデータ長(request length)
4 | DRAWABLE |  | drawable
4 | GCONTEXT |  | gc
4n | LISTofPOINT |  | points

拡張 length プロトコル(拡張 length フィールドを用いるプロトコル)の符号化方式は、一度有効化されれば、全てのプロトコル・リクエスト(あらゆる拡張のものを含む)で使用できる。

## 第２章　リクエスト

`BigReqEnable`

=>

maximum-request-length: CARD32

このリクエストを使用したクライアントは、拡張 length プロトコルのリクエストを使用することができるようになる。また、このリクエストは、拡張 length プロトコルのリクエストで使用できる最大のデータ長(4 バイト単位)を返す。この値は常に、接続設定情報として返ってくる最大リクエスト長よりも大きくなる。

## 第３章　イベントとエラー

この拡張では、新しいイベントとエラーは定義しない。

## 第４章　符号化

本文書は、X11 プロトコルの符号化に関する文書(X Window System Protocol の附録 B「プロトコルの符号化」 )で定められた規約を用いているため、そちらも参照してほしい。

この拡張の名前は「BIG-REQUESTS」である。

BigReqEnable
1 | Card8 | opcode(X11 の命令コード)
1 | 0 | bigreq opcode(BigReqEnable リクエストを表す拡張内命令コード)
2 | 1 | request length

=>
1 | 1 | Reply
1 |  | unused
2 | CARD16 | sequence number(通し番号)
4 | 0 | length
4 | CARD32 | maximum-request-length
20 |  | unused

## 第５章　C 言語バインディング

Xlib 本体も他の拡張も、この拡張が必要な場合、同拡張を内部で使用するのが望ましい。また、この拡張は、X クライアントに対してできる限り透過的な形で利用されるのが望ましい。たとえば、この拡張が初めて必要になる時まで同拡張の有効化を先延ばしにしていたとしたら、`XNextRequest` を使ってリクエストの通し番号を知ろうとしていたアプリケーションは、もはや正しい通し番号を得ることはできないであろう。なので、`XOpenDisplay` によってサーバがこの拡張に対応しているかを判断することにし、もし対応していれば、同関数で拡張 length プロトコルの符号化方式を有効にすることにする。

Xlib 本体の関数の中、`XDrawLines`、`XDrawArcs`、`XFillPolygon`、`XChangeProperty`、`XSetClipRectangles`、及び `XSetRegion` は、サーバが拡張 length プロトコルに対応している場合、必要な場面では、同プロトコルの符号化方式を使用することが求められる。他の Xlib 本体の関数(`XDrawPoints`、`XDrawRectangles`、`XDrawSegments`、`XFillArcs`、`XFillRectangles`、及び `XPutImage`)では、拡張 length の符号化方式の利用は認められているが必須ではない。後者の関数群の Xlib の実装においては、代わりに、データを複数の小さなリクエストに分割することにしてもよい。

拡張 length の符号化方式で使える最大リクエスト長をクライアントから知ることができるように、Xlib に次の関数を追加する。

`long XExtendedMaxRequestSize(`Display *display`)`;

display で指定されたディスプレイがこの拡張に対応していなかった場合、0 が返る。そうでない場合、拡張 length の符号化方式を使う際にサーバが対応できる最大リクエスト長(4 バイト単位)が返る。

## 第６章　謝辞

Clive Feather (IXI) は、この拡張提案で使用した拡張 length 符号化方式を考案してくれた。

入り口に戻る