pdoshi01 "at" student.vill.edu
Thu, 12 Mar 1998 18:56:50 +0000
Ryan Kirkpatrick wrote:
> The result as I see it would be this:
> * User connects to the main server on a single, specified port,
> say 5800.
> * The main server asks the client for username and password.
Who runs this "main server"? Does it run all the time, or is it in
inetd.conf? Would this even work? It seems like a lot of renovation,
rather than being "not very detailed" as you suggest. It sounds
interesting, but I'm not sure how feasible it would be. And all of this
for what? I didn't think that VNC had a MS NetMeeting rival in mind.
Meaning, it was developed with the intranet in mind, not the "sharing
with friends" idea.
> * Client sends the server this information.
> * Username / password is verified, and if valid, a Xvnc session
> is started using the next avialable display for that user.
> * The display number is passed back to the client, and the client
> then switches into normal operation mode (the way it currently works),
> automatically connecting to the given X display number on the remote
> Ok, this is not very detailed, and leaves out encryption of
> passwords for transmission, but still should work. If I have missed
> something, or totally missed the boat, please point it out! :)
Yes, I think it does. What about all the options that vncserver can
take? For instance, something as simple as setting the geometry, or are
you proposing that the client has *all* the options built in, including
control over the ~/.vnc/xstartup file from the client? For instance, if
I wanted to run a different window manager on the server, I'd need to
edit the ~/.vnc/xstartup file - this *does* require telnetting in. It
just seems quite complicated to get away from the current
telnet-in-and-start-it without sacrificing all the flexibilities.... so
perhaps not entirely *change* things, but design vnc so that it supports
the current method *and* this (although limited) "friendlier" mode, too.