[patch] abstract socket support for xtrans

[Bill Crawford]

On Sunday 19 March 2006 23:02, Jamey Sharp wrote:
> On Sun, Mar 19, 2006 at 09:18:00PM +0000, Bill Crawford wrote:
...
> > Well, yes, that's the idea :) It would actually be fairly easy if it
> > weren't for all the conditional compilation based on what library is
> > #include'ing it.
>
> I think you and I are on the same page, but since I'm not sure: I was
> trying to suggest that you should move the library-dependent stuff into
> the calling library (e.g., libX11 or the X server) and out of xtrans. It
> doesn't seem like a very hard design problem if approached that way.

My ideas were sort of condensing into either a) passing in a callback to use 
for translating the port in some application-specific way or b) passing in 
parameters like "tcp port base" and "prefix to use in creating unix path". 
Since that's rather vague, an example:

	XtlNames foo = { "X11", "X$X", 6000 };
	connection = XtlNewConnection (&foo);
	if (! XtlConnect (connection, host, port)) {
		XtlDestroyConnection (connection);
		return 0;
	}

 etc.

It (how the sockets are named/numbered) shouldn't really be part of the 
transport itself; I think that code should actually become agnostic to X 
protocol, perhaps usable for other purposes. There isn't really any very 
elegant solution, though; if it weren't for the "well known port" issue, the 
application above could pretty much ignore details of the transport and vice 
versa.

> In some sense it's not going to disappear for a while. Top-of-tree on
> libX11 still has a build-time option for not using XCB and instead using
> the old code. I expect that option to persist for some time.

Fair enough, I just don't see the benefit of "improving" xtrans if it's being 
obsoleted :)

> Well... (/me desperately hopes this doesn't turn into a flame war)

Good grief no. I certainly had no intention of flaming anyone. I'm mortified 
to think I might have given that impression :$

> That's an interesting discussion we could have. The argument I was given
> in the design of XCB is that the sockets interface is already an
> abstraction of the transport layer, and we don't need another one.

An argument that's actually a pretty powerful one. Sockets are a great 
abstraction, and appear to have won the transport interface war before it 
started :)

Stripping the xtrans layer down to just unix and tcp sockets would actually 
make life a lot simpler, as we've already seen. Eliminating it altogether is 
possibly the right approach, in fact. I'm a little sad, 'cause I was looking 
forward to rewriting it :) but I wouldn't mourn long.

> --Jamey