[patch] abstract socket support for xtrans

[Jamey Sharp]

On Sun, Mar 19, 2006 at 09:18:00PM +0000, Bill Crawford wrote:
> On Sunday 19 March 2006 20:03, Jamey Sharp wrote:
> > I assume the release managers and distributions aren't opposed to
> > cross-module version build dependencies? I don't see any problem with
> > picking one common interface for xtrans and then fixing all the callers
> > to use it. You'll have to update them to quit #include-ing xtrans.c
> > anyway. :-)
> 
> 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 work will make all X11_t issues irrelevant anyway: libX11 will use
> > XCB in place of xtrans for the connection to the X server. (xtrans
> > continues to be used for XIM, but at least there's only one copy
> > compiled in instead of two...) But I think it's valuable to have xtrans
> > fixed up in the meantime.
> 
>  ... if it's going to disappear, I'm not going to waste time on it.

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.

> I'd prefer to have a fixed up interface that can be used just as
> easily from XCB/XCL and from FS/ICE/whatever else uses it. The
> principle of isolating the application layer from the transport layer
> is a good one.

Well... (/me desperately hopes this doesn't turn into a flame war)
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. 

--Jamey
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: Digital signature
URL: <http://lists.x.org/archives/xorg/attachments/20060319/59b1281a/attachment.pgp>