AltME groups: search

It's just one partition. The problem is that I can't mount it, as 
the file-structure is damaged. I tried to extract meaningful file 
parts but no luck. I already spent to much time on it. We throw it 
away as we have the data locally and now need to find a way how to 
restore our AltMe content.

IIRC there exists a command different from FIND that will print all 
absolut file locations for a given filename. Any idea?

If the Unity launcher (at least I think that's how the launchbar 
in the netbook thing is called) still uses .desktop files, it's probably 
only a matter of finding the associated .desktop file and modifying 
it to use Terminal=true

To clarify the 'font issue' a bit:

In REBOL2 there are two different 'font engines':
engine1:  is used when you set face/text field
engine2:  is used when you use face/effect: [draw [text "..."]]


On Windows both engines use the same OS functions for the font handling. 
Therefore no differencies are seen at the script level. 


On Linux the Engine1 us using some X-windows api and the Engine2 
is using FreeType2 library. 

The X-windows font api doesn't support antialiasing and the font 
output in general is not so nice (depending on the distro).

The FreeType2 lib has better font quality output and also supports 
antialiasing but you have to know the full-path to the font file.


Currently noone suggested any efficient method how to get the 'font 
path' in unified way (considering the 'mess' between different Linux 
distros). 

When I tried to investigate a bit someone pointed me to the FontConfig 
lib that should take care of this problem on Linux. But:

1. I don'r know if the fontconfig is really widely supported and 
what other 'framewrorks' are possible on the rest of distros that 
don't have fontconfig...

2. I don't know how easy/hard is to get the info from fontconfig, 
havent studied it

3. as I said I'm not using Linux for desktop stuff so it is nto my 
high-priority item.


Another solution is to intorduce something like global font-path 
in the Rebol system object which would be used for the font lookup. 
This variable could be set individually by user or author of the 
rebol program. We could also provide some font-name/type->font-file 
matching table but that would take some research as well and won't 
work for all setups. But at least something.


So If anyone here from the 'Linux power users' group knows a good 
solution or even propose a prototype of the solution I believe Carl 
will be glad for your help.

When you install the rebol.deb file, it autamtically install xfonts 
packages, then you need to reboot the PC

Just reboot? Ok, I was trying with a CD-Live so I have never restarted 
after installing the rebol.deb file.  I'll try it tomorow with a 
installed Kubuntu 11.04 and I'll post any new. Thank you for your 
help.

@DocKimbel: Thanks! There is a README file in the /etc/rc3.d/ directory 
that indicates to rename the file to a Knnapache2. I'll do it and 
see what blows up. :))

A report about my adventures:

sudo aptitude install libxaw7 libxmu6
[sudo] password for gouslar: 

0 packages installed, updated or deleted. 0 bytes of archives received.
Ok
sudo aptitude search libxaw7 libxmu6

i A libxaw7                         - X11 Athena Widget library  
               

p   libxaw7-dbg                     - X11 Athena Widget library (debug 
package) 

p   libxaw7-dev                     - X11 Athena Widget library (development 
hea

i A libxmu6                         - X11 miscellaneous utility library 
        

p   libxmu6-dbg                     - X11 miscellaneous utility library 
(debug p
Ok
sudo ldconfig
Ok
ldd 042/altme 
...
	libXaw7.so.7 => not found
	libXmu.so.6 => not found
...
Ok
ls /usr/lib/i386-linux-gnu/libXmu*
No such file(s).
Ok
ls /usr/lib/i386-linux-gnu/libXaw*
No such file(s).
Ok

Then, I installed rebol-2.7.8.4.3-4.amd64.deb from maxvessi.net.

(GTK-DEBI installer was saying to 47 additional packages, then it 
hung before downloaded anything. I killed some processes it created. 
Then I re-ran gdebi, it said all dependencies of 'rebol' are satisfied 
and installed 'rebol' quickly.)

Then, I re-ran:

ldd 042/altme 
...
	libXaw7.so.7 => not found
	libXmu.so.6 => /usr/lib32/libXmu.so.6 (0xf75c3000)
...
Ok
sudo aptitude install libXaw7 libxaw7-dbg libxaw7-dev
...it installed 21 new package...
Ok
ldd 042/altme 
...
	libXaw7.so.7 => not found
...
Ok
042/altme 

altme: error while loading shared libraries: libXaw7.so.7: wrong 
ELF class: ELFCLASS64
Ok

Hmm. Was hacking a bit more. I cannot get ldconfig to be sane and 
include all file names into its cache, tried all ways it seems.

We don't want this tutorial to get too large, so we decided not to 
include certain features at this time. Some of them may be added 
as part of a future CGI tutorial.

        * User accounts (including user registration)
        * Browser cookies
        * Fancy message formatting
        * Message searching
        * File locking methods


so straight away we don't need file locking methods, browser cookies

Ok.. this seems to work.. kinda.. 

	on-response: func [req params svc][	

  ;-- this callback is useful to mutualize the HTTP response settings.
		
		thetarget: copy req/in/target
		print join "target: " thetarget
			either found? find thetarget "." [
			mimetype: parse thetarget "."
			
			if (last mimetype) = "swf"[
			print "is a flash file"
				req/out/code: 200

    h-store req/out/headers 'Content-Type "application/x-shockwave-flash"
				]
			][
		print "is text/html" 
		req/out/code: 200
		h-store req/out/headers 'Content-Type "text/html"
		]
	]

Worked out the other issue.. Flash requires crossdomain.xml file 
to be delivered up by Cheyenne when running Flash that uses xml.Socket 
(like RASH).
Butt it's working well now.. and very cool. 

Works like this.. I run my local copy of Framewerks with embedded 
Cheyenne server, and park the GUI on any server (always accessible, 
single point of bug fixing etc.) for all to use.. currently it's 
here  http://kommonwealth.com/exper/gui.html


Now, it wont work for you 'cuz you're not running framewerks.. but 
if you were..  you could type into the box "codes" and it would open 
the RASH code file, on your desktop, using your favorite text editor. 
  

But wait.. there's more... 

In my local code.txt file i have the following line

PnG "testing" ][bout: {<pre>ok this works</pre>} makeXML ['DISPLAY 
'MSG "testing works here"]]


So when I open another browser, and point it to http://localhost/
testing  that line is fired (more on all this later).. 

Which does two things.. it outputs "ok this woks" to this second 
localhost page .. BUT (and this is the cool part)

it sends the "testing works here" into the panel on the first kommonwealth 
page. 

In other words, Im able to PUSH data to the remote page at ANY TIME.. 
  this will make for the ultimate in portal pages. 

And.. if that's not enough, Im able to pass messages to the DOM via 
javascript to the kommonwealth page as well. 

Allowing things like sliding in panels.. fading div elements moving 
images.. whatever.


So.. remote page can manipulate my computer.. run apps, do any Rebol, 
reboot .. whatever.. and the local desktop can manipulate a remote 
web page.

Finally.

I spoke too soon.. 

the 0916 version running PHP on windows allows you to read the test.php 
page once.. then each subsequent refresh comes back with a "No input 
file specified." error.

ok.. .spoke too soon again.. the fix was mentioned earlier
path: form to-local-file get-modes req/in/file 'full-path

See the changelog.txt file in the archive for more info.

HOW-TO make Cheyenne work with PHP for non-Windows OS


The purpose of the following patch is to make FastCGI in PHP work 
the same on all OSes.


1) If you have PHP v5.2.1 or higher with sources, you can skip 2) 
& 3) else :

2) Download latest PHP sources from http://www.php.net/downloads.php
3) Untar the archive anywhere yo want
4) Go to PHP install folder
5) Patching PHP source :

	Open a REBOL console, then :

;---- cut'n paste the following code in REBOL's console ----

patch-php: has [buffer pos][
	target: %sapi/cgi/fastcgi.c
	if none? attempt [buffer: read target][
		print "unable to find the file to patch!!"
		exit
	]
	either parse buffer [
		thru "int fcgi_accept_request("
		to "if (req->fd >= 0) {"
		pos: to end
	][
		insert pos "^/^-^-^-^-break;^/^-^-^-^-"
		write target buffer
		print "patch applied."
	][
		print "failed to locate the line to patch!!"
	]
]

patch-php
;---- end of code ----
		
6) Once the patch is applied :

	> ./configure --enable-fastcgi
	> make
	> sudo make install
	
7) Check if everything is ok :

	> php-cgi -h
	...
	you should see a -b option listed meaning you got proper
	FastCGI support.
	
	If it fails (occured on OSX), try with a full path instead :
	
	> /usr/local/bin/php-cgi -h
	

8) Edit Cheyenne's config file (httpd.cfg) to set the correct option 
in the PHP section. Non-Windows users have to also set the new 'delay 
option.

hmm, I have Apache installed on port 80. So I manually changed httpd.r 
port setting in the object section but it did not work. So I tried 
via conf file and now it works. I wonder if directly setting port 
number should work too?

Conf file is ok too, using the 'listen keyword. You should not change 
it directly in the source code (the HTTPd.r port-id value is override 
by the following line in %cheyenne.r : foreach p any [port-id [80]][control/start/only 
'HTTPd p]

The 0.9.17 beta source that I had doesn't have that directory, but 
upon redownloading the file it does. Thanks tor the heads up.

Yes, when asked to run in service mode (-s cmdline switch), Cheyenne.exe 
write the service.dll file in its working directory and then use 
load/library.

Is the service.dll file encapped then? By this I mean stored in the 
exe as binary data and written out when necessary.

Apparently it's not in the main cheyenne.r file, but during a call 
to a sub system (don't know which yet) that causes this.

I think I found the problem in Uniserve:

In uni-engine.r, replacing:

call join form to-local-file system/options/boot [" -s " cmd]

with:

call join form to-local-file system/options/boot [" -sq " cmd]

quiets it down

Sure, It's just a matter of configuration in %httpd.cfg file.

Just remove .r from this line : bind-extern CGI to [.cgi .r], and 
.r file will be served as static files.

Hi guys, there's a tiny issue with Cheyenne running on 2.7.6 due 
to a bug fixed in EXTRACT. To fix it just open %HTTPd.r file and 
find the  following line :

ok.. found it... BUG:  if there is specified other alias type than 
'file ot 'path - Cheyenne halts on uncatched error.

impressed! 8) I finally gave another try at php support in cheyenne 
and after patching fastcgi.c as suggested it now works like a charm.

If you are on os x and use macports, here is a way to patch and compile:

sudo port install php5 +mysql5 +fastcgi
sudo port uninstall php5
cd /opt/local/var/macports/distfiles/php5/
sudo tar -xjf php-5.2.6.tar.bz2
>> run patch below
tar -cjf php-5.2.6.tar.bz2 php-5.2.6
sudo port install php5 +mysql5 +fastcgi checksum.skip=yes

copy of Dockimbel's patch with path fixed for this example

;---- cut'n paste the following code in REBOL's console ----

patch-php: has [buffer pos][ target: %php-5.2.6/sapi/cgi/fastcgi.c 
if none? attempt [buffer: read target][ print "unable to find the 
file to patch!!" exit ] either parse buffer [ thru "int fcgi_accept_request(" 
to "if (req->fd >= 0) {" pos: to end ][ insert pos "^/^-^-^-^-break;^/^-^-^-^-" 
write target buffer print "patch applied." ][ print "failed to locate 
the line to patch!!" ] ]
patch-php ;---- end of code ----

This bench looks a little odd to me. First, how can Yaws supports 
80,000 parallel connections when running on a single server (TCP/IP 
stack limit is at 65535 AFAIK) ? Second, the load is generated by 
sending request byte per byte with a delay of 10s between each bytes 
and getting in response a file of 1 byte...This isn't a web server 
real load test, it just compares the scalability of OS threads vs 
"soft threads". You don't need a benchmark to know which one scales 
better on a mono-CPU server, it's obvious. How Erlang handles multi-core 
CPU ?

Basically it's the part which was showstoper for Rebol plugin - shortly 
it works in a way, that if you want to connect to some site with 
Flash, Flash first loads crossdomain.xml file from the target server 
where must be your domain allowed to access the server domain. If 
it's not allowed, the Flash do not connects at all. It's a basic 
prevention of doing Dos attacks from Flash Player.

Is there anything that would cause Cheyenne to crash? I've not yet 
tracked down the bug, but every time I click a specific link on one 
of my .rsp pages, it just dies and needs to be restarted. Unfortunately 
it's now gone so far that it seems not to want to serve pages anymore 
even though it's running. Under OSX, I get this log output:


Aug 20 23:31:16 Macintosh com.apple.launchd[136] (com.rebol.cheyenne[68207]): 
Stray process with PGID equal to this dead job: PID 68212 PPID 68210 
rebol

Aug 20 23:31:16 Macintosh com.apple.launchd[136] (com.rebol.cheyenne[68207]): 
Stray process with PGID equal to this dead job: PID 68211 PPID 68209 
rebol

Aug 20 23:31:16 Macintosh com.apple.launchd[136] (com.rebol.cheyenne[68207]): 
Stray process with PGID equal to this dead job: PID 68210 PPID 1 
rebol

Aug 20 23:31:16 Macintosh com.apple.launchd[136] (com.rebol.cheyenne[68207]): 
Stray process with PGID equal to this dead job: PID 68209 PPID 1 
rebol


Are there any file permissions, that if set wrong, would cause cheyenne 
to stop serving pages?

I'm not sure to understand what you want to know exactly, so I'll 
start with this : virtual domains are defined in the config file 
%httpd.cfg. See the default config file for syntax examples.

If you want to know how they are handled internally in Cheyenne, 
like any other web server, the virtual domains are extracted from 
the value of HTTP "Host" header, then they are matched against the 
domains defined in the config file. If no one matches, the 'default 
domain in config file is used.

I take a look at the config file.

How about putting the default config file on the website? I haven't 
found it and it would help people to see how things are configured.

The %httpd.cfg config file is in the source archive. If you have 
the Cheyenne binary only, it is wrote down in the same folder the 
first time Cheyenne is started. If you started Cheyenne from Window's 
desktop, Cheyenne will use C:\Documents and Settings\All Users\Application 
Data\Cheyenne\ to store its files.

There is only an RSP.log file, which only contains 4 error objects. 
Should those other log files be in the same directory?

Main changes are :
- an improved PHP support (now works reliably)
- sandboxed RSP webapps (as much as it's possible in R2)
- now compatible with REBOL 2.7.6
- bugfixes

See ChangeLog.txt file in the archive for complete description.

A question about post/put

Here's my little test file

<html><title> RSP PUT test </title>
<%= request/posted
%>
</html>

When I do this with the modified http protocol


page: read/custom http://localhost:8080/put.rsp [ PUT %rebview.exe 
]

I get this

<html><title> RSP PUT test </title>
file=%/D/che19/Cheyenne/incoming/zmmnfoto.tmp

</html>

So, how do I access the file I sent with my PUT ?

PUT file : the tmp file is deleted once the HTTP response is sent 
back to client. If you want to keep the file, you need to either 
rename it (with its original name) or move it elsewhere.

Don't forget also to add the REST module name to the MODULES section 
in %httpd.cfg file.

I want to allow download of the faxes.  I made the file  names links

<a href=showfax.rsp?fax000000.tif>fax000000.tif</a>

and showfax.rsp is 

<%
recvqdir: %/var/spool/hylafax/recvq/
file: dehex request/content/filename

switch suffix? file [
	%.tif [ response/set-header 'Content-type "image/tiff" ]
	%.pdf [ response/set-header 'Content-type "application/pdf" ]
]
response/buffer: read/binary join recvqdir file file
%>

but when the file downloads,it is called showfax.rsp ...

Anyone know how to set the name of the file being downloaded?

<a href=showfax.rsp?file=fax000000.tif>fax000000.tif</a>

Hey Doc, Im using the embed version of Cheyenne, but I can't grab 
any files for downloading.. the dialog box opens, but the content 
is empty.. with this error in the console.. 
target: rockstar.rar

## Error in [uniserve] : On-received call failed with error: make 
object! [
    code: 312
    type: 'script
    id: 'cannot-use
    arg1: 'path
    arg2: 'none!
    arg3: none
    near: [either req/file-info/size > 16384 [
            req/out/content: req/in/file
        ]]
    where: 'handler
] !

Any ideas?

Graham: content-disposition should work, but there may be browsers 
or other clients that ignore it. there is a trick that should always 
work though, but i don't know if Cheyenne supports it: use a url 
like this: showfax.rsp/fax000000.tif?otherargs - you probably won't 
need to put the file name after the ? because most servers (and i 
assume Cheyenne, if this is supported) give you access to the actual 
request path.

Doc, regarding the issue above, I'm not getting the error now, but 
the content is still corrupted? ie: if I read/binary a .zip file, 
set the header to application/x-zip-compressed, the browser is recognizing 
the file size, but the file itself is corrupted? Happens with all 
binary files.

Do you have an example i can use in the embed-demo.r file that returns 
a binary?

I've wrapped up the latest Cheyenne source code, binary and my web 
to fax gateway in on file

one file .. see http://rebol.wik.is/Hylafax

Another local ram-based AtomDB handles user specific data.. and this 
is saved in a rather unique flat file system.

I want to be able to edit my rsp pages remotely, and I've got this 
file here called edit.rsp

<html>
<title>
Editor
</title>
<body>

<%

filename: to-file request/content/filename
if (suffix? filename) <> %.rsp [ quit ]
; if filename = %edit.rsp [ quit ]
either source: select request/content 'source [
	; a http post, so save it
	write filename dehex source
][
	source: read filename
]


val-tag: rejoin [ {<input type="hidden" value="} form filename {" 
name="filename">} ]
replace/all source "<" "&lt;"
replace/all source ">" "&gt;"

print rejoin [
<form method="POST" action="/hylafax/edit.rsp">
<input type="submit" value="Save">
<hr>
<textarea rows="40" cols="140" name="source" > source
</textarea>
val-tag
<p/>
<input type="submit" value="Save">
]
include-file %footer.inc
%>

Look in latest v0.9.19. By default, RSP errors are catched and logged 
in a %rsp-errors.log file in Cheyenne's home directory. It works 
well for RSP webapps, but not really tested yet for standalone RSP 
scripts (there might be some bug/issue in that case).

See the changelog file.

Production vs Debug mode. In Production mode, when an RSP error occurs, 
Cheyenne displays a general error page (or a custom one if defined 
in config file) and logs the error on server.

and tehre is no %rsp-errors.log file in the %Cheyenne directory.

it's not yet exported in config file, but you can change the default 
value in %Cheyenne.r source code.

No, not that bad.  
I had some code like this

do to-file "../../config.r"

when i guess it should have be

do to-rebol-file ".../../config.r"

do to-file "../../config.r" should have worked
and even when I changed it to absolute path
do to-file "/opt/fgw/Cheyenne/config.r"
i still had problems.

I use an absolute path to the config file now

I don't understand why sometimes it would not execute the config 
file using relative paths

Not sure that it can work with the current version. Cheyenne is using 
READ to get static and RSP files,  I have to change that to use the 
virtual file system in memory.

I thought about doing that once, then I found that it requires some 
redesign work first on the virtual file system (%encap-fs.r) and 
also being sure that it won't affect performances when reading files 
from the filesystem in normal usage. I've planned to work on such 
feature for v1.0.

If it's a file saved to the web server as it's too large .. it's 
a string! holding the file name in %incoming/

either string! = type? request/posted)[
		; file name as large post
		f: trim/tail find/tail request/posted "incoming/"
		file: join %../incoming/ f

  write/binary to-rebol-file rejoin  ["faxes/" filename ] read/binary 
  file 
	][
		; binary content

  write/binary to-rebol-file rejoin  ["faxes/" filename ] request/posted
	]

Error 500
Access Error
Cannot open <my file here>
Near do %../../html.r
Where: protected-exec

/posted: thanks for the reminder, that's right, it can be binary! 
or string!. It looks like the file upload support could be cleaner 
and easier to use from RSP. Will give it some thoughts.

/posted caught me ... i keep getting image errors when writing the 
/posted to a file and then trying to view it with img src!

You shouldn't do that. If you want take priority other an existing 
module already declaring it's callback as 'first, you have to put 
your module after the other module in config file (modules section).

What's the purpose of the .cache.efs file  that gets written . I 
think this was the file I saw before that I didn't have writes to 
write to the local filing system

If you can access to the server through rconsole just do this : write 
%debug.log mold uniserve (and put the compressed version of the %debug.log 
file on your web site so I can download it).

Henrik, if you're running cheyenne in source mode, you should use 
the -w command line option (that will allow the generation of a %crash.log 
file if the REBOL error is catched). If your Cheyenne quits, I don't 
think that's caused by a bug inside Cheyenne, but usually by something 
like an uncatched file access error (file handles starvation, file 
access rights,...). Will had some similar issues with Cheyenne on 
OS X, I guess he could help here.

You could put a couple of debug lines around your call/wait and log 
them to a file to see if your CALL always returns.

I thought maybe the file table was too big.

pool-max value should be changed in %cheyenne.r (shared/pool-max: 
any [all [flag? 'debug 0] 8]). Just replace the 8 value by the new 
value. It's not yet exposed in %httpd.cfg file.

It's documented in the Changelog file.

It's straight forward and you should see the default test page. If 
not, check your %httpd.cfg config file. They're no general documentation 
available yet, only RSP API is documented.

You can also choose to run Cheyenne on another port, just look in 
the default %httpd.cfg file and uncomment the LISTEN option in the 
'globals section.

Interesting pattern, I'll try to reproduce that. Strange that you 
can write a log file from rconsole, something wrong with filesystem 
writing permissions ?

sudo rebol
and then do %rconsole.r
and there was no error when I tried to write the log file.

A possible explanation is : your RSP processes are freezing because 
of a file access issue. The main process  wait for the RSP process 
to finish and launch a new one for new request. Once the max number 
of processes is reached, your server is no more able to execute RSP 
requests.

Hm, I have a very small data abstraction library that uses a prototype 
for a database, currently file-based - but it's not very ENTERPRISE 
:-)

Strange...  


I added some working JSON...  Somehow the .rsp file handling the 
JSON request is using functions that aren't including in the rsp 
file.  Is it supposed to do that?

A config file, but if you don't provide one, Cheyenne will create 
a default one in the same folder.

Btw, did you checked for a %crash.log file near cheyenne.exe?

Yes, can you just comment the following line in %UniServe/uni-engine.r 
file :

	if new/scheme = 'tcp [set-modes new [no-delay: on]]

then try again your test.

Basically, some errors are not reported or (not catched?) during 
RSP execution. I want to clean up the RSP logging code to output 
all errors to a log file.

Excuse me if I'm wrong, but "Accept-Ranges: bytes" is not implemented. 
Can this be done ?

I've just tried to resume a file from Henrik's server, and noticed 
that it has "Accept-Ranges: none". I know this means the web server 
is advertising "you can't resume!" My download client can use this 
information to avoid trying to resume, but it would be even better 
if the server allowed me to resume too :-)

If you have propositions for improving the debug mode, I'll be glad 
to hear them. 


I'm currently working on a new Cheyenne release with a big cleanup 
of all debug and error logging done by background RSP processes. 
It will basically generate only 2 log files : error.log and debug.log. 
You'll be able to send content to debug.log file using some functions 
like : 

- debug/print data

- ?? word

anyway, I will update the include.html file soon for you to have 
the information available

The on demand broadcast seems not dumpable as with the ultraverbose 
vlc -vvv rtsp://195.220.133.26:80/iStream/01_opening1.mov

I can see the video and see the "SETUP <url>/trackID=4" and PLAY 
RTSP commands while, with the dump parameters:  vlc rtsp://195.220.133.26:80/iStream/01_opening1.mov 
:demux=dump :demuxdump-file="01_opening1.mov"

the SETUP and PLAY don't work (actually they are not even tried) 
and I get 
VLC media player 0.8.6a Janus

[00000288] main input error: no suitable access module for `rtsp://195.220.133.26:80/iStream/01_opening1.mov'
[00000279] main playlist: nothing to play
I also tried some vlc scripting but with no success

foreach file [
	%01_opening1.mov
	%02_opening2.mov
	%03_carl1_1.mov
	%04_Carl1_2.mov
	%05_Francois.mov
	%06_Maxim1.mov
	%07_Carl2.mov
	%08_Ladislav.mov
	%09_Sunanda.mov
	%10_Carl3.mov
	%11_Reichart.mov
	%12_Maxim2.mov
	%13_Ron.mov
	%14_Nicolas.mov
	%15_Concluding.mov

] [write/binary file read/binary join http://ead.ephe.sorbonne.fr:81/R7/ 
file]

** Script Error: Not enough memory

** Near: write/binary file read/binary join http://ead.ephe.sorbonne.fr:81/R7/
>>

foreach file [
	%01_opening1.mov
	%02_opening2.mov
	%03_carl1_1.mov
	%04_Carl1_2.mov
	%05_Francois.mov
	%06_Maxim1.mov
	%07_Carl2.mov
	%08_Ladislav.mov
	%09_Sunanda.mov
	%10_Carl3.mov
	%11_Reichart.mov
	%12_Maxim2.mov
	%13_Ron.mov
	%14_Nicolas.mov
	%15_Concluding.mov
] [
	if error? try [ 

  in: open/direct/binary join http://ead.ephe.sorbonne.fr:81/R7/ file
		out: open/new/direct/binary/write file

  len: to-integer (to-integer in/locals/headers/content-length) / 1024
		siz: 0
		chunk: 4096
		print ""
		while [data: copy/part in chunk][
			siz: siz + length? data

   print ["^(1B)[Awriting file:" file to-integer siz / 1024 "KB of" 
   len "KB..." ]
			insert tail out data
		]
		close in
		close out
		in: out: none
	][

  print ["ERROR during transfer of" join http://ead.ephe.sorbonne.fr:81/R7/ 
  file] 
	]
]

BrianH, there is a problem with that file as Reichart can verify

Keeps track of referring pages, lets you make file comments, etc.