> > This new alpha release fixes problems of swf parsing,
> > bogus download progress infos, remaining .delayed files
> > not handled correctly, and adds two new external
> > callbacks (check-mime and save-file2) to be notified 
> > when a file is going to be written and/or modified 
> > and/or untouched.
> 
> > Please report any unexpected behaviour, especially
> > crashes, broken mirrors, files taken by error 
> > (or missing files), and so on..
> 
> Nice and good, except the subject of speed.

Have you realized that some options are now limited 
by default ?
You have to use "-%!" to be able to override these
limits and then specify the values that you want to
increase, eg, -A (transfer rate), -%cN (conns/sec)
and -cN (# of multiple connections)

See you.

> We test HTTrack on our own servers and, like
> most Admins, we use the GUI mainly because it is more
> convenient, hence, in this way, also faster. With the 
> GUI, you can get even a lay colleague to keep an eye
> on your tests when you have to do other things.
> 
> Besides, we shouldn't forget that speed itself
> is an important factor in the testing of software.
> What's the point of an off-line browser beta if it 
> cannot dare to experiment with speeds of, say, 
> 10 000 kiloByte-Connections per second? The two key
> words are beta and experiment.
> 
> Incidentally, kBC/s or kiloByte-Connections per sec is 
> a bandwidth unit I've thought of. For example, 250 kBC/s 
> is equivalent to 25 kB/s and 10 simultaneous connections
> to a server, 50 kB/s and 5 connections, 250 kB/s and
> 1 connection, and so on. It has been motivated by the
> research we're doing and by the recent exchanges in this
> forum.  And what has this got to do with the testing of
> HTTrack?> 
> A bit. We believe that the "efficiency" of an off-line 
> browser is measured by the highest value of kBC that it
> can deliver in a given period of time, "all other
> variables being the same". HTTrack still has a problem
> here.