> 1. From the macroeconomic point of view, there is little
> demand for such a
> package and we're only hearing the vocal few;
>
> 2. The few "end users (especially non UNIX users)" who are
> in the know how
> to set up such an environemnt are not sharing their
> knowledge effectively
> or at all with the "many end users (especially non UNIX
> users) who need a
> more inclusive package that a raw VNC."
I can only speak from personal experience and the experience of the few
people I have turned on to VNC. I think we fall in between 1. and 2. Some of
us stumble and fumble and eventually figure out ssh. Our knowledge is not
adequate to help anyone else since we barely have it working. We give up on
file transfer and remote printing because we have exhausted our limited
abilities. We just wish we could figure it out but instead work less
effectively.
The others never figure it out and give up thus never being in a position to
post requests to this list.
In a more perfect world ssh and scp would be available as libraries which
could be integrated into VNC and other packages much like regular expression
libraries are independently developed and then included in packages like
Python and Tcl; or the gnu readline package; or compression libraries; or
graphics file format libraries. This would solve the independent development
issues. The only thing VNC would need to do is provide the hooks somewhere
close to the transport layer. Such an API could then support other transport
mechanisms including tose not based on TCP/IP. This would allow tight
integration of secure transport without expanding the development effort to
include secure transport.
---------------------------------------------------------------------
To unsubscribe, send a message with the line: unsubscribe vnc-list
to [EMAIL PROTECTED]
See also: http://www.uk.research.att.com/vnc/intouch.html
---------------------------------------------------------------------
