"- - Pierre" <ca****@canada.com> wrote in message
news:25**************************@posting.google.c om...
Hi all,
I'm trying to come up with a script and I'm having a heck of a time...
I require users to enter the size (in MB or KB) of the attachment they
wish to transfer/upload. As they enter the number and move over to
the next field (using onBlur or...), I would like a popup/alert window
warning them that this attachment size would take "x" amount of time
based on a speed of 24 kilobits per second (kbps). If they are happy
with the amount of time, I wish to allow them to click OK (to carry on
with the transfer) or Cancel/No to cancel it.
Anyone can assist me on this? I find this is quite difficult and
would appreciate any assistance you could send my way.
Cheers
--P
I don't have an answer for you - but I do know that pending the type of file
you want to download/upload, the results can differ - For example, a 500kb
txt file will transfer faster than a 500kb mp3, rm, jpg, gif or whatever
else type file.
This variation is not just due to filetype, but is in part related to the
browser and web server - I was told this (here) when working on streaming
media - I wanted to calculate the best streaming file to suggest to the
client pending their internet connection - and I thought I could do this by
timing a download of a small file.
I was told that because some browsers (and web surfers) support a
compression in tranzip similar to gzip that one might find on a unix/linux
box. Web Clients have headers that tell the web server what it is capable
of - If the web server is configured to compress it will do so automatically
for every web client that can support compression and some files (like
mp3/jpg/gif/streaming) have files that are already compressed and thus
further compression won't make much of a difference - whereas an html or txt
file will compress very well.
So - you can only guess the transfer times - but even then, some guesses can
vary tremendously - Also, when you think of it, if the web client is
reasonably modern and receiving a compressed file - it uncompresses it
automatically without user intervention and this requires client/computer
resources - which in itself can effect the 'download' time (ie the "save as"
dialog box will not have closed/completed until the full download has
finished.
So... I hope that gives you a rough idea - if you still want to give it a
try I'm sure someone here will offer some solution that might help in some
shape or form...
randell d.