I can readily understand the needs of the VNC developers to focus on the
'core functionality', especially for an application ported to so many
different platforms. But I think it would be a mistake to dismiss this as
an issue of user ignorance or laziness.
Point #1:
I use VNC for a variety of purposes, and I very often find it necessary to
bring back a file. Sometimes because we're using VNC for support
(trouble-shooting) purposes and we need to bring back diagnostic
information. Sometimes we generate printed output and we want to bring the
spoolfile back to print it locally. I suspect that for every situation in
which remote control is useful, one finds a directly related need to
transfer files. And I mean the file transfer need arises directly out of
the work being done in a remote control session.
Point #2:
There are a variety of obstacles to performing the file transfer using a
separate tool:
1) the FTP ports are not open on an intermediate firewall (for good reason!)
2) the FTP service is not running on the server (for good reason!)
3) the client system does not have an FTP client installed (remember, the
vncviewer is often installed by placing a single executable on the client;
installing an FTP client is not nearly as simple).
I wonder... whether it is possible to implement file transfer in such a way
that it also delivers remote printing. I think the two requirements have
significant overlap.
-Lee Allen
----- Original Message -----
From: Morris, Steve <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, March 13, 2001 7:15 AM
Subject: RE: FTP Server
> I guess we all know the issues here. What we don't have is a good answer.
> The VNC team has decided to bound the development process by keeping to
the
> core functionality, correctly reasoning that things like file transfer,
> secure connection and local printing of remote files are all solved
> elsewhere.
>
> Unfortunately this leaves the end user with a bundle of requirements that
> have to be solved piecemeal. This creates a barrier to entry that leaves
out
> the less sophisticated user without the benefit of sysadmin support.
>
> In other contexts a third party sometimes steps in to provide an
> integration/packaging function. Consider RedHats relationship to Linus
> Torvold's Linux Kernel. The Linux kernel is practically useless without
the
> rest of the package.
>
> Imagine if someone were to make a windows package which included VNC, a
SSH
> client and an FTP client, along with a common configuration procedure. I
> think this would be quite popular and adequately address Steve Bostedor's
> and many other posters issues.
>
> This is the key conflict. Many end users (especially non UXIX users) need
a
> more inclusive package than a raw VNC and there is no one willing to
provide
> the packaging/integration service that most end users are not
sophisticated
> enough to handle themselves. This leads end users to request the
additional
> features as enhancements to VNC, thus this perennially reoccurring thread.
>
> > -----Original Message-----
> > From: Steve Bostedor [mailto:[EMAIL PROTECTED]]
> ... parts clipped ...
> > Why run twenty
> > programs to accomplish something that you should be able to
> > do with one?
> > Isn't the point of technology to make things easier and more
> > efficient?
>
> This is a clash of cultures issue. It is the UNIX way to make independent
> tools that can be mixed and matched to provide a broader range of user
> selectable functionality. "One package does everything" is the Microsoft
way
> towards monopoly control and to stifle innovation. Consider the lowly
> grammar checker. Microsoft bought one 10 years ago and embedded it in
Word.
> As a result the grammar checker is just as limited as it was 10 years ago.
> Microsoft has no financial incentive to enhance it and no one else can
make
> money competing with something Microsoft gives you for free. Using the
> Linux example imagine if we tried to integrate the gcc compiler directly
> into the Linux Kernal or the web browser directly into X11.
>
> Breaking out development on clean functional lines leads to faster
> functional growth. In this the VNC team is totally correct. However
> integration is a important and valuable function. Who will be the
integrator
> for remote Windows access with VNC at the center if the att team will not
do
> it? I think the answer is no one, which means that VNC will be forever at
a
> disadvantage competing against the commercial packages which handle the
> integration. VNC will remain a tool for the sophisticated user.
> ---------------------------------------------------------------------
> 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
> ---------------------------------------------------------------------
---------------------------------------------------------------------
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
---------------------------------------------------------------------
