HDTenEightyP/NetNews huggingface dataset:
From: dorai@cs.rice.edu (Dorai Sitaram)
Subject: Re: What are good references on learning Scheme
Organization: Rice University, Houston
Date: Mon, 23 Nov 1992 18:43:23 GMT

In article <GJR.92Nov23094656@chamarti.ai.mit.edu> gjr@zurich.ai.mit.edu writes:
>In article <1992Nov22.033413.1020@linus.mitre.org> crawford@boole.mitre.org (Randy Crawford) writes:
>
>|   Except that SICP doesn't mention call/cc anywhere.  I think that's a significant
>|   omission.  And since R3RS _does_ include continuations, I have to conclude that
>|   SICP didn't attempt to cover all of even R3RS, much less R4.
>
>
>SICP predates R3RS by a few years.  It even predates RRRS (R2RS).
>
>The decision to teach about continuations or not in an introductory
>class is a major difference of opinion between the "Indiana School"
>and the "MIT School".  SICP does not attempt to be a language tutorial
>nor is the course on which it is based really a programming class.
>There is a difference between teaching programming and teaching
>thinking about programs and the decomposition of large systems.  Both
>of them are valuable, but they are different.  Of course, you need
>concrete programs and concrete programming languages to do the latter,
>hence the use of Scheme and the tutorial-like material in SICP.
>
>Note that CALL/CC is not required by the reports :-).


How does one pronounce the abbreviation "SICP"?  I've been
saying "Sic P" without qualms all along, and only yesterday,
when someone I recommended the book to started snickering
did I realize that an alternate pronunciation would be
desirable.

That said, while I agree that SICP chooses to teach thinking
about programs over teaching programming, I don't think the
passing over of call/cc in the book can be attributed to
that choice.  Arguably, if SICP were written today, it would
contain call/cc or some variant, without such an act
spelling a compromise of any of its lofty goals.

--d
-- 

dorai@cs.rice.edu      !    It may be that the gulfs will wash us down;
dorai@owlnet.rice.edu  !      it may be we shall touch the Happy Isles.
Newsgroups: comp.lang.scheme,comp.lang.lisp
From: john@physiol.su.OZ.AU (John Mackin)
Subject: Wanted: Scheme prettyprinter as a UNIX filter
Organization: Department of Physiology, University of Sydney, NSW, Australia
Date: Sun, 22 Nov 1992 08:26:27 GMT

For some time, I have wanted a program that I could use to filter
Scheme definitions through and get them prettyprinted.  It would be
lovely to have some control over the formatting, but in the first
instance I will take whatever I can get.  I tried to implement this
using the prettyprinter from Slib and Scheme->C, but I didn't
succeed.  I don't doubt that that's a _possible_ approach, but
it was more work than I wanted to put in.  What I would really
like is something that I can just compile (regardless of what
language it's in -- so, Scheme->C or C) and have work.  It seemed
likely to me that someone else had already done this -- so if
you have, please reply by mail.  I will summarise if I receive any
positive responses.  Thanks!

-- 
John Mackin <john@civil.su.oz.au>
Knox's box is a 286.                 Fox in Socks does hacks and tricks
Knox's box is hard to fix.           To fix poor Knox's box for kicks.
Newsgroups: comp.client-server
From: danh@quantum.on.ca (Dan Hildebrand)
Subject: Re: Is Client-Server dead?
Date: Tue, 17 Nov 92 20:33:50 GMT
Organization: Quantum Software Systems

In article <1992Nov17.111656@is.morgan.com> mpiet@is.morgan.com (Mark Pietrasanta) writes:
>Okay.  I'll ask it.  Is Client-Server going down the tubes in
>favor of peer-to-peer?

Client-server applications are what you run on a network. Whether or not
that network has "servers" and "workstations" or runs "peer-to-peer" does
not change this.

>Are networks like Novell, Banyan, etc. that rely on the logical
>star of client-server a thing of the past now that Unix and
>Microsoft's Windows for Workgroups and Windows NT are on the
>horizon?

You will still likely have your database server process running on the node
with the big disk, fast processor and tape backup. As a result, that node
becomes a "server", even though the OS may be capable of making any node on
the LAN a server. 

>It would seem that business is more suited to a peer-to-peer
>environment, although IS typically isn't.  How do we IS'ers
>maintain our role (or any role) as the business units start to
>welcome the new peer philosophy?  Especially if they embrace
>Microsoft's solutions, which will mean they can support and
>develop with minimal man-hours and without IS?

Someone will still need to do the administration ( backups, installation
of new software, upgrades, etc ).
-- 
Dan Hildebrand                     email: danh@qnx.com
Quantum Software Systems, Ltd.     QUICS: danh  (613) 591-0934 (data)
(613) 591-0931 x204 (voice)        mail:  175 Terrence Matthews          
(613) 591-3579      (fax)                 Kanata, Ontario, Canada K2M 1W8
Newsgroups: comp.client-server
From: paul@suite.sw.oz.au (Paul Antoine)
Subject: Re: SQL and Client-server architecture
Organization: Softway Pty Ltd
Date: 19 Nov 92 02:48:31 GMT

In <1992Nov17.160748.5948@cbnewsl.cb.att.com> sdo@cbnewsl.cb.att.com (scott.orshan) writes:

>In article <92316.105420KSADEGH@auvm.american.edu> Kayvon Z. Sadeghi <KSADEGH@auvm.american.edu> writes:
>>I was wondering why all the client/server systems use SQL as their manipulation
>>language. I don't recall seeing any client/server that works on OO or
>>hierarchy, for example. Is this because its easier to implement client/servers
>>in SQL or is there any especial reason.

>I'm not sure why you say that all client/server systems use SQL.
>Perhaps all client/server SQL database systems use SQL (a tautology),
>but some databases don't, and non-database client/server packages
>probably have no need to use SQL.

>For example, plain RPCs and TP Monitor C/S calls pass arbitrary information
>between clients and servers.  Most client/server access is probably
>just remote file access, and that has nothing to do with SQL.

And I'd even dispute that most C/S access is not remote file access (as in 
our C/S system that talks to 3270-based applications).  The TP monitor is
used to route the data, and is aware of the type and number of servers and
where they're running, but there's no restriction on the data (i.e. it
needn't be SQL!).

The confusion probably arises because most C/S systems are used to more
efficiently access corporate data - but this needn't be in the form of
direct database access.  A lot of it can also be done through existing
applications (as in our case).  It just goes to show that getting consensus
on the eternal question 'what is C/S?' is well nigh impossible,

Regards,
Paul (a Tuxedo fan)

------------------------------------------------------------------------------
Paul Antoine, Softway Pty Ltd			    Net: paul@suite.sw.oz.au
PO Box 305, Strawberry Hills, NSW 2012, Australia   Tel: +61 2 698 2322
79 Myrtle St, Chippendale, NSW 2008, Australia	    Fax: +61 2 699 9174
------------------------------------------------------------------------------
Newsgroups: comp.client-server
From: nagle@netcom.com (John Nagle)
Subject: Re: Is Client-Server dead?
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Date: Wed, 18 Nov 1992 05:08:12 GMT

mpiet@is.morgan.com (Mark Pietrasanta) writes:
>Okay.  I'll ask it.  Is Client-Server going down the tubes in
>favor of peer-to-peer?

       The main purpose of client-server systems is isolation of the
manipulation of important data from the (probably graphical) user
interface.  Whether both reside on the same machine is not the central issue.
GUI-based applications tend to be mostly user interface in terms
of code volume, and breaking up the program into a user-friendly
client and a server whose users are programs seems to be a good
division of labor.

						John Nagle
From: dsr@lns598.tn.cornell.edu (Daniel S. Riley)
Newsgroups: comp.client-server
Subject: Re: Authentication of Clients in a C/S environment
Date: 23 Nov 1992 15:18:41 -0500
Organization: Wilson Lab, Cornell U., Ithaca, NY  14853
Distribution: world
NNTP-Posting-Host: lns596.tn.cornell.edu


In article <19921122175106SEB1525@MVS.draper.com>,
SEB1525@MVS.draper.com (Steve Bacher) writes:
> In article <1992Nov20.032345.18307@kodak.kodak.com>,
> deal@tempus.Kodak.Com (Stephen M. Deal) writes:
> >Has anyone given much thought to client authentication on PCs and Macs?
> >Does anyone have any thoughts on how a server (DB  or otherwise) would
> >handle such a mechanism?
> 
> You may want to look at RFC 931, "Authentication server", which
> proposes a protocol for user authentication from remote clients.

Not for PCs and Macs he doesn't.  RFC931 only works with reasonably
trusted hosts; with PC class machines that are trivially subverted,
RFC931 is useless as an authentication protocol.  See the CAVEATS
sections of RFC931:

CAVEATS

   Unfortunately, the trustworthiness of the various host systems that
   might implement an authentication server will vary quite a bit.  It
   is up to the various applications that will use the server to
   determine the amount of trust they will place in the returned
   information.  It may be appropriate in some cases restrict the use of
   the server to within a locally controlled subnet.

For reliable client authentication on untrustworthy hosts, you really
need something like Kerberos.

-- 
-Dan Riley                          Internet: dsr@lns598.tn.cornell.edu
-Wilson Lab, Cornell University     HEPNET/SPAN: lns598::dsr (44630::dsr)
From: pan@sunvax.sun.ac.za
Newsgroups: comp.client-server
Subject: Graphical Client-Server
Date: 20 Nov 92 16:20:45 GMT
Organization: University of Stellenbosch

I am currently writing an article that investigates relational databases and
graphical front ends to relational databases.

In the process I have stumbled across the client-server model as one mode of
implementing such an configuration.

Does any specification for translating an SQL view into a graph, gantt chart,
organigram or any other graphical representation exist?

I would appreciate it if anyone can help me with this.

Abrie Nel
Institute for Industrial Engineering
University of Stellenbosch
Stellenbosch
7600
South Africa

"Semper ex Africa Liquid" (always something new out of Africa)
Organization: The American University - University Computing Center
Date: Thu, 19 Nov 1992 14:05:31 EST
From: Kayvon Z. Sadeghi <KSADEGH@auvm.american.edu>
Newsgroups: comp.client-server
Subject: Re: SQL and Client-server architecture
 <1992Nov17.160748.5948@cbnewsl.cb.att.com> <paul.722141311@suite.sw.oz.au>

In article <paul.722141311@suite.sw.oz.au>, paul@suite.sw.oz.au (Paul Antoine)
says:
>
>In <1992Nov17.160748.5948@cbnewsl.cb.att.com> sdo@cbnewsl.cb.att.com
>(scott.orshan) writes:
>
>>In article <92316.105420KSADEGH@auvm.american.edu> Kayvon Z. Sadeghi
><KSADEGH@auvm.american.edu> writes:
>>>I was wondering why all the client/server systems use SQL as their
>manipulation
>>>language. I don't recall seeing any client/server that works on OO or
>>>hierarchy, for example. Is this because its easier to implement             s
>client/server
>>>in SQL or is there any especial reason.
>
>>I'm not sure why you say that all client/server systems use SQL.
>>Perhaps all client/server SQL database systems use SQL (a tautology),
>>but some databases don't, and non-database client/server packages
>>probably have no need to use SQL.
>
>>For example, plain RPCs and TP Monitor C/S calls pass arbitrary information
>>between clients and servers.  Most client/server access is probably
>>just remote file access, and that has nothing to do with SQL.
>
>And I'd even dispute that most C/S access is not remote file access (as in
>our C/S system that talks to 3270-based applications).  The TP monitor is
>used to route the data, and is aware of the type and number of servers and
>where they're running, but there's no restriction on the data (i.e. it
>needn't be SQL!).
>
>The confusion probably arises because most C/S systems are used to more
>efficiently access corporate data - but this needn't be in the form of
>direct database access.  A lot of it can also be done through existing
>applications (as in our case).  It just goes to show that getting consensus
>on the eternal question 'what is C/S?' is well nigh impossible,
>
>Regards,
>Paul (a Tuxedo fan)
>
>------------------------------------------------------------------------------
>Paul Antoine, Softway Pty Ltd                       Net: paul@suite.sw.oz.au
>PO Box 305, Strawberry Hills, NSW 2012, Australia   Tel: +61 2 698 2322
>79 Myrtle St, Chippendale, NSW 2008, Australia      Fax: +61 2 699 9174
>------------------------------------------------------------------------------


Perhapse I didn't clear myself, at least not good enough. What I meant was
why most of the client/server *data bases* use SQL. My appologies.
I know that some of the client/servers are not data bases, e.g. file servers
or printer servers have nothing to do with data base. So, I guess, I
should be more careful in future.


k1
---
------------------------------------------------------------------------
PUSH, if that doesn't work
PULL, if that doesn't work
we're probably CLOSED
------------------------------------------------------------------------
Kayvon Sadeghi                    k.sadeghi@ieee.org
Voice:202/244-0789
Newsgroups: comp.client-server
From: mpiet@is.morgan.com (Mark Pietrasanta)
Subject: Is Client-Server dead?
Organization: Morgan Stanley - IS
Date: Tue, 17 Nov 1992 16:16:56 GMT

Okay.  I'll ask it.  Is Client-Server going down the tubes in
favor of peer-to-peer?

Are networks like Novell, Banyan, etc. that rely on the logical
star of client-server a thing of the past now that Unix and
Microsoft's Windows for Workgroups and Windows NT are on the
horizon?

It would seem that business is more suited to a peer-to-peer
environment, although IS typically isn't.  How do we IS'ers
maintain our role (or any role) as the business units start to
welcome the new peer philosophy?  Especially if they embrace
Microsoft's solutions, which will mean they can support and
develop with minimal man-hours and without IS?

Looking for input...

Mark Pietrasanta - mpiet@is.morgan.com
* * * * * * * * *

"Great spirits have always encountered violent opposition from
mediocre minds." - Albert Einstein

----------------------------------------------------------------
Disclaimer: These responses are my own and in no way reflect the
            views of my employer.
----------------------------------------------------------------
Newsgroups: comp.client-server
From: SEB1525@MVS.draper.com (Steve Bacher)
Subject: Re: Authentication of Clients in a C/S environment
Organization: Draper Laboratory
Date: Sun, 22 Nov 1992 22:51:00 GMT

In article <1992Nov20.032345.18307@kodak.kodak.com>,
deal@tempus.Kodak.Com (Stephen M. Deal) writes:

>One major implication of distributed processing (of which C/S is but one
>manifestation) is that of authentication.
...
>How do you authorize a client? Can you even trust a client? Perhaps
>those clients executing on a node that has password protection (e.g.
>UNIX, VAX/VMS) can be trusted but what about single tasking nodes that
>run a Disk Operating System (a.k.a. DOS)?
...
>Kerberos (from MIT's Project Athena) provides a glimmer of hope but I
>have not seen any C/S vendor embrace this approach.
...
>Has anyone given much thought to client authentication on PCs and Macs?
>Does anyone have any thoughts on how a server (DB  or otherwise) would
>handle such a mechanism?

You may want to look at RFC 931, "Authentication server", which
proposes a protocol for user authentication from remote clients.

RFC's (Requests for Comments) are available from nic.ddn.nil
via anonymous ftp.  You may be able to locate it elsewhere as well.
If you can't locate it, I can email a copy to you.

--
Steve Bacher (Batchman)                 Draper Laboratory
Internet: seb@draper.com                Cambridge, MA, USA
Newsgroups: comp.client-server
From: wright@hsi.com (Gary Wright)
Subject: Re: Is Client-Server dead?
Organization: 3M Health Information Systems, Wallingford CT
Date: Wed, 18 Nov 1992 13:36:25 GMT

In article <1992Nov17.111656@is.morgan.com> 
mpiet@is.morgan.com (Mark Pietrasanta) writes:
>How do we IS'ers
>maintain our role (or any role) as the business units start to
>welcome the new peer philosophy?  Especially if they embrace
>Microsoft's solutions, which will mean they can support and
>develop with minimal man-hours and without IS?

A rose by any other name ...

I always laugh when I see someone claim that client/server, PC's/
peer-peer etc. systems can be supported and developed without IS.

Now I would tend to agree that traditional IS groups may have
trouble with this but certainly the skills required to design,
install, support, etc a complex heterogeneous LAN environment 
are the same skills required to run a large central computer center.
The details change, but the concepts are much the same.

In fact in some ways is harder to administer to the needs of a 
distributed PC based environment.  Just think about making reliable
backups for all those PCs.

What needs to happen is that the IS group must change its structure
and the services it offers so that the smaller groups within your
organization can rely on you to continue to manage their systems.
Why should each of these smaller groups being hiring (or drafting)
PC and network experts?  Usually they take what they can get from
there existing staff instead of hiring a skilled/trained person.
-- 
Gary Wright                                                 ...!uunet!hsi!wright
3M Health Information Systems                                     wright@hsi.com
Newsgroups: comp.client-server
From: wright@hsi.com (Gary Wright)
Subject: Re: Is Client-Server dead?
Organization: 3M Health Information Systems, Wallingford CT
Date: Wed, 18 Nov 1992 13:44:08 GMT

In article <1992Nov18.050812.20252@netcom.com> nagle@netcom.com 
(John Nagle) writes:

>       The main purpose of client-server systems is isolation of the
>manipulation of important data from the (probably graphical) user
>interface.  

Why do we have to perpetuate the abuse of the "client-server" term?
Client-server is an abstract concept with many concrete implementations.

To claim that the computation/display relationship between two pieces
of software is a special or primary meaning of "client-server" is to
make that term less descriptive.  What do I call two computational
systems that communicate in a request/reply manner if the term
client-server has been redefined to mean Microsoft Windows and SQL Server?

Certainly NFS is based on a client-server concept but there is no
display software at all in that system.
-- 
Gary Wright                                                 ...!uunet!hsi!wright
3M Health Information Systems                                     wright@hsi.com
Newsgroups: comp.client-server
From: sdo@cbnewsl.cb.att.com (scott.orshan)
Subject: Re: SQL and Client-server architecture
Organization: UNIX System Laboratories
Date: Tue, 17 Nov 1992 16:07:48 GMT

In article <92316.105420KSADEGH@auvm.american.edu> Kayvon Z. Sadeghi <KSADEGH@auvm.american.edu> writes:
>Hi out there
>
>I was wondering why all the client/server systems use SQL as their manipulation
>language. I don't recall seeing any client/server that works on OO or
>hierarchy, for example. Is this because its easier to implement client/servers
>in SQL or is there any especial reason.
>
>I would appreciate if someone could give me some pointers on this.
>------------------------------------------------------------------------
>Kayvon Sadeghi                    k.sadeghi@ieee.org
>Voice:202/244-0789

I'm not sure why you say that all client/server systems use SQL.
Perhaps all client/server SQL database systems use SQL (a tautology),
but some databases don't, and non-database client/server packages
probably have no need to use SQL.

For example, plain RPCs and TP Monitor C/S calls pass arbitrary information
between clients and servers.  Most client/server access is probably
just remote file access, and that has nothing to do with SQL.

Even C/S SQL databases don't always pass SQL.  If a stored procedure is
being invoked, then the message need only include the name of the
procedure.

	Scott Orshan
	TUXEDO Support
	UNIX System Laboratories
	908-522-5063
	sdo@usl.com
From: silverm@bcstec.ca.boeing.com (Jeff Silverman)
Newsgroups: comp.client-server
Subject: Re: Is Client-Server dead?
Date: 19 Nov 92 06:03:12 GMT
Organization: Boeing Computer Services, Seattle

nagle@netcom.com (John Nagle) writes:

>mpiet@is.morgan.com (Mark Pietrasanta) writes:
>>Okay.  I'll ask it.  Is Client-Server going down the tubes in
>>favor of peer-to-peer?

>       The main purpose of client-server systems is isolation of the
>manipulation of important data from the (probably graphical) user
>interface.  Whether both reside on the same machine is not the central issue.
>GUI-based applications tend to be mostly user interface in terms
>of code volume, and breaking up the program into a user-friendly
>client and a server whose users are programs seems to be a good
>division of labor.


I think that client-server is the wave of the future.  The future that I
see is that the computer will be a network of machines.  Some of the machines
will be clients, some machines will be servers and some machines will be both.
The future I envision has a disk machine, which has a lot of online storage
connected to a fast but otherwise pretty minimal CPU (NFS).  There is a compute
server, a computer which has been optimized to have a fast, powerful computer
and lots and lots of RAM.  There are terminals connected to terminal servers,
terminals which are servers (X-terminals).  Security is maintained by a
security server (Kerberos).  Time is provided by a time server.  Now, the
machines can take on different roles at different microseconds.  For example,
the compute server is a client of the file server, but it is a server to
a general purpose computer.  The file server is obviously a server to lots of
clients, but less obvious is that it is a client of the security server and
the time server (Kerberos requires time synchronization).

I think if you look carefully at the new offerings, you will see that deep
down inside they are still client server based!  

Jeff Silverman, Boeing.
Newsgroups: comp.client-server