Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!decwrl!ucbvax!bloom-beacon!EXPO.LCS.MIT.EDU!rws
From: rws@EXPO.LCS.MIT.EDU
Newsgroups: comp.windows.x
Subject: Re: Why X Windows?
Message-ID: <8904271326.AA00393@expire.lcs.mit.edu>
Date: 27 Apr 89 13:26:27 GMT
References: <9740090@hpfclp.SDE.HP.COM>
Sender: daemon@bloom-beacon.MIT.EDU
Organization: The Internet
Lines: 26


    The reason for this is INHERENT in the X protocol: multiple server
    round-trips are required for a reparenting window manager.

You just switched arguments entirely.  The client/server model is independent
of the "policy" decision of where to place window manager functionality.

    I know your first objection to my statement would be that you can always
    use fast communication on the local machine via shared memory or such

Bingo.

    but that really only provides significant benefits for large data transfers

Do you have (multiple) implementations and measurements to back up this
statement?

    The process switching and synchronization delays would still exist.

Yes, but how are you proposing to get around them?  If you want to support
multiple concurrent applications, some form of synchronization will still
exist.  Since you haven't stated what your alternative architecture is, it's
hard to argue about whether or not process switching has gone away (or
instead been replaced with some other delay).  And, in a properly designed
system, it's not clear that process switching should be a "significant"
disadvantage (else why are we all running multi-process systems :-).