rws@EXPO.LCS.MIT.EDU (05/24/89)
X Registry The MIT X Consortium is maintaining a registry of certain X-related items, to aid in avoiding conflicts and to aid in sharing of such items. Requests to register items, or questions about registration, should be addressed to xregistry@expo.lcs.mit.edu or to Bob Scheifler Laboratory for Computer Science 545 Technology Square Cambridge, MA 02139 Electronic mail will be acknowledged upon receipt. Please allow up to 4 weeks for a formal response to registration and inquiries. The registry will be published as part of the X software distribution from MIT. All registered items must have the address of someone responsible for the item, or a reference to a document describing the item and the address of where to write to obtain the document. Registration of conflicting items will not be permitted (the same value will not be assigned two different meanings) except where explicitly indicated. Items in the following categories are acceptable for registration: Organization names These should generally be used as prefixes for other registered names. Examples: "MIT"; "X3D". Keysyms (name, value, #define'd name in C, other languages) Only "private" keysyms (with 29th bit set) can be registered by organizations; standard keysyms must be approved by the Consortium. Since keysym numeric values are explicitly private, we will permit (but not encourage) conflicting registration here. Authorization protocol names See Section 8 of the protocol. Names should generally have an organizational prefix. Examples: "MIT-MAGIC-COOKIE-1"; "MIT-KERBEROS-5". Vendor string formats See Section 8 of the protocol. The vendor string should generally have an organizational prefix. Example: "MIT X Consortium". Protocol extension names As used in the QueryExtension and ListExtensions protocol requests. The name should generally have an organizational prefix. Example: "X3D-PEX". Host Families See the "family" component of the HOST structure in the protocol. Values for private families will be assigned by MIT. Examples: Starlan address; OSI address; hostname string Property names As stored on windows in the server. See Sections 4.1.2, 4.1.3, 5.1.1, and 6.3 of the ICCCM, and Section 9.2 of the Xlib manual. Registration must include the context in which the property is used (e.g. root window, top-level client window). In general, private property names should start with a leading underscore, followed by the organizational prefix, followed by another underscore. Property type names See "Property names" above. Selection names See Section 2.6.1 of the ICCCM. In general, private selection names should start with a leading underscore, followed by the organizational prefix, followed by another underscore. Selection targets See Section 2.6.2 of the ICCCM. In general, private selection targets should start with a leading underscore, followed by the organizational prefix, followed by another underscore. WM_PROTOCOLS protocols See Section 4.1.2.7 of the ICCCM. In general, private protocols should start with a leading underscore, followed by the organizational prefix, followed by another underscore. ClientMessage types See the "type" field in the ClientMessage event in the protocol, and Section 4.2.8 of the ICCCM. In general, private types should start with a leading underscore, followed by the organizational prefix, followed by another underscore. Font Foundry names See Section 3.1.2.1 of the XLFD. This will typically be an organization name. Font CharSet (Registry and Encoding) names See Sections 3.1.2.13 and 3.1.2.14 of the XLFD. For ISO standards, the format will generally be: "ISO" + <standard-number> + "-" + <part-number> Example: "ISO8859-1". Font Property names See QueryFont in the protocol, and Section 3.2 of the XLFD. In general, private properties should start with a leading underscore, followed by the organizational prefix, followed by another underscore. Resource types See Section 10.11 of the Xlib manual and Section 9.1 of the Xt manual. Application classes See Section 4.1.2.5 of the ICCCM and Section 9.1.8 of the Xlib manual. [Only class names, not instance names.]
mikew@fx.com (Mike Wexler) (07/07/90)
According to ./mit/doc/Registry/README, "The registry will be published as part of the X software distribution from MIT." Are there any plans to publish this more frequently. For instance, it could be posted to comp.windows.x monthly. How active is the registry? -- Mike Wexler (mikew@fx.com)
rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (07/09/90)
Are there any plans to publish this more frequently.
You can get an up-to-date copy whenever you want by sending a message to
xstuff@expo.lcs.mit.edu. In the usual case, the message should have a
subject line and no body, or a single-line body and no subject, in either
case the line looking like:
send docs registry
Some mailers produce mail headers that are unusable for extracting return
addresses. If you use such a mailer, you won't get any response. If you
happen to know an explicit path, you can include a line like
path foo%bar.bitnet@mitvma.mit.edu
or
path zot!gzork!me@uunet.uu.net
in the body of your message, and the daemon will use it.
For instance, it could be posted to comp.windows.x monthly.
I'm not interested in doing this.
How active is the registry?
I don't keep track of frequency of update.