Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!samsung!think!ames!pasteur!ucbvax!bloom-beacon!EXPO.LCS.MIT.EDU!rws
From: rws@EXPO.LCS.MIT.EDU (Bob Scheifler)
Newsgroups: comp.windows.x
Subject: Re: X11 Server Porting Questions
Message-ID: <8912151535.AA01268@expire.lcs.mit.edu>
Date: 15 Dec 89 15:35:33 GMT
References: <5@wglen.UUCP>
Sender: root@athena.mit.edu (Wizard A. Root)
Organization: The Internet
Lines: 35


    1. How much of the sample server source code involves the following:

Use the Source, Luke.  Seriously, depending on other people's answers
probably won't get you that far.  The best way to understand the server
and it's relationship to your hardware and OS is to dive in, and actually
look at the code.

    Are there substantial differences between R3 and R4 in these areas?

Yes.

    2. What are the key advantages to waiting for the release of the R4 sample
       server and porting that, and what will the R4 server have over the
       R3 server?

LOTS.  Performance and robustness, to name two.  But, you'll have to wait
for R4 to actually come out to get the details from us.  There will be a
talk at the X Conference convering some of this.

    4. Will client applications developed for R3 be fully compatible (ie run 
       without changes) on an R4 server implementation?

Correct applications won't need changes.  But, there are fair number of buggy
applications out there (e.g. R3 xterm, passive grabs in the R3 Intrinsics,
I think R3 InterViews, the version of Frame that we've tried, Composer I think)
that will get protocol errors when run against a strict R4 server.  A typical
bug is passing a do-not-propagate-mask with "extraneous" bits set.  Our R4
server will have a "bug compatibility" mode to allow you to continue to run
buggy R3 clients.

    5. Also, We have been made aware that there are at least three documents
       available to aid in porting a server.

These documents are included in the MIT R3 distribution, in doc/Server/.