Re: [RFR] fex package
Giuseppe Iuculano wrote:
> Description: web based service to send very big files
It isn't just a web based service, it's a web service, implemented
as a set of Perl CGI-scripts. (So shouldn't the package have a
"Depends: apache2 | httpd" field?)
Make it a "service for transferring" them (here and below).
> F*EX (Frams' Fast File EXchange) is a service to send big (large, huge, giant)
> files from a user A to a user B, anywhere on the internet.
With a few fossil exceptions, names like this possessivise regularly
with 's: Gus's aunt, Louise's hat, Frams's Fast File EXchange.
The consensus seems to be that Internet takes a capital I.
> .
> The sender uploads the file to the F*EX-server and the recipient automatically
> gets a notification e-mail with a download-URL.
> .
> Main features of F*EX
^:
> .
> * file transfer of virtually unlimited file size
(Even if my web server has a 1GB hard drive? Since when has there
been a file size limit for SMTP, anyway? And does this F*EX
transfer really go over the net uncompressed and unencrypted?)
> * recepient and sender only need an e-mail program and a web browser - of any
recipient
> kind, they do not have to install any software
^
Comma splice; I'd reorganise it into something like:
* sender and recipient only need an e-mail program and a web browser
(of any kind; they do not have to install any software)
> * RESEND and REGET for resuming after link failures at last sent byte
> * auto-notification of recipient
> * auto-deletion after download
> * auto-deletion after expiration date (default: 5 days)
> * full-users can create sub-users, who can send only to this full-user
> * maintenance-free: no admin interaction necessary besides creating new F*EX
> accounts
Wait, what's all this about needing to interact with the server's
admin? If installing this package gives me a F*EX server, doesn't
that mean _I_ am the admin? So from my point of view it's:
* maintenance-free: no administration necessary beyond creating new
F*EX accounts
> * Sending to multiple recipients needs storage on the server only once
sending
"Once" doesn't eliminate the possibility of "several at once".
* multiple recipients only require one stored copy
(Isn't this self-evident from the whole upload/download mechanic?)
> * F*EX is a HTTP web-service and needs no firewall-tunnels
is an HTTP service firewall tunnels
or just uses HTTP
(In which case you may find that the recipient's workplace blocks
access to the URL.)
> * support for streams, too (SEX : Stream EXchange)
^
That word belongs right up next to the colon.
> * for real UNIX users, there are the shell programs fexsend and fexget to
> avoid annoying web browser usage
In these days of MacOS X, "real UNIX" user != shell user. Say:
* shell clients provided for commandline users: fexsend and fexget.
(I need to install the server to get these clients?)
So that's:
Description: web service for transferring very large files
F*EX (Frams's Fast File EXchange) is a service for transferring big (large,
huge, giant) files from a user A to a user B, anywhere on the Internet.
.
The sender uploads the file to the F*EX-server and the recipient
automatically gets a notification e-mail with a download-URL.
.
Main features of F*EX:
.
* file transfer of virtually unlimited file size
* sender and recipient only need an e-mail program and a web browser
(of any kind; they do not have to install any software)
* RESEND and REGET for resuming after link failures at last sent byte
* auto-notification of recipient
* auto-deletion after download
* auto-deletion after expiration date (default: 5 days)
* full-users can create sub-users, who can send only to this full-user
* maintenance-free: no administration necessary beyond creating new
F*EX accounts
* multiple recipients only require one stored copy
* F*EX uses HTTP and needs no firewall tunnels
* support for streams, too (SEX: Stream EXchange)
* shell clients provided for commandline users: fexsend and fexget.
--
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
Reply to: