> ] From: "Martin Djernaes" <[EMAIL PROTECTED]>
>
> ] I know that the internet were not build for "general use", but it is the
> ] life of the net today, at it should be the goal for the people
> ] implementing it (us?). Let us get away from the idea that it should
> ] always be used the way we implemented it and change our view to how
> ] would the user like to use it.
>
> There is no magic. Users have been demanding the impossible from SMTP
> on the grounds that they don't understand why not for decades. The same
> people who wouldn't try to load 10 ton of gravel in the back of their
> light duty pickup truck expect email to be 99.9999% reliable, have
> end-to-end delays of less than 15 seconds 99.9999% of the time, and to
> move arbitrarily large files in at most 15 seconds. Just because people
> want something does not mean that it is possible or even desirable.
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 (I guess that
were the reason someone invented MIME in the first place). Personally I
would love another solution than encoding you files into a mail (it
actual get a size increase of 33%).
> 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.
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.
> ] If the user would like to transfer 28 MB we should make it possible
> ] (there is always somebody who is in front of the big group, so I do not
> ] say that just because one person wants it we have to make it possible).
>
> 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.).
> ] If the mail service from today isn't the right solution, we should
> ] invent a better. If all providers would allow a user to place XX MB via
> ] FTP on a server, ...
>
> Didn't I see mention of something called an "external body"? That notion
> avoids the scaling problems of requiring that all spool directories and
> all destination mail directories be large enough when many people decide
> to forward a 28 MByte Good Times virus.
:-) But please tell me which "usable" programs support this function,
and what kind of providers offers this service.
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.
--
Regards,
Martin Djernæs
--------------------------------------------------------------
Martin Djernæs [EMAIL PROTECTED]
Dipl.-Ing.
Alcatel Kommunikations-Elektronik GmbH Tel:+49 (0511) 6747 741
Postfach 3246 Fax:+49 (0511) 6747 777
30032 Hannover, Germany http://www.ke-online.de
--------------------------------------------------------------
