Newsgroups: comp.sys.amiga.advocacy
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!van-bc!ubc-cs!uw-beaver!cornell!johnhlee
From: johnhlee@CS.Cornell.EDU (John H. Lee)
Subject: Re:   IAC (was Re: Clipboard (was Re: The Amiga's Future))
Message-ID: <1991Jun17.022209.18076@cs.cornell.edu>
Sender: news@cs.cornell.edu (USENET news user)
Nntp-Posting-Host: fulla.cs.cornell.edu
Reply-To: johnhlee@cs.cornell.edu (John H. Lee)
Organization: Cornell Univ. CS Dept, Ithaca NY 14853
References: <mykes.3558@amiga0.SF-Bay.ORG> <1991Jun15.225638.11517@cs.cornell.edu> <mykes.3628@amiga0.SF-Bay.ORG>
Date: Mon, 17 Jun 1991 02:22:09 GMT
Lines: 114

In article <mykes.3628@amiga0.SF-Bay.ORG> mykes@amiga0.SF-Bay.ORG (Mike Schwartz) writes:
[...]
>So far, you've described a distributed network application.  For example,
>if you want to run FrameMaker, you don't need a binary version of Frame
>for each workstation that is going to use it, just for a "server" machine
>somewhere on the network.  The "clients" (again, my knowledge of X is limited)
>are programs that only provide user-interface support.  The clients draw what
>the server tells them to and sends input events back to the server...

Well, no, X programs are not distributed network applications, at least in
the fashion that I know that term.  For those kind of applications, you'll
need something like the ISIS Distributed Programming Environment developed
here at Cornell which allows multiple processes on multiple machines in a
heterogenous network to act as a single "group" program (end of shameless
plug--my current project is an X Window System-based performance tool for
ISIS.)  In the usual case, the application runs entirely on one host
machine.  The server is not considered part of the application, since that
is implemented once by the workstation vendor.  This is not to say that
X applications can't be distributed, though (such as my program.)


[...]
>The notion of "server" and "client" are reversed in X to what I think of
>them as.  A server, to me, is a program on a machine dedicated to doing
>a specific application (like E-Mail or FileSharing).  A client, to me,
>is a program run on people's workstations that talks to the server.  The
>reversal in terminology doesn't confuse me, though...

As for the terms "client" and "server", according to the original model
I learned at Berkeley, the "server" provides services to multiple
"clients".  Only "clients" initiate the connection, never the other way
around.  This implies that while the system is up, servers are always
waiting for a connection, whereas clients don't.  The usual guide is that
the resource that must be shared is operated as the server, but it is
not always easy to classify things.

According to the X Window System model, the service is the screen,
keyboard, mouse, graphics facilities, and the graphics processing power.
For each set of the above, there is only one X server program running
providing access through the X protocol for multiple client programs.
From your description of FrameMaker, the model is indeed "turned around",
in that applications are "computation servers", and the workstations are
"display clients."  However, X Window System applications aren't written
as two programs like Framemaker (if I'm interpreting you correctly), since
all applications have the operational parts of the GUI contained within
them.  Both application models have their advantages and disadvantages.


>There is no rule in networking that says that the client and server can't
>be located on the same physical machine, either...

True, but then I did imply that (the "local" and "UNIX domain" connections
I mentioned are used only when the client and server are on the same
machine.)


>The notion of "server" and "client" are reversed in X to what I think of
>them as.  A server, to me, is a program on a machine dedicated to doing
>a specific application (like E-Mail or FileSharing).  A client, to me,
>is a program run on people's workstations that talks to the server.  The
>reversal in terminology doesn't confuse me, though...

(See above.)


[...]
>It is nice to add a layer on top of network protocols like this, but it
>still doesn't change the fact that the network is being used to do distributed
>processing.  That is all I was trying to say.  The talk here was that the
>Mac and PC have their own flavors of X-style applications, while the Amiga
>doesn't, and that resource sharing is the meat and potatoes of networking.
>In the PC and Mac networking universes (using your terminology), they have
>Database, Paint, and Word Processing clients that allow servers to act on
>the same documents in real time...

As I said before, not really.  The X server really doesn't participate
in "distributed processing" any more than does, say, a VT340 terminal.
I also don't dispute that fact that network applications exist for Macs
and PC while such Amiga- specific applications don't really exist yet.
I just wanted to clarify what exactly the X Window System is about and
to point out that there is nothing in the Amiga to preclude "X-style
applications", and that the native IPC and multitasking environment of
the Amiga actually makes the Amiga very attractive as an X Window System
platform.  That the Amiga doesn't have a standard network-independent
programming model of its own isn't any different from the situation with
Mac and IBM system.  I'm not familiar with the internals of the
applications you describe, but it appears that each application vendor
must supply a "display client" specific for his "application servers."
This is not the case with the X Window System.  All applications share
the same "display client."  If we adopt X Window System, we get all the
advantages of Mac and IBM network-independent applications plus the
advantage of access to all X Window System-based programs already out
there.


[...]
>I find this hard to swallow :)  I'd think that it might be relatively easy
>to port the GUI (server) portion of an APP to the Amiga, but porting the real
>guts of the application might be far from Easy.  Today, I know I can use
>X to run Frame FROM my Amiga, but I still need a network and a Sun (or
>whatever) to run the client binary...

That's why I said the "GUI" portion of the application is easy to port and
the OS-dependent part is another matter.  But something like the UNIX and
ANSI C libraries provided by SAS/C makes porting X applications to execute
ON the Amiga easier.  In fact, many of the X applications I can think of
should port with little difficulty.  The hard part is implementing the
X server and X libraries for AmigaDOS and, thanks to Dale Luck, that's
already done.

-------------------------------------------------------------------------------
The DiskDoctor threatens the crew!  Next time on AmigaDos: The Next Generation.
	John Lee		Internet: johnhlee@cs.cornell.edu
The above opinions are those of the user, and not of this machine.
