World: r3wp

Noone should run any server with disk near full.  The OS and software 
doesn't like it.

Henrik: what os are you running it on? If you can zip all you server+config+rsp 
I'd be happy to install it locally and see what could be wrong

Will, OSX Leopard. I think I'll wait with external testing until 
I can open my new website a few bits at a time.

one think comes to mind, if you use the source instead of the binary, 
after unzipping the download I always have to convert all line endings, 
I unzip then drag the whole folder on LineBreak.app http://www.versiontracker.com/dyn/moreinfo/macosx/13491
. I remember having strange behaviours like your ones if not done. 
I'm on os x as well

Will, that's pretty amazing numbers. I'm currently using lighttpd 
for my web-sites. It's lean and clean. Maybe I should give Chyenne 
a test on my production system. What about the memory consumption?

Hm, I just spent two days getting a REBOL script to run from a graphical 
launcher in Linux

One of the many problems was that Linux chokes on the first line 
of the script, that specifies the REBOL interpreter to run with, 
if it has a DOS line ending (a CR before the expected LF)

I had to use a hex editor to debug this

It could well be the same on OS X

Kaj, get the dos2unix utility

Don't need it, if I press ENTER in an editor on Linux I get just 
a linefeed :-)

The problem was finding out that this was a problem, amidst all the 
other problems

And besides, REBOL has dos2unix built-in :-)

Robert: here is actual memory consumption after running for 157 days:

ID     Process Name              User        CPU      RSIZE      
      VSIZE

11591  rebol                     root       0.00     52.65 MB    
    75.64 MB         

11592  rebol                     root       0.00     152.00 KB   
    27.72 MB         

11593  rebol                     root       0.00     14.05 MB    
    39.41 MB         

11594  rebol                     root       0.00     9.93 MB     
    30.80 MB         

11595  rebol                     root       0.00     29.84 MB    
    52.00 MB         

11596  rebol                     root       0.00     10.46 MB    
    30.84 MB         

11597  rebol                     root       0.00     10.92 MB    
    30.33 MB         

11598  rebol                     root       0.00     200.00 KB   
    27.72 MB         

11599  rebol                     root       0.00     168.00 KB   
    27.72 MB         

11600  rebol                     root       0.00     168.00 KB   
    27.72 MB         

11601  rebol                     root       0.00     160.00 KB   
    27.72 MB         

11602  rebol                     root       0.00     204.00 KB   
    27.72 MB         

12464  rebol                     root       0.00     9.55 MB     
    30.74 MB         

12465  rebol                     root       0.00     9.35 MB     
    30.29 MB         

12466  rebol                     root       0.00     160.00 KB   
    27.72 MB         

12467  rebol                     root       0.00     160.00 KB   
    27.72 MB         

12513  sshd                      root       0.00     1.34 MB     
    29.89 MB         

15246  rebol                     root       0.00     4.63 MB     
    29.34 MB         

15247  rebol                     root       0.00     160.00 KB   
    27.72 MB         

27117  rebol                     root       0.00     8.17 MB     
    30.45 MB         

27118  rebol                     root       0.00     168.00 KB   
    27.72 MB

always read and write in Rebol a foreign script.  Sometimes you also 
need to pass it thru detab.

some comments:

- the 52.65MB process is a memcache like uniserve service that has 
thousand of pages and partial data cached

- every task-handler process (those that process rsp) have i18n module 
that caches data in memory

ok I've just restarted and here is memory consumption for you to 
compare:

ID     Process Name              User        CPU      RSIZE      
      VSIZE

18455  rebol                     root       0.00     6.74 MB     
    30.32 MB         

18456  rebol                     root       0.00     156.00 KB   
    27.72 MB         

18457  rebol                     root       0.00     9.19 MB     
    30.58 MB         

18458  rebol                     root       0.00     4.63 MB     
    29.34 MB         

18459  rebol                     root       0.00     4.63 MB     
    29.34 MB         

18460  rebol                     root       0.00     4.63 MB     
    29.34 MB         

18461  rebol                     root       0.00     4.63 MB     
    29.34 MB         

18462  rebol                     root       0.00     168.00 KB   
    27.72 MB         

18463  rebol                     root       0.00     160.00 KB   
    27.72 MB         

18464  rebol                     root       0.00     164.00 KB   
    27.72 MB         

18465  rebol                     root       0.00     160.00 KB   
    27.72 MB         

18466  rebol                     root       0.00     160.00 KB   
    27.72 MB

Wil, thanks. Looks very promising.

Graham, it's not always possible. In this case, I have REBOL scripts 
in AltME for remote update and collaboration, that are started by 
external launchers or the command line

If someone edits a script on Windows, when it messes with the first 
line, it won't start any more on Linux

Doc, where does Cheyenne get the location "C:\Documents and Settings\All 
Users\Application Data\Cheyenne" from? Is it hard-coded or do you 
retrieve it from the registry like Windows does?

The registry key is "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell 
Folders", the value is "Common AppData".

If you take your setting from there, Cheyenne will be compatible 
with Vista, Server 2008, and weird setups without change.

I think you can also use the SHGetFolderPath API.

Yeah, that is the Windows API that retrieves the values from that 
area of the registry. You will need to determine which is easier: 
Using the built-in registry APIs or creating a routine! wrapper for 
SHGetFolderPath.

Cheyenne uses SHGetFolderPath( ) API.

Cool :)

I think that the API approach is more reliable across Windows versions 
and flavors.

Robert: you can use get the wrapper for this API function in Cheyenne/misc/win32.r.

Doc, what's the appropriate way to process http methods ... such 
as delete, put, options, get, post ... if one wishes to write an 
API based upon these?

REST for Cheyenne!

probably past his bed time now ....

He'll read later, and in the meanwhile you can read the Cheyenne 
docs, samples and source.

I've only ever used RSP with Cheyenne.

though I did build a smtp server using Uniserve once ....

Prior to today, the only thing I knew about REST was that it existed. 
 Now, ... I'm thinking that it might just be the way to go to provide 
web services for non REBOL clients.

The trick is that many HTTP clients only support GET and POST.

which is why I was hacking the http protocol recently to add the 
others

Presumably javascript supports all http verbs?

I wouldn't presume that - test first.

Or look it up.

is this the way to support all clients ?  from cellphones, to pdas 
and then full featured client browsers

well i only used get and post so i can't tell the others options

If you only use get and post, you can't do REST - it requires the 
others.

Handheld devices may be another matter. Many of them have poor JavaScript 
support, and most don't support XMLHTTP.

Those might require old school HTML get/post interfaces.

Which can also be implemented as Cheyenne proxies to your same LNS 
service.

how would one use cheyenne to load/balancing redistributing the resources

Cheyenne docs look a bit sparse ... the wiki sections are all looking 
for an author except for RSP. http://cheyenne-server.org/wiki/Main/HomePage

Docs: I put the wiki online mainly because several peoples asked 
me for one so they can contribute by documenting Cheyenne...