Path: utzoo!attcan!uunet!cs.utexas.edu!usc!bloom-beacon!ATHENA.MIT.EDU!swick
From: swick@ATHENA.MIT.EDU (Ralph R. Swick)
Newsgroups: comp.windows.x
Subject: Re: Can X Be Used As A General-Purpose IPC Mechanism?
Message-ID: <8906291526.AA02087@LYRE.MIT.EDU>
Date: 29 Jun 89 15:26:40 GMT
References: <19833@cup.portal.com>
Sender: daemon@bloom-beacon.MIT.EDU
Organization: DEC/MIT Project Athena
Lines: 29


     Date:  24 Jun 89 01:45:13 GMT
     From:  imagen!atari!portal!cup.portal.com!Will@bloom-beacon.mit.edu  (Will
     E Estes)

     Can X be used as a general-purpose IPC mechanism across a network, or
     is X so specifically tailored to user-interface functions that it is
     not well-suited towards more general IPC and client/server functions?

Well, it _can_ be (and has been), but then you can also split firewood
with a screwdriver and hammer.  The several mechanisms in X for
inter-client data exchange are not tuned for traffic that has
high bandwidth requirements.  General full-function IPC is "not our job,
mate" but we were forced to specify the minimal capability necessary
to build useful multi-client windowed applications without waiting
for others to do real IPC.

     The way I understand it, X officially supports TCP/IP and DECnet.
     Are there plans to support TOPS, Novell, the Microsoft LAN Manager,
     and Appletalk?

Whenever any vendor chooses to propose a standard port/service-name/
name-server-attribute-list/whatever for an X client and server to
connect on a particular network transport, I'm sure there will be
others willing to discuss and/or adopt it.   Common or Standard
application-level syntax (e.g. command line args) for selecting
alternate transports is a slightly more touchy problem, as it has
direct impact on pre-existing users and applications.  I'm not
aware of any formal proposals for either at this time.