AltME groups: search

hehe, Tom Halwerda got reply from someone from Syllable team apparently 
:-)
-------------------

 By Vanders (IP: ---.cable.ubr02.chap.blueyonder.co.uk) - Posted on 
 2005-07-04 22:34:20
Sorry Thom but you're wide of the mark on several counts.


Systems like the Amiga or BeOS failed for a number of reasons, but 
mostly because they were either tied to a minority hardware platform 
and through sheer poor management. It's fair to say that both were 
ahead of their time, which was certainly a contributing factor. We'll 
add NeXT to this list while we're here. Syllable and SkyOS are written 
for generic Intel PC hardware, and neither are old enough to know 
if Robert or I will kill either through bad management!


Sure we want to compete with Linux. Linux is a great OS on the server, 
it's a sucky desktop. I've been running it for over six years on 
my home PC and several years now in various real-world deployments 
in a server capacity. Year after year, Linux continues to dissapoint 
me as a desktop OS. Why shouldn't we compete with that? Saying "You 
can't compete with Linux!" is just deafeatism. The thing is, Syllable 
is not out to beat Linux. We want to co-exist with Linux and in doing 
so, enhance the Open Source ecosystem. Linux can run the servers, 
Syllable can run the clients. Makes sense to me.


Look, if in two years time us Syllable developers have nothing to 
show for it but an OS that only us six run and are happy with, well 
then that's fine with me! I'm sure as hell not going to roll over 
and pretend that I like using Linux on my desktop though. Why shouldn't 
we try to improve it? Because we might fail? Piffle.

Some quick points to finish off:


o Robert is a good developer but I don't believe he has the time 
or the hardware to have written every single driver for SkyOS from 
scratch. The video drivers are from X & if you asked him, I'd expect 
the NIC & audio drivers are BSDL.

o The Open Source nature of Syllable has never been in impedement 
to implementing features. We have a set or core developers and we 
make the decisions. We have a roadmap and we're following it. To 
paint Syllable as a band of wishy-washy Open Source developers with 
no direction who are somehow bogged down with arguments is misleading 
and dishonest. Just like SkyOS, if we decide a feature must go in 
it goes in.

o I'm not aware of a single company currently working with SkyOS. 
We can sign up for the exact same Developer Relations schemes as 
Robert can. Many companies don't seem to mind that Linux is Open 
Source, I fail to see how Syllable is any less legitimate in this 
regard.


Hard is the whole point Thom! What's the point in doing easy? Anyone 
can do easy!

Lots of bugs were fixed over the past year, and again in Syllable 
0.6.1, which we will probably release this weekend. So yes, that 
would be a good time to try again

:-) interesting, and probably not correct group here ... you have 
different ideas than Orca? Now as R# is showing non-activity for 
way too long time, Orca is the only clone which showed some promise 
...

Yeah, my approach is different. My time and energy is limited though. 
We'll see if I can budget the time to work on it.

In the coming years, each time we improve the functionality enough 
to make the system usable for the next ring, the number of users 
will increase by an order of magnitude

5 Core developers, maybe 50 that have contributed at some time, 500 
on the mailing list, more than 1000 on the forum, 5000 who download 
each install CD, more than 10,000 who download each live CD and emulator 
image, tens of thousands who come visit when we're on OSNews, roughly 
an order of magnitude more when we're on Slashdot

It has taken us half a year this time. Almost all parts of the system 
have been overhauled, but this includes my build system. The system 
build is now finally fully automated, and we are confident that we 
can use this to get back to one release every two or three months

This release also marks the first time that Orca is actually used 
in the system, after already being included in the previous release. 
I rewrote pkgmanager in it, a tool used to register and unregister 
binary packages by managing a pool of symbolic links

- A new scheduler, which makes things like audio and video much more 
usable. You can now keep using the system for other tasks while playing 
multimedia. In fact, we can now easily replicate the famous BeOS 
demo with six videos running at the same time

well, nothing is responding .. so time to kill vmware player again.

Since time immemorial. That's how we got AtheOS from Kurt, and it 
has been a huge advantage

It hasn't been open that long. :-) About eight monts now. The current 
Syllable release is the first one that was produced under formal, 
public bug tracking, so a lot of bugs got squashed. Previously, we 
didn't have very many reports, and the time to fix them is scarce, 
anyway

I didn't want to make that part of the announcements yet, to give 
people time to digest the idea of our use of Linux. That's plenty 
controversial already :-)

Cloning R3 is pretty much beyond our reach. We only have time to 
integrate existing parts

In the first years, you would choose the Linux for stability and 
hardware support. Over time, you would migrate to Desktop for superior 
performance and ease of use

At the time when I made this group, I didn't want to impose too much 
on the REBOL community here. Do other people think it's a good idea?

This thing must really be a time killer... a nice one of course.

Thanks. It sure is. On the other hand, around the time we started, 
five years ago, I and others spent so much time fixing Linux that 
we independently sort of decided that it wouldn't really take more 
time to spend it on developing  our own operating system. It certainly 
leaves us with a lot more to show for all that time

Well, both Linux and Windows, really. The Windows situation is still 
roughly the same. Linux has improved a lot over that time, but only 
to reach about the same levels as Windows

I hope this time, once R3 beta is out, they will not hesitate to 
post about it. And I also think, that Syllable helped REBOL on osnews 
a bit. Because if OS designers decided to use such language, it ought 
to be rather good :-)

And it has software that also takes time to port to Desktop

We're on OSNews again (well, we haven't been off the front page for 
a few weeks), this time with our new Syllable Newsletter:

The time has arrived! We have released Syllable Server

It's a development release. A lot of work remains to be done in the 
time to come, but I made sure it's usable for several things already

No, there's noone but me for some time to come who could write this 
documentation

I think all my linux boxes have the wrong time.

because the imap server thinks the time is wrong and keeps shutting 
down :(

With the download being a few MB, you save download costs right with 
our first large package. Especially on dial-up, which is also a large 
part of the world. And of course, the next time you already have 
it installed

30 Million downloads, and an all-time top ten position on SourceForge, 
is really not noone using it

Me too.  But I did try the Live CD just now.  Nice.  All the problems 
were minor.  I didn't spend a whole lot of time 'in system' but I'll 
try and takes some notes next time I boot it up.

just wanted to drop by and say that I published alpha of my first 
mini cheyenne webapp and it is the most responsive app I ever made 
.. it is noted also when not on local comp and someone of 2 peps 
that tried it already wondered how come it loads so fast ...  this 
is minimal app so it looks more reasonable but I know a slightly 
bigger app that I am making behaves just as fast for now..  have 
to run.. will read this cookie discussion other time

It's something like framework... if you check the httpd.cfg, you 
can see something like:
webapp [
	virtual-root "/testapp"
	root-dir %www/testapp/
	auth "/testapp/login.rsp"
	;debug
]

When you that access the server with starting with the virtual-root, 
it's proccessed by Cheyenne using the %www/testapp/app-init.r file 
where are several handlers which are processed by the process. So 
you don't have to for example think how to update session time etc.

I am not shooting down your idea.. I am just trying to say that cheyenne 
with just simgle -- exe + folder + config file -- already provides 
very deployable webapp solution, compared to for example installling 
apache + php + apache + pear.. and django / ruby (with just development 
server) also wasn't anywhere near as simple to install last time 
I tried

I have one question... after working in various other languages + 
mysql/sqlite I am using normal files with rebol structures and LOAD 
for my first projects here. Now I have a little more serrious project 
up so I started thinking if by using just files I can corrupt data 
somehow. I am not that good on low level details, but I imagine that 
I don't have to worry too much. Because cheyenne is single process 
I imagine only single write to file can happen to some file at any 
given time. Am I correct or wrong?

What you describe would mean, than you can only do one CGI request 
at the time. Cheyenne will launch new CGI process at each request, 
hence your file operations could collide. I like SQLite very much, 
but they don't provide server level functionality. They are able 
to work at file-lock level, but dunno how solid it is ...

I am not sure if cheyenne starts new process for each request , I 
suspect it uses async sockets and serves request at a time

I suspect on the system level at the time one write is in action 
file is locked for all other writes

Petr, the filesystem will ensure that this won't happen. The thing 
is, that for the time you write to the file, you get a file-lock. 
But this is immediatly released after you finished. So, if you try 
to write to a file with a lock, you get an error.

A DB handles this by having one file lock for the database file all 
the time, taking several request at the same time and doinga  DB 
locking scheme on-top of the filesystem locking.

aha, so rsps work on multiple worker processes, interesting.. well 
I think to me it's not a problem as each user has it's own data files 
so it's hard to imagine multiple writes could happen at the same 
time for the same file. And if I would need something reall y heavy 
duty I would make a server serving files and caching them in ram 
for speed etc, which would also take care for sync. or something 
off the shelf

You can get file access errors and corrupted data in file (last write 
wins probably). A simple RSP page may be rendered very fast, but 
there's situations where it can take much more time. Imagine a complex 
query on database or using CALL to a third-party command-line tool.


With RSP pages rendering in a few ms, the risk for collision is very 
low, but it's not zero.

thanks for all info.. to me it's important difference if (1) last 
write wins or (2) data get's corrupted meaning you get file that 
doesn't have a rebol data that could be load-ed any more. Well I 
think I have been asking too much and should try experimenting and 
looking what happens. If only (1) can happen with very small probability 
(because I have many separate small files which don't get edited 
most of the time) in case of my current app it seems ok, but I will 
test (also what happens with read and write at the same time.) If 
(2) can happen at all then I will use/make a centralized file/data 
server right now so webapp will access no files directly any more 
and that server will have to take care of locking or serialize all 
reads writes.

If you meant : create a new SID each time a RSP is called in case 
the RSP script uses session/start, that could be a solution, but 
not very elegant.

I'm just wondering how to simulate tabs in a rsp page ... do I have 
to recreate the tab each time I switch to it, or can I keep all the 
data in a session.

General answer: session data is exchanged by TCP for each RSP request, 
so the performance penality can be high for huge session data. That 
also means that your server won't be able to handle a lot of user 
session at the same time.

Let's clarify a few things :


- Request/content is working OK in your example, there's no issue 
with that.


- Using variables in PARSE rules without initializing them is a bad 
programming practice in my book. You *should* initialize them before 
using them (unless wrapped in a function which will do the work for 
you). If your parse rule fails, your code may error out (or you may 
get an unexpected value) when trying to print 'phone because it hasn't 
been initialized. 


- You seem to expect that RSP script will be evaluated in a fresh 
REBOL session each time. This is not the way RSP works. RSP uses 
persistent pre-forked processes for performances. If you expect a 
fresh REBOL session each time, then this is the CGI model which is 
an order of magnitude slower than RSP. 


- Even if RSP processes are persistent, they can be restarted or 
killed and you can't control which process will executed your script, 
so, just as a warning, you can't expect that a "global" variable 
will be still there for the next RSP script evaluation. If you need 
value persistency, use a session variable or write it to disk.

I would initially not try to do VID graphics directly, but to do 
something like this:

html-view [
	text (reform "The current server time is" now/precise)
	display-name: text
	name: field

 button "Submit" [set-html-face display-name get-html-face name] ; 
 'name is stored on server too
]

... well, let's see how easy that is in JS :-)

Each time I go to the RSP page, more binary appears above my html.

on-page-start: has [][
	set 't0 now/time/precise
]

REBOL [
	Purpose: "RSP environement init code"
]

on-application-start: does [
	;--- add here your library / modules loading
    *do %private/captcha.r
    captcha/set-fonts-path %private/fonts/
]

on-application-end: does [
	;--- add here your library / modules proper closing
]

on-session-start: does [
	;--- add here your per session init code
	;--- ex: session/add 'foo 0
	;--- that can be latter accessed with : session/content/foo
	
	session/add 'user "guest"
	session/add 'hits 1
]

on-session-end: does [
	;--- add here your per session closing/cleanup code

]

on-page-start: has [][
	set 't0 now/time/precise
]

on-page-end: has [pos time][
	if pos: find response/buffer "</body>" [
		time: to-integer 1000 * to-decimal (now/time/precise - t0)
		insert pos reform [
			"<br><br><small>Processed in :"
			either zero? time ["< 1"][time]
			"ms.</small>"
		]
	]
]

The garbage data seems to increase by 830 bytes each time.

xfdf: {<?xml version="1.0"?>
<xfdf xmlns="http://ns.adobe.com/xfdf/"xml:space="preserve">
<fields>
<field name="Submit"><value>Send</value></field>
<field name="TextField1"><value>$fname</value></field>
<field name="TextField2"><value>$surname</value></field>
<field name="syupdfid"><value>$syupdfid</value></field>
</fields>
<f href="$myhost/testpdf4.pdf?$time"/>
</xfdf>
}

So, to use a single instance of cheyenne, I have to go thru all my 
source and change the database name so that it's different each time 
I want to run more than one instance of this web app

Ok, time to check them out.

pdf downloaded ... bed time reading it is then.

Thanks for the link Paul, I'll check that site next time I need a 
name! :-)

I'm on a time limit for now so I'll increase the post mem limit by 
10x, but I need to get this fixed eventually so I'll track the error 
down.

This was after restarting Cheyenne after a crash. I gotta review 
the source some time :(

Brian: It shouldn't be a problem. Sessions block is hashed, so session 
access time is constant and the only impact is on memory usage.

Taking the time to read all messages back to 18h March to dig it 
up was most probably driven by another goal than just saving me from 
re-typing it. :-)

Damn, that's the first time I'm noticing that feature in AltMe!

Doc, agree too. It's a mess. And a time-killer if you start using 
Linux. Where can I find ABC etc.

how many connections are actively being served , time since they 
connected (to enable better timeout handling), etc.

ok. thanks, you`ve already helped me save some time  :-)

this way, the uniserve can ask the service if all is set for handling 
requests... there are hundreds of uses for this... time tables, required 
header fields, etc etc.

part of the integration will be run-time tag editing, so anyone will 
be able to build a CMS using remark, out of the box.

Doc. I have made a testing engine that simulates all sorts of http 
requests for testing my apps in rebol ... it so so works now, so 
I have to improve it still . .. you could also use that to create 
a pack of test suits for cheyenne and each time you make bigger changes 
you just run it and see if things behaved as suspected

Not sure what you're trying to do, but, you shouldn't need to lost 
time of low level async stuff. UniServe is meant to offer a complete 
client and server API that should save you from working on low level 
stuff (unless what you're trying to do is not supported by UniServe's 
API).

I will survive if I have to be in debug mode all the time :) I thought 
it will add some output to ajax responses too and make them unworkable 
but you seem to thought of this :)

That's very interesting and inspiring work. It's close to my own 
thoughts about a web app testing framework. You're very right, the 
main target should be the webapp API, not the UI. That's why I didn't 
invest in Selenium, I don't want to update scripts every time I change 
the UI without changing features.

Robert, maybe it should be the right time to switch to a "Testing" 
group (surprinsingly, there's no such group yet), we're going too 
OT.

Q3:  Are there any time-based call backs we can implement through 
mods?  sort of like a rate on a view face.

this would be very usefull:

-it could allow me to keep statistics on mod internals at regular 
intervals ex:  average load, high/low peaks, 

-perform cash cleanup/buildup, ping remote tools for "I am alive" 
monitors, etc.

Q3 : Not yet. It's a planned feature that I need also to add a simple 
CRON-like task scheduler inside Cheyenne. Feel free to add your own 
in your mod, I don't that I'll have time to work on it before middle 
summer (low priority task).

I'd like to not do everything by myself, but it's not that easy. 
I have some deep concerns for Cheyenne core part such as speed, memory 
usage, stability and security. Cheyenne has become a *critical* part 
of our business, I have to garantee that a new version won't break 
our webapps in production, nor make them instable, insecure or noticeably 
slower. My responsibility also extends to other companies that are 
selling products or services based on Cheyenne.


I've already accepted small patches on Cheyenne core in the past, 
but it takes me a lot of time to study and test each line of code 
an rewrite them if required. If your code has only a local impact, 
I might use it, if it needs to patch a lot of parts of Cheyenne/UniServe, 
I probably won't. Anyway, you can send it to me, it's always a good 
inspiration to see how other developers solved some specific problem.

the inability to run more than one Cheyenne server at the same time 
has been a problem too.

as Henrik said.. cheyenne was certanly rebol "web-window" for me. 
The day I tested and saw it can handle 300req/sec I switched to rebol 
for webdev.. there is no way I would use ordinary CGI to make webapps 
at this time.

Not just the TCP code will be open in R3 - the HTTP port code will 
also be open. One of the goals is to make something like UniServe 
completely unnecessary for R3. This is not a criticism of UniServe, 
but of R2. If R2's networking infrastructure were good enough we 
wouldn't need UniServe.


Hopefully by the time that Cheyenne is ready to be rewritten for 
R3 it will be able to be written right on R3's HTTP ports.

Brian: that's interesting, but as you can guess, my free time is 
currently very limited. Maybe we can work together on that? I think 
that your input (especially with R3) would be of great value. I agree 
with Pekr for the dynamic part of the server, without tasks, it will 
be good only for serving static files.

I'll investigate it further if I get the time.

Note this is a linux server-side only tool (currently).
currently:
	-remote browing of files in a gui.
	-uploading/downloading any files to/from the webserver
	-running command-lines remotely
soon: 
	-chmoding remote files
	-handling webserver start/stop/restart  remotely.
	-more as time goes by.

this being said... mod-remark will be using persistent liquid nodes 
for session and post/get parameter side of things, and its possible 
that I might store session data outside of the server itself, using 
a liquid-tcp node. 


so that access to actuall session data could be brokered outside 
the server's jurisdiction, extremely efficiently, locked one value 
at a time. and any access/change could be perpetuated to other handlers 
when they attempt to lock to one session value.

I thought also about doing a TCP based session server (with session 
variable granularity), but the overhead in synchronization would 
hit performances (and scalability) too much IMO. If each time you're 
setting a new value to a session variable in a script, you have to 
query a TCP server (even a local one), that would have a huge impact 
on a script execution time.

all the code which was originally called to create the news items 
is skipped... until some site parameter changes how the news items 
are built, which will automatically cause the news item to reprocess... 
 but on the page and server side, nothing special needs to be done. 
 liquid's internal caching will fork the processing by itself, and 
then start serving the new cached data the very next time any single 
news item is asked for again.

so most people put their time on tackling the real problems like 
sql injection and https use properly

the larger the func, the less hit, you can see that each function 
call is taking more time to initialise because of the return.

RETURN usage: your benchmark doesn't reflect real usage. RETURN cost 
is only significant if you didn't spent much time since you've entered 
in the function. In other terms, if RETURN is at the very beginning 
of the function, it might have a significant (means measurable, doesn't 
imply high) impact on performances, if much code has been processed 
before reaching it, I guess that you won't be able to measure any 
difference in performances.


In Cheyenne's mods, I often use a testing expression at the beginning 
and jumping out if it doesn't match. Let's try to calculate how much 
gain I would get by removing this early RETURN :
    - 500 incoming req/s (extreme load conditions)
    - 10 mods
    - 12 callback / mod (each one having a early RETURN)

    - execution time for testing expression before each RETURN : 0 (will 
    give us the maximum possible final gain)

RETURN evaluation time :  (according to your benchmark)
>> (1.032 - 0.296) / 1E6
== 7.36E-7

# of RETURN evaluated under the testing conditions during 1 sec :
>> 500 * 10 * 12
== 60000

Time spent in 60000 RETURN :
>> 7.36E-7 * 60000
== 4.416E-2			; = 44 ms, roughly 1 / 20 sec


So, under extreme conditions, having a testing condition before RETURN 
taking no time, we can have a maximum gain of 5%.

This translates in real usage in a gain of 0 to 5% depending on server's 
load and test branching conditions performances.


Looking at the testing conditions in current mods, I guess we could 
squizze between 0 and 2% (under extreme load only). I'll try to hunt 
down those early RETURN cases in future versions.


Btw, there's a drawback in not using RETURN, you end up with nesting 
IF/EITHER expressions, which gives you less readable code IMO.

Currently yes. I didn't found any value of having logs both on screen 
and on disk at the same time. But if you can convince me that it 
has a value, I may support it in future.

my client uses the console for real-time status checking... using 
remote desktop and just noticing if the client isn't serving stuff 
anymore... but the logs then allow you unravel what led to that problem.

I have a problem, that after some running time Cheyenne seems to 
get into an unstable state and my REST shopping-cart isn't working 
any longer. I got this error in the trace.log, which seems to be 
Cheyenne internal:


5/6-10:09:48.142823-## Error in [task-handler-40014] : Make object! 
[                                                                
                 
    code: 501                                  
                                                                 
                                      
    type: 'access         
                                                                 
                                                           
    id: 
'not-open                                                        
                                                                 
            
    arg1: "Port"                                    
                                                                 
                                 
    arg2: none                 
                                                                 
                                                      
    arg3: 
none                                                             
                                                                 
          
    near: [parse/all current: fourth entry [          
                                                                 
                               
            any [                
                                                                 
                                                    
            
    end break                                                    
                                                                 
        
                | "#[" copy value to #"]" skip (        
                                                                 
                             
                    append out reform 
[                                                                
                                               
                 
       " prin any [pick cat"                                     
                                                                 
   
                        locale/id? value                     
                                                                 
                        
                        mold value #"]" 
                                                                 
                                             
                   
 ]                                                               
                                                                 
 
                )                                              
                                                                 
                      
                | "<%" [#"=" (append out " 
prin ") | none]                                                  
                                          
                copy value 
[to "%>" | none] 2 skip (                                        
                                                          
      
              if value [repend out [value #" "]]                 
                                                                 
              
                )                                 
                                                                 
                                   
                | s: copy value 
[any [e: "<%" :e break | e: "#[" :e break | skip]] e: (          
                                                     
           
         append out reform [" txt" index? s offset? s e #" "]    
                                                                 
         
                )                                      
                                                                 
                              
            ]                     
                                                                 
                                                   
        ]]   
                                                                 
                                                                 
       
    where: 'confirm                                      
                                                                 
                            
] !                                 
                                                                 
                                                 
5/6-23:01:46.501455-## 
Error in [task-handler-40014] : Make object! [                   
                                                              
  
  code: 501                                                      
                                                                 
                  
    type: 'access                             
                                                                 
                                       
    id: 'not-open        
                                                                 
                                                            
    
arg1: "Port"                                                     
                                                                 
                
    arg2: none                                  
                                                                 
                                     
    arg3: none             
                                                                 
                                                          
    near: 
[unless no-lang [                                                
                                                                 
          
            id: locale/lang                           
                                                                 
                               
            locale/set-default-lang 
                                                                 
                                                 
        ]      
                                                                 
                                                                 
     
        out: make                                          
                                                                 
                          
    ]                                 
                                                                 
                                               
    where: 'confirm 
                                                                 
                                                                 

] !

Ok, great. Any time frame ;-)? Or can I use the source-code version 
so long? If, is there a link to dowload it?

yes... I already new... but I had to trace the code and lost some 
time wondering why my page wasn't being re-rendered when I first 
used 'BIND  ;-)

I also had to trace the logic to make sure that cheyenne wasn't actually 
expecting an external handler if I used 'BIND-EXTERN...


I ended up loosing more than an hour to figure it out myself... now 
that is just one config... there are MANY... a lot of them I don't 
even know exist.


the above is exactly the kind of information which should be included 
within the httpd.cfg file, even if an example is commented out, but 
provided as an example use.  just like apache does it.

I hate Apache config file. Because I hate having to read tons of 
docs to just "switch on" some app. Cheyenne's config file has never 
been designed to copy the Apache way, nor to be used by average end 
user. It's just a placeholder waiting to be replaced by a builtin 
web GUI allowing a simple, fast and straightforward way to manage 
the server. That has been the plan since the beginning and one of 
the main motivation for building Cheyenne. Unfortunately, I never 
had the required time to complete that goal yet, so I'm stuck with 
that, and that's also why Cheyenne is still at 0.9.x.

Ok, got it, finally. Problem was DO-SQL's signature differing from 
what I've been used too, having dealt with RT'S ODBC drivers most 
of the time. Sorry for the noise.

Doc, RSP by itself.. I use a version which does set word capturing 
(do you do that?) and allows page inclusion and context injection 
with "captured" words on the subpage. Do you do that?


Otherwise, a lot of Qtask "the application"  is Javascript on the 
UI calling API services - RSP is of little use there. The main web 
site... I would actually oppose REBOL. Why spend time there on e.g. 
a shopping cart when you can take one of the shelf and spend that 
time improving the real product (the service/application)?

maybe ... I'll watch out for it next time.

I have some time allocated today to work on Cheyenne so I will give 
it a look.

App-init.r : if you define a word! in a RSP script or in app-init 
event handlers, remember that it will only exists in the worker process 
context where it was called. It won't be defined in the other worker 
processes, so it will likely produce errors in your app. The only 
safe and multiprocess way is to use session object. This means that 
you currently can't have such thing as webapp global words (but you 
can at the session level).


If REBOL had multithreading or, at least, an efficient IPC between 
REBOL processes (like shared memory), you would have such feature 
since the beginning. I was reluctant to extend my custom IPC to allow 
shared global values for RSP script because it would have an impact 
on performances, but maybe the added value worths it and the impact 
might not be so big (basically, a MOLD/LOAD + 2 TCP transfers of 
all shared data for each request). Perhaps, it's time to reconsider 
adding this feature?

Can you all please "document" those finding in the Cheyenne Wiki? 
This should build a collection of tipps & tricks over time.

Sadly no .. it does actually create the document the first time, 
but then brings up the same document again the second time.   So, 
basically the same behavior as cognito

I think I may be able to get around this issue by tagging the request 
with a dummy time parameter.