NetNews Usenet Archive 1992 #19/NN_1992_19.iso/spool/comp/os/mswindo/programm/win32/811

Text File | 1992-09-03 | 3.9 KB | 72 lines

Newsgroups: comp.os.ms-windows.programmer.win32
Path: sparky!uunet!news.mentorg.com!mentorg.com!pbrooks
From: [e-mail] (Phil Brooks)
Subject: Re: Looking for rshd, telnetd, ftpd etc.
Sender: [e-mail] (News User)
Message-ID: <[e-mail]>
Date: Thu, 03 Sep 1992 20:21:28 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Nntp-Posting-Host: decoy.mentorg.com
Organization: Mentor Graphics Corporation
Keywords:
Followup-To:
Lines: 57

In article <[e-mail]>, [e-mail] (Michael Winser) writes:

Regarding remote builds:
|> Why do you need remote login in the classic unix sense?  Setup a make (or
|> compile server) that uses RPC or named pipes.  The server side whould use
|> the client impersonation API to get an ACE (access control entry).  No login
|> required.
Now you add a layer of complication.  What is the use for this?  I have to write
my own RPC clients.  RPC's aren't trivial things to use or work with.  I have to
worry about security as well if I have dozens of RPC interfaces available which
can all impersonate other other users.  All of this theory about RPC's is great,
but point me at an existing remote Make server.  Even if you find one by early
next year I will be quite suprised.  Then that is only good form make.  I can't
use it to distribute another task that I come up with tomorrow.  The RPC solution
is not really general unless you write RPC for a living.

Regarding Remote Server startup:
|> Once again, why stick with the unix model?  Services are explicitly supported
|> by Windows NT.  When started they take on the ACE of the user that installed
|> them.  No login required.  I'm pretty sure that you can start these services
|> via RPC.  It would be trivial to write a start server daemon (for RPC, telnet
|> or whatever).
Long lived daemons are not trivial to write.  Especially when they are
impersonating other users.  Besides, I am back to rolling my own complex
software tools to get trivial tasks done.

Regarding Modem access:
|> OK, you got me.  For this you're gonna need to "login" ie create an ACE (unless
|> you use LANMAN RAS from home :-)  To do that you'll need to write a subsystem
|> that can call upon the Security Manager (not a part of the Win32 API).  For now
|> I would write a service that does callbacks only to your registered number.
Here I go writing another massive application to accomplish a simple task.  BTW,
there is hardware that does a much better job of handling callbacks than any
program you would care to write.

Regarding large multi-user systems:
|> Hmm, I'll just say that this is not the future as we see it.  Windows clients
|> are the way to go.  Would you be happy with only a dumb terminal on your desk?
This misses the point entirely.  The point is that I shouldn't have to go into
major software development every time I want to do something that involves more
than one computer.  Sure, a distributed make Windows client with little make
servers running on all the machines in the network sounds great.  The problem is
that I don't see one yet and if I have remote login, I can wait a long time
for someone else to write one.  RPC's are not a panacea for network access.
They are complex and difficult to work with.  Remote logins are not difficult
to work with.  It really amazes me that people that try to make computers easy
to work with through wonderfulness GUIs don't blink an eye when suggesting that
everyone go out and start writing RPC clients and servers.

Having a remote login capability doesn't preclude the development of RPC based
windows clients when demand for a particular application is high enough.

--
Phil Brooks, Mentor Graphics Corporation
([e-mail])
8005 SW Boeckman Road
Wilsonville, OR   97070-7777 [phone]