Bug 6801

Summary:	reply element ought to have a "multiple replies" attribute
Product:	XCB	Reporter:	Jamey Sharp <jamey>
Component:	Protocol	Assignee:	Josh Triplett <josh>
Status:	RESOLVED MOVED	QA Contact:
Severity:	enhancement
Priority:	medium
Version:	unspecified
Hardware:	All
OS:	All
Whiteboard:
i915 platform:		i915 features:

Description Jamey Sharp 2006-05-01 19:52:57 UTC

The XML protocol descriptions currently distinguish between requests that can't
have a reply and those that can have one or more replies. It would be nice if we
could further distinguish between the common case of a request with exactly one
reply, and the quite unusual case of a request with an arbitrary number of replies.

Protocol implementations might use this attribute to detect programming errors
that are otherwise hard or unlikely to detect.

Comment 1 Josh Triplett 2006-10-12 03:08:11 UTC

Jamey wrote:
"It would be nice if we could further distinguish between the common case of a
request with exactly one reply, and the quite unusual case of a request with an
arbitrary number of replies."

On the one hand, I do think documenting that in the protocol descriptions seems
like a good thing.  On the other hand, I'd like to do so in such a way that
prevents anyone from creating a new extension that has such a request, along the
lines of "if this attribute exists, the tuple (request/@name, request/@opcode,
/xcb/@extension-xname) must have one of the values [(ListFontsWithInfo, 50, ""),
...]".  If possible, I'd love to do that in the XML Schema, so that files which
attempt to use it for something other than one of those fail to validate;
barring that, I'd at least like to see something like that in the XSLT, but that
wouldn't help other users of the protocol descriptions.

Comment 2 chemtech 2013-03-15 14:22:02 UTC

Jamey Sharp 
Do you still experience this issue with newer soft ?
Please check the status of your issue.

Comment 3 GitLab Migration User 2019-02-16 19:39:47 UTC

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/proto/xcbproto/issues/3.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.