On Thu, Apr 08, 1999 at 12:41:34AM -0500, Steve Beitzel wrote:
> Hey All,
>
> Err...I don't mean to nag or anything, but hasn't this thread
> gotten a little out of hand? I mean, it's like ten days running now, it
> no longer bears any semblence to the subject, and there has been flaming
> and sarcasm left and right. It doesn't do the debian user community any
> good to have many of its good people wrapped up in a pointless thread.
> Just my $0.02.
>
> Steve
>
Well...yes, it has gotten out of hand - but really, why waste it?
In simple summury, we have the following issues for large file transfer:
email: ("the bane of postmasters everywhere")
- inefficient file transfer methods.
- large amounts of space required on possibly numerous servers for spooling.
- difficult for a reciever to choose whether to receive the file or not.
- DOS possibilities.
ftp/http(et al):
- difficult to use, requires a user to know how to use them - to place the
files in appropriate places and to pass correct urls to the files.
- often not an available alternative due to ISP restrictions.
- lack of security (ok, email isn't secure either - but _far_ less people
have the technical skills + access to snoop email transfer).
So far these are the only protocols mentioned for transfering files between
people over the internet. Both have their problems, thus neither is a good
solution.
Now - I was thinking, what this debian-user lists represents is some of the
best computer programmers in the world mixed with one of the largest user
bases. Surely between ourselves we have the ability to come up with a
"Better Way"? What is really stopping us from developing a better solution
ourselves? These things have to start somewhere...
Here is my first suggestion:
One program I use regularily on linux is sendfile (see the sendfile package
guys). This program is very useful - although it suffers from some of the
same problems as email transfer (the file is transfer is done immediately,
hence spooling is required, DOS possible, etc).
What would be nice is if this program only transfered the file when the
user chooses to "recieve". This would require the file to be spooled on
the senders machine awaiting download - which is a much better solution than
"transfer then spool". A basic algorithm to do this could be:
User requests a file be sent. Their "sendfile server" (either their local
machine or a server that gives them access) will be sent the file and it
will store it somewhere. A ticket is then sent back to the user which
contains a URL (or similar) for the file plus an authentication code, so
that the file can only be downloaded by supplying that code (you could even
add support for a limited timeframe to pervent indefinate file storage).
This ticket is sent to the recipient (possibly with a email message), and
upon receipt the user is given the option to download the file. The
recipient could use information such as the sender and the file size to
choose to a) download the file, b) not download the file (and remove from
the "sendfile server" or c) differ the choice until later.
There is also the possibility to set up automatic download at the client
end if required. It would all be part of the client software.
Chris
--
----------------------------------------------------------------------
The box said "Windows 95, NT or better" .. so I installed Debian Linux
----------------------------------------------------------------------
Reply with subject 'request key' for PGP public key. KeyID 0xA9E087D5
Attachment:
pgptfLcZ8XS8m.pgp
Description: PGP signature