> From: "Martin Djernaes" <[EMAIL PROTECTED]>
> ...
> > There is no magic. Users have been demanding the impossible from SMTP
> > on the grounds that they don't understand why not for decades. ...
> As long as the fact is that it takes 15 seconds in average and the
> reliability is 99 or more % I will not blame the user for expecting this
> functionality from such a service. Our job is to not to tell the user,
> that what he do is wrong but to make the service usable ...
Those of us with engineering pretensions don't try to offer the impossible
or the undesirable. If you go to a gravel pit with your light duty
pickup truck and ask 3 tons of gravel, the operators will be extremely
reluctant. They know that you'll blame them for the consequences.
> > It's actually worse than that. Instead of demanding a way to move large
> > files, they demand a way to move large email messages, and they cannot
> > understand the distinction.
> I do not think so - if we could make a transparent way of sending large
> files, the user would not care if it is a mail or something else.
Well, based on having been around for a long time (I met the net in ~1971),
I do think so. Even when people have perfectly good FTP areas available,
they still try email first. Even worse, unless you impose limits on file
sizes on FTP areas, those who will use FTP (usually after trying email
and hitting administrative limits) don't stop to think. They'll try to
send 600 MByte files over 56K links instead of doing the obvious
computation and realizing that a CDROM would be quicker.
Once you point out the obvious computation, only the hopelessly
pointy-haired are huffy.
> There is just one fact which is in the way for any other solution - as
> long as the user have a way of sending his/hers files, and it actually
> works (I mean he/she have a program which make the way of doing it
> transparent to him/her, and the file get to the desired destination
> within a reasonably short time) there is not reason seen from the point
> of the user to get another service.
We disagree. But I also think that no one should be allowed a driver's
license without passing a test that includes changing a tire and checking
a spark plug. It is impossible to hide the difference between an external
path involving T1's and an internal path involving 100 Mbit/sec and 1000
Mbit/sec LAN's.
> ...
> > There are scaling problems. Consider how many disk drives an ISP would
> ...
> The size issue is there what ever (relay-)service we use! We can try to
> prevent the usage being to big (why make a BASE64 encoding when we can
> store it binary etc.).
The scaling problem I meant exists only if you insist on a relay-service.
The reasons why FTP and SMTP are of similar ages are still compelling.
> > Didn't I see mention of something called an "external body"? That notion
> ...
> :-) But please tell me which "usable" programs support this function,
> and what kind of providers offers this service.
That sounds like a coding opportunity.
The common FTP implementations also need to be enhanced to support the new
encryption options.
> I have to say that I consider the problem seen from the "dummy" users
> point of view - he/she have to see the same function from his/hers work
> place as well as from his/hers home computer (PC? mac?). I guess
> everybody here would be able to open a ftp server in case of "an extreme
> big file", but I am not sure that mr. Normal User will be able to do
> this, and more he will not wait for the receiver to go online to pick it
> up.
Instead of assuming people are stupid and pandering to their laziness,
why not educate them? When you buy a light duty pickup truck, you
are bombarded with its load limits.
Vernon Schryver [EMAIL PROTECTED]
