XTrap vs. RECORD/XTEST

[Eamon Walsh]

Daniel Stone wrote:
> On Thu, Jun 12, 2008 at 07:27:17AM -0700, Rob Currey wrote:
>   
>> From the XTrap manpage ...
>>
>> "It is strongly suggested that users of XTrap technology begin developing 
>> against RECORD/XTEST as it is the intention of the X Consortium to drive 
>> these two extensions in the standards process for providing the protocol 
>> capturing/synthesis functionality. Some members of the xtest working group 
>> are actively researching migration issues between XTrap and RECORD."
>>
>> This leads me to think XTrap is deprecated
>>
>> But then I was recently corrected ...
>>
>>     
>>> From: Daniel Stone <daniel at fooishbar.org>
>>> Subject: Re: Wrapping up 7.4 (finally)
>>>       
>>> ... XTrap is absolutely not dead.
>>>       
>> So, Has XTrap been superceeded by RECORD/XTEST?
>>     
>
> Sorry, I'm an idiot.  Yes, it pretty much has, but no-one who remembers
> this stuff is still alive, so removing it is basically just pending
> someone investigating the two to find out if there's anything left in
> XTrap ('it's a trap') that needs to be ported to XTest.
>
> Cheers,
> Daniel
>   

I have carefully reviewed the XTest and RECORD specs from xorg-docs and 
an XTrap spec I managed to find at [1].  According to that spec, XTrap 
offers no functionality over RECORD/XTest, except for one 
"GetStatistics" request that could easily be implemented in RECORD or 
done on the client side.  XTrap does not support capturing replies, and 
it has limited support for extensions.  The XTestFakeInput request and 
XETrap_SimulateXEvent are identical semantically, although probably not 
on the wire (the XTrap spec does not include wire encodings).  
RECORD/XTest is, in short, a superset of XTrap in terms of functionality.

One unrelated thing I also noticed was that RECORD probably can't handle 
XGE properly, at least not the part where you specify the range of 
events you are interested in as a CARD8-CARD8.

The manual page text quoted by the OP, containing the deprecation 
notice, has to be at least 10 years old judging by the DEC e-mail 
address and phone number in it [2].  The server-side code itself was 
written in 1991 and updated to X11R6 in 1994.  It contains the following 
ominous comment, which is in serveral of the files:

 *      This is shared code and is subject to change only by team approval.


Well, I don't know if the "team" would be happy, but getting rid of 
XTrap would not lose any functionality, reduce the amount of protocol 
(my personal motivation), and quell the confusion about which extension 
to use.


[1] perso.tls.cena.fr/jestin/Video/Docs/XTrap_Arch.ps.gz
[2] http://linux.die.net/man/1/xtrapproto


-- 
Eamon Walsh <ewalsh at tycho.nsa.gov>
National Security Agency