Re: why should email v's ftp? (was Re: What DO you lose with Linux ???)
> Well...yes, it has gotten out of hand - but really, why waste it?
And don't forget the entertainment value :)
<snip>
>
> 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.
Don't we still have the spooling problem unless you can co-ordinate sender
and receiver to be on line in different time zones in different parts of
the world simultaneously.
Although, thinking about it, maybe we assume that people who use this
programme have diald installed and we could include in the email
a message to the effect that "file transfer will take place at
GMT +xxx hrs unless otherwise cancelled". If the transfer is cancelled
by the receiver then a message to that effect is emailed to the sender.
A scheduler, written as part of this new programme, would then make the ISP
connection, interrogate the receiver ("are you ready ?" type message), if
!ready then try again every 5 minutes to a maximum of x (sender specified)
attempts and then send the file. Of course, the scheduler on the receiving
end would have to know it is the receiver and make the ISP connection at
the appropriate time.
Sounds like a fantastic project - count me in and put me on the dftp
(_D_ebian _F_ile _T_ransfer _P_rotocol) mailing list.
Ivan.
Reply to: