HDTenEightyP/NetNews huggingface dataset:
From: dchen@ctp.com (Denys Chen)
Subject: Re: scared customers
Date: Tue, 6 Oct 1992 19:46:38 GMT
Distribution: na
Organization: anonymous

In article <1992Oct5.173444.24966@meaddata.com>, srivasm@meaddata.com (M. C. Srivas) writes:
|> In article <DWF.92Oct5092154@hope.acl.lanl.gov>, dwf@acl.lanl.gov (David W. Forslund) writes:
|> |> workstation world for 5-10 years.  I believe the workstation world now
|> |> is moving more to peer-peer computing in a truly distributed manner.
|> |> Client/server has difficulty scaling to large numbers of systems and
|> |> is most appropriate for systems in which the server is much more
|> |> powerful than the client.
|> |> 
|> |> --
|> |> David Forslund
|> 
|> If I take a look at OSF's DCE, or Sun's DOE and DOMF, it seems to me
|> that the world is indeed going to a client-server paradigm, away from
|> peer-peer. These client-server systems are supposed to scale to many
|> millions of machines and many millions of users. What do you have in
|> mind when you say:
|> 
|> 	"I believe the workstation world now is moving more to
|> 	peer-peer computing in a truly distributed manner."
|> 
|> I find that very hard to believe.
|> 
|> -Srivas.
|> 

The way I perceive the issue of "C/S vs. P2P" in today's distributed
computing paradigm is as following :

When it comes to the *TRANSPORT* level, P2P is the way the _network_ 
architecture should go. P2P is the essence of Distributed Computing in that 
it enables all nodes on the network to be equivalent to simplify network 
protocol, and to be expandable in its intelligence to manage the network 
resources. One evidence that supports this vision is IBM's extending (or shall 
we say _sustaining_ ?) LU6.2/PU2.1 (which is the only animal that has P2P 
behavior in the old SNA zoo) as the corner stone of its APPN, which is the network
fundation of its new SAA.

The C/S model, on the other hand, will still be the major computing paradigm 
on the *APPLICATION* level. For an application designer, C/S is intuitive
and actually models the real world more closely in a lot of cases.

There's nothing wrong with a C/S *application* built on a P2P *network*; 
Actually, that's probably going to be more and more usual a model you'll
see in the next couple of years. 

However, I do maintain that there is NOTHING wrong with a P2P
application built on a P2P network either.

Hope my thought doesn't SCARE too many people.


-- 
***********   Denys Jyh-Hwa Chen      dchen@ctp.com    1-617-374-8271   ***********
NOTHING IN THIS ARTICLE REPRESENTS VIEWPOINT, OPINION, OR WHATSOEVER OF THE 
ORGANIZATION FROM WHICH THIS ARTICLE IS POSTED.
From: toddpw@cco.caltech.edu (Todd P. Whitesel)
Newsgroups: comp.client-server
Subject: Re: My personal ideas on Client/Server
Date: 9 Oct 1992 13:18:56 GMT
Organization: California Institute of Technology, Pasadena
NNTP-Posting-Host: punisher.caltech.edu

ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) writes:

>That's strange. I thought of OLE as being roughly equivalent to Publish/
>Subscribe under Macintosh System 7, only without the network transparency.

This is probably true of OLE 1.0. I am no expert on OLE but 2.0 was supposed
to have network transparency and a considerably more powerful object model.

>This allows applications to call on the services of other applications, eg a
>word processing program doesn't need to provide drawing tools to manipulate
>graphics, it can make use of the services of an existing drawing program.

OLE does this also. The stuff I worked on was definitely for OLE 2.0, and it
was intended to be a toolkit in a DLL that would help third-parties retool
their apps for OLE 2.0 compatibility.

>AppleEvents aren't a scripting language per se, but they do provide the
>basis on which you can build a scripting system to coordinate tasks involving
>a whole bunch of applications working in concert.

OLE 2.0 is a more fundamental protocol that defines common app operations and
allows apps to speak to each other with a more powerful language that includes
both direct, pre-defined standard messages and more macro-like scripting. The
key difference is that with AppleEvents you _have_ to build the system -- and
Microsoft has implemented OLE on top of AppleEvents -- but with OLE you have a
lot of things built in. It seems to me to have a much broader scope than
AppleEvents.

It's been a year, so I'm pushing my recollection of OLE somewhat. I'll leave it
to somebody else who knows more to expound on the details. The only stuff I
know more about is basic architecture of the communications path between OLE
compliant apps, and what the common messages would be like. This has all been
handed out to developers so I _think_ it's safe for me to talk about it...

Todd Whitesel
toddpw @ cco.caltech.edu
From: jeroenkw@htsa.aha.nl (Jeroen Kwast)
Subject: Re: Client-Server
Organization: Algemene Hogeschool Amsterdam, The Netherlands
Date: Fri, 16 Oct 1992 11:42:42 GMT

In article <1bka4kINNc0h@ef2007.efhd.ford.com> wwm@ef5003.efhd.ford.com (Bill Meahan) writes:
>In article <1992Oct15.142133.7998@htsa.aha.nl> benc@htsa.aha.nl (Ben Castricum) writes:
>>In article <1992Oct15.111641.29400@htsa.aha.nl> you write:
>>>
>>>Hello out there,
>>>
>>>We were supprised to hear that a newsgroup exists about our great client-server.
>>>
>>>If you know it please give us some comments!
>
>For those of us who tuned in late? care to tell us what this is all
>about?
>
>WHOSE client-server?

Well, mine ...
>
>From where?

From the htsa DADS group.
>
>For what platforms?
>
>With what networks?

Any UNIX related network.
>
>?????????????????????????????????????????????????????
>
>
>(Methinks this group is about client-server in general, not somebody's
>specific "product")
>
Offcourse, but I thought I would begin with my product to launch a discussion.
>
Well client server is the first program that enables you to connect to
multiple sites but using 1 terminal for I/O.
It is used (at least for now) to connect people working in the same
company but in different countries. They can use a specific application
and respond(change) to I/O from others directly but the final respons
remains by source.
>
If you're interrested, let's us know and give some details about your
company.
						Dir. Jeroen. J
-- 
On a dark day Magicus M. said to me:  It's better to create an illusion of life,
                                      than live to create illusions.
Newsgroups: comp.client-server
From: torrie@cs.stanford.edu (Evan Torrie)
Subject: The Power game (was Re: Lotus Powerbook)
Originator: torrie@Xenon.Stanford.EDU
Organization: CS Department, Stanford University, California, USA
Date:  9 Oct 92 18:10:57 GMT

ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) writes:

>Funny, I thought POWER was the acronym IBM used to refer to the CPU
>architecture in the RS/6000. (No, I can't remember what it stands for.)

  Something like Performance Optimisation With Enhanced Risc.

-- 
------------------------------------------------------------------------------
Evan Torrie.  Stanford University, Class of 199?       torrie@cs.stanford.edu 
Embrace rationalism, reject superstition.           Break away from the past.
From: ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University)
Newsgroups: comp.client-server
Subject: Re: Lotus Powerbook
Date: 9 Oct 92 16:40:54 +1300
Organization: University of Waikato, Hamilton, New Zealand

In article <Bvtx14.60I@comp.vuw.ac.nz>, Gavin.Flower@comp.vuw.ac.nz (Gavin Flower) writes:
>
> Not to mention POWER is the code name for the project to develop a
> portable workstation for the European education market, headed by
> Acorn Computers, based on a new ARM chipset...

Funny, I thought POWER was the acronym IBM used to refer to the CPU
architecture in the RS/6000. (No, I can't remember what it stands for.)
Hence the PowerPC initiative with Motorola and Apple, to pack all that
functionality onto one chip, so it's fit to use in a PC instead of a UNIX
box.

Lawrence D'Oliveiro                       fone: +64-7-856-2889
Computer Services Dept                     fax: +64-7-838-4066
University of Waikato            electric mail: ldo@waikato.ac.nz
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+13:00
I have a thing about almost any human-computer interaction technique that
starts with the word "cognitive". They always seem to me far too intellectual
and likely to miss the gestalt of what is going on.       -- Bruce Tognazzini
From: tay@hpbbi4.BBN.HP.COM (#Michael Taylor)
Date: Wed, 7 Oct 1992 17:28:48 GMT
Subject: DCE and NFS
Organization: Hewlett-Packard GmbH
Newsgroups: comp.client-server

Can OSF - DCE security (user registry) end naming services support NFS?
How are then network wide excess rides (UID for NFS) administored? 
Where can I find more information/documentation about DCE?

Pax,

Mike Taylor
Computer Systems Organization Europe

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Surface: Hewlett-Packard GmbH     Internet: tay@hpbbn.bbn.hp.com
	 Herrenberger Strasse 130    Phone: ++49 (07031) 14-1198
	 7030 Boeblingen, Germany      Fax: ++49 (07031) 14-2721
Newsgroups: comp.client-server
From: momtahan@bnrca (Parham Momtahan)
Subject: Re: Client/Server - rpc
Organization: Bell-Northern Research, Ottawa, Ontario, CANADA
Date: Fri, 16 Oct 92 15:06:19 GMT

In article <2485@shuksan.boeing.com>, sam2747@shuksan.boeing.com (Scott Moody) writes:
|> It seems RPC has been branded as a total co-routine concept,
|> where you totally block until the callee is finished
|> servicing the request, then that callee (server) waits for more.
|> 
|> There is a reason for waiting, and that is because of the return 
|> parameters. A 'connection' is required in some communication
|> schemes. Clicking a button, and not having something happen
|> (even if you wait awhile), is usually better than clicking 6 buttons
|> and then sometime later seeing 6 things happen.
|> 
|> I think the RPC mechanism should be thought of as the Ada rendevous,
|> where one blocks until finished retrieving important information.
|> If there is nothing to return, then let the caller continue.
|> [..deleted..]

One reason for blocking the caller is flow control. This is to
avoid the complexity of coping with the callee being flooded by
repeated calls from the same caller.

However, since the callee has to cope with concurrent callers, I think
having non-blocking calls is just an extension.

The most important reason for blocking the caller is to simplify 
failure semantics. If the caller makes a call and carries on assuming
that the effect of its call is in place while the callee, say, has crashed
in the middle of executing the call, you can get into 'interesting'
situations.

I would rather have blocking procedure/function and non-blocking
send/send-with-reply as two completely separate classes of facilities.
The former being simple but potentially slow; and vice-versa for the
latter.



Parham Momtahan.  
________________________________________________________________________
Bell-Northern Research Ltd, Dept 0R00 |     
PO Box 3511, Station C, Ottawa        |   email: momtahan@bnr.ca 
Ontario K1Y4H7, Canada.               |                                 
------------------------------------------------------------------------ 
X.DISCLAIMER: Contents (if found) may not represent my employer's views.
Newsgroups: comp.client-server
From: erek@helios.enea.se (Erik Ekstr|m)
Subject: Backups in a networkenvironment.
Organization: Enea Data AB, Sweden
Distribution: comp
Date: Tue, 13 Oct 1992 09:01:06 GMT


I have a problem with backups in a network environment (TCP/IP and IPX).

I want to use a Aviion workstation (Data General) as a backup-server. Connected to this
server we have a lot of disks and a tapestation.

Out in the network we have a MV40000 (Data General), an Aviion server and Novell servers.
We have portable Netware and NFS on the MV40000.
The requirement is to be able to backup/restore  these servers disks to the disks connected to 
the backupserver. Later the backups is transfered to tape.

Any comments? Is it any products (commercial or public domain) that support this or parts of it?

--
Erik Ekstr|m	- erek@enea.se
ENEA DATA AB
Sweden 



--
Erik Ekstr|m	- erek@enea.se
ENEA DATA AB
Sweden 
-- 
Erik Ekstr|m	- erek@enea.se
ENEA DATA AB
Sweden 
Newsgroups: comp.client-server
From: chris@suite.sw.oz.au (Chris Maltby)
Subject: Re: Defining Client-Server
Organization: Softway Pty Ltd
Date: 16 Oct 92 05:08:25 GMT

In <1992Oct14.122702.24159@samba.oit.unc.edu> dil.admin@mhs.unc.edu (Dave Laudicina) writes:
>>There is clearly a lot more to client-server, but the important concept
>>is partitioning of Processing, Presentation, and Data.

>In article <1992Oct12.165832.10614@devildog.att.com>  writes:
>I think you have given an excellent definition of client server.

I think there's one other point which usually gets lost in the definition;
it's to do with efficiency. The split of processing between server and
client is optimal when it makes minimum demand for both processing and
communications bandwidth. I know the "costing" algorithm is ill defined,
but things which make excessive use of bandwidth (say X Windows) might
have their magic "client-server" status revoked under my test...

Chris
-- 
Chris Maltby - Softway Pty Ltd		Internet: chris@softway.sw.oz.au

PHONE:	+61-2-698-2322	"I'm waiting for X-Windows to become just that;
FAX:	+61-2-699-9174	 Ex-Windows" - A McGrath.
From: ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University)
Newsgroups: comp.client-server
Subject: Re: My personal ideas on Client/Server
Date: 8 Oct 92 15:50:58 +1300
Organization: University of Waikato, Hamilton, New Zealand

In article <1992Oct8.013106.21116@ryn.mro4.dec.com>, anderson@bigun.enet.dec.com (Keith J. Anderson) writes:
>
>         o Applications run on desktop

This would tend to rule out X Windows, wouldn't it?

>
>     o Distributed Function
>          Examples:
>            DEC ACA Services, DECmessageQ, OSF DCE
> 	 Biggest growth area for future : application talking to application.

Is anybody working on a scheme for breaking down the seams between applications?
That is, not only can they share data, but they can share it in a transparent
fashion by directly invoking each other's services when appropriate, without
the user having to remember which application to use to perform which function.
Apple's AppleEvent Object Model seems to me to be one step on this road, which
has already garnered a significant degree of vendor support. The only other
idea I can think of that sounds remotely similar is Sun's ToolTalk (assuming
I haven't got a completely wrong idea of what ToolTalk is all about).

Or is this what the Object Request Broker idea is all about?

Lawrence D'Oliveiro                       fone: +64-7-856-2889
Computer Services Dept                     fax: +64-7-838-4066
University of Waikato            electric mail: ldo@waikato.ac.nz
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+13:00
To someone with a hammer and a screwdriver, every problem looks
like a nail with threads.
Newsgroups: comp.client-server
From: jeroenkw@htsa.aha.nl (Jeroen Kwast)
Subject: Re: Client-Server
Keywords: Perfect
Organization: Algemene Hogeschool Amsterdam, The Netherlands
Date: Fri, 16 Oct 1992 11:46:30 GMT

In article <1992Oct15.113314.776@htsa.aha.nl> donnyj@htsa.aha.nl (Donny Janzen) writes:
>In article <1992Oct15.111641.29400@htsa.aha.nl> jeroenkw@htsa.aha.nl (Jeroen Kwast) writes:
>>
>>Hello out there,
>
>Hello to you too.
>
>>We were supprised to hear that a newsgroup exists about our great client-server
>
>Don't be, I've heard story's about your server which are absolutely awesome.
>
>>If you know it please give us some comments!
>>						MM.
>
>Well I think this says it all.
>
I don't know what you mean, please explain, do you want a sample program
or did you just want to make a statement.

						Dir. Jeroen.J

-- 
On a dark day Magicus M. said to me:  It's better to create an illusion of life,
                                      than live to create illusions.
Newsgroups: comp.client-server
Subject: Re: Lotus Powerbook
From: Gavin.Flower@comp.vuw.ac.nz (Gavin Flower)
Date: Fri, 9 Oct 1992 00:51:03 GMT
Organization: Dept. of Comp. Sci., Victoria Uni. of Wellington, New Zealand.

In article <moofie-081092135232@moofie.apple.com> moofie@apple.com (Steve Klingsporn) writes:
>In article <1992Oct7.184921.26543@hsr.no>, jonny@hsr.no (Jonny Rein
>Eriksen) wrote:
>
>
>> 
>> Also I would be interested to know if Powerbook is going to support GUPTA SQL-Base
>> 
>> 
>> If anyone can help, please followup or E-Mail at jonny@hsr.no
>
>What is PowerBook?  PowerBook is a registered trademark of Apple
>Computer, Inc.
>
>I'm sure there are way bad legal ramifications here!!!
>
>Just MY opinion,
>
>Steve

Not to mention POWER is the code name for the project to develop a
portable workstation for the European education market, headed by
Acorn Computers, based on a new ARM chipset...

Gavin
-- 
Tomorrow's Society                              | flower_g@kosmos.wcc.govt.nz
    Depends on                                   ----------------------------
Today's Children  - help us raise them properly! 
*******  These comments have no known correlation with dept. policy!  *******
Newsgroups: comp.client-server
From: benc@htsa.aha.nl (Ben Castricum)
Subject: Re: Client-Server
Organization: Algemene Hogeschool Amsterdam, The Netherlands
Date: Thu, 15 Oct 1992 14:21:33 GMT

In article <1992Oct15.111641.29400@htsa.aha.nl> you write:
>
>Hello out there,
>
>We were supprised to hear that a newsgroup exists about our great client-server.
>
>If you know it please give us some comments!
>
>
>						MM.

I'm a really big fan of the client-server program.. However I still don't
have any of those great utilities belonging to it.. I would also
like to have the last update of it (I believe v17.16 patch 14a)..

If anyone  has one of the above pleeeaaaasssseeee Email it
or post it on the net.. there are probably much more people wanting them..
-- 
/****************************************************************************/
/* benc@solist.htsa.aha.nl               Who cares anyway?                  */
/****************************************************************************/
-- 
/****************************************************************************/
/* benc@solist.htsa.aha.nl               Who cares anyway?                  */
/****************************************************************************/
Newsgroups: comp.client-server
From: steveh@devildog.att.com (Steve Hendershott)
Subject: Defining Client-Server
Keywords: Client-Server Computing
Organization: AT&T IMS - Piscataway, NJ (USA)
Date: Mon, 12 Oct 1992 16:58:32 GMT

In order to define client-server computing we have to be practical
about it.  It doesn't exist just for it's own sake, it accomplishes or
enables something to happen. I believe client-server is based on moving
processing to processors that can do it the best. By the best, I mean
at the least cost for processing and network. This moving of processing
can be called partitioning. An application can be partitioned to
optimize it's performance. The pieces we partition are conventionally:

o Presentation
o Processing
o Data

Presentation is the display portion, everything necessary to draw the
screen and present the data. This is the part the user sees. Processing
is the unseen part of computing. The manipulation that an application
must do to move, compute, and prepare data for Presentation or Data.
Data is the data management piece, mostly represented by Data Base
Management Systems, but also could include simpler file management.

Using these ideas, that we want to partition the three pieces of
computing to optimize an application, we can see how a simple example
of client-server evolved. Look at the ATM machines. They obviously are
mostly Presentation. They can't all be expected to have the Data piece,
so they are probably partitioned (simplified) as follows:

Client ATM's
	Presentation
	Processing <---+
                   |
Bank Server(s)     |
	Processing <---+
	Data

The Client and Server are then communicating their transaction at a
Processing to Processing level, using whatever protocols or method is
available and useful for the network. The important part is that the
servers do not have to worry about Presentation protocols on the
ATM's.

There is clearly a lot more to client-server, but the important concept
is partitioning of Processing, Presentation, and Data.

Stephen W. Hendershott
AT&T
steveh@devildog.att.com

-- 
Stephen W. Hendershott
steveh@devildog.att.com
Newsgroups: comp.client-server
From: martijn@htsa.aha.nl (Martijn van der Heide)
Subject: Re: Client-Server
Organization: Algemene Hogeschool Amsterdam, The Netherlands
Date: Thu, 15 Oct 1992 11:26:43 GMT

In article <1992Oct15.111641.29400@htsa.aha.nl> jeroenkw@htsa.aha.nl (Jeroen Kwast) writes:
>
>Hello out there,
>
>We were supprised to hear that a newsgroup exists about our great client-server.
>
>If you know it please give us some comments!
>
>
>						MM.

Well, to be absolutely honest, I have checked for such a newsgroup since the
first version written. I sincerely hope that everyone will soon be able to 
play this absolutely terrific game.
As this is the very first time anyone hears about this great server, I think
we need to tell 'em how to start it (to say the least) and how to play.
I also think I should hurry writing the help pages on this server.

Lots of luck wished to all you great crew-members of the client-server!
-- 

+------------------------------------------------------------------------------+
| Even Magicus M. and Vulture the dragonslayer don't understand why you exist  |
+------+----------------------------------------------------------------+------+
Newsgroups: comp.client-server