> 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.
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.