AltME groups: search

that is very short, maybe < 2 pages...it that the whole cannoli?

I'm not clear on the issue. 1.3.61 was just a test release, wasn't 
it? And is there a UPC lib they're using that requires rebcode or 
something? i.e. what pages are being printed?

Henrik: just for info, there is CSS styles junks at the top of some 
pages like this one (in IE6 almost) http://www.hmkdesign.dk/rebol/reblog/files/category-3.html

(The results could be stored after this, mayb, so that only popular 
questions have web pages generated with the results in them.)

strange, I just searched it again, and for some reason, now, new-line 
is the first thing returned in google... damn... last week it wasn't 
in the first 3 pages   > :-(

Anyone processing strings from different code-pages would be driven 
crazy by case-insensitive char compare.

I think the above explains the problem domain. Imagine pages with 
lots of tags and that you don't want to clutter the emit-page function 
with lots of template variables neither want to compose the function 
given that if is a normal function where you do have other normal 
local variables. I am looking for ideas on how to approach this

Yes,  but how costly is this ? ( I currently can generate 1000 pages/minute)

http://web.syllable.org/pages/about.html

http://web.syllable.org/pages/about.html#technology

One minor comment on the Syllable about page ... the content is fine 
but the page is "too busy". Perhaps moving the "Syllable for ..." 
inline content off on a separate page (or pages) might be a good 
idea. Also need to regroup the bullet points ... it's generally a 
bad idea to have a heading followed by more than about 7 bullet points 
(your first set has 21, so splitting the Desktop and Server points 
into sub-categories should improve things).

I'm trying to keep it on one page, though. As soon as you spread 
things over multiple pages, most people simply won't go there

http://web.syllable.org/pages/about.html#Desktop

http://development.syllable.org/pages/index.html

Thanks. We made sure it would by having static pages, but on the 
other hand, the connection is not overly powerful at 10 Mb/s

Many bugs were fixed, including several regressions from earlier 
releases. The window decorators don't destabilise the system anymore. 
The installation procedure is greatly enhanced with options to fix 
hardware support problems. The native web browser is replaced with 
Webster, based on a newer version of the WebKit engine. Many enhancements 
were made to standards support, leading, among others, to the ability 
to run QEmu - so now you can run virtual machines. The documentation 
was improved and several translations were added. Read more in the 
full release notes: http://downloads.syllable.org/Syllable/i586/systems/Desktop/0.6.6/README-SyllableDesktop-0.6.6.txt
ISO CD images, (VMware) emulator images, an upgrade pack and documentation 
are available from the download page: http://web.syllable.org/pages/get-Syllable.html
Extra software is available here: http://web.syllable.org/Syllable/downloads.html

http://web.syllable.org/pages/about.html#Server

http://web.syllable.org/pages/about.html#Desktop

http://web.syllable.org/pages/get-Syllable.html#Live-CD

http://web.syllable.org/pages/about.html#Desktop

The utf-8 sequence for the multiply symbol is #{C397}. So you can 
look up character C3 in various code pages.

On Mac, you might be looking at Mac Roman  http://en.wikipedia.org/wiki/Mac-Roman

I have an idle Cheyenne running on a Linode server without a domain 
name. it's been there for a couple of months now. I was a bit surprised 
to already see bots looking for wordpress, admin pages and attempts 
to submit various scripts for injection in the access log. Well, 
I guess I shouldn't be surprised.

hm.. it's not very elegant, but I could probably just load the set-net 
mezzaine in cheyenne rsp pages.

Jun 18 12:50:12 mail kernel: oom-killer: gfp_mask=0x201d2, order=0

Jun 18 12:50:12 mail kernel:  [<c0157322>] out_of_memory+0x142/0x170

Jun 18 12:50:12 mail kernel:  [<c0158f27>] __alloc_pages+0x2e7/0x300

Jun 18 12:50:12 mail kernel:  [<c015a68f>] __do_page_cache_readahead+0x13f/0x2d0

Jun 18 12:50:12 mail kernel:  [<c0151f46>] __delayacct_blkio_end+0x46/0x50

Jun 18 12:50:12 mail kernel:  [<c02f9eab>] __wait_on_bit_lock+0x5b/0x70
Jun 18 12:50:12 mail kernel:  [<c0153640>] sync_page+0x0/0x40
Jun 18 12:50:12 mail kernel:  [<c0153636>] __lock_page+0x56/0x60

Jun 18 12:50:12 mail kernel:  [<c01567ee>] filemap_nopage+0x2fe/0x3c0

Jun 18 12:50:12 mail kernel:  [<c0162c82>] __handle_mm_fault+0x1d2/0x1140

Jun 18 12:50:12 mail kernel:  [<c028acea>] sock_aio_read+0x6a/0x70

Jun 18 12:50:12 mail kernel:  [<c0117f9a>] do_page_fault+0x7ba/0xd64

Jun 18 12:50:12 mail kernel:  [<c01397f0>] autoremove_wake_function+0x0/0x40
Jun 18 12:50:12 mail kernel:  [<c01790e1>] sys_read+0x41/0x70

Jun 18 12:50:12 mail kernel:  [<c01177e0>] do_page_fault+0x0/0xd64
Jun 18 12:50:12 mail kernel:  [<c01058db>] error_code+0x2b/0x30
Jun 18 12:50:12 mail kernel: Mem-info:
Jun 18 12:50:12 mail kernel: DMA per-cpu:

Jun 18 12:50:12 mail kernel: cpu 0 hot: high 186, batch 31 used:107

Jun 18 12:50:12 mail kernel: cpu 0 cold: high 62, batch 15 used:14
Jun 18 12:50:12 mail kernel: DMA32 per-cpu: empty
Jun 18 12:50:12 mail kernel: Normal per-cpu: empty
Jun 18 12:50:12 mail kernel: HighMem per-cpu: empty

Jun 18 12:50:12 mail kernel: Free pages:        2508kB (0kB HighMem)

Jun 18 12:50:12 mail kernel: Active:91716 inactive:257 dirty:0 writeback:0 
unstable:0 free:627 slab:2796 mapped:9 pagetables:434

Jun 18 12:50:12 mail kernel: DMA free:2508kB min:2532kB low:3164kB 
high:3796kB active:366864kB inactive:1028kB present:401408kB pages_scanned:439557 
all_unreclaimable? yes
Jun 18 12:50:12 mail kernel: lowmem_reserve[]: 0 0 0 0

Jun 18 12:50:12 mail kernel: DMA32 free:0kB min:0kB low:0kB high:0kB 
active:0kB inactive:0kB present:0kB pages_scanned:0 all_unreclaimable? 
no
Jun 18 12:50:12 mail kernel: lowmem_reserve[]: 0 0 0 0

Jun 18 12:50:12 mail kernel: Normal free:0kB min:0kB low:0kB high:0kB 
active:0kB inactive:0kB present:0kB pages_scanned:0 all_unreclaimable? 
no
Jun 18 12:50:12 mail kernel: lowmem_reserve[]: 0 0 0 0

Jun 18 12:50:12 mail kernel: HighMem free:0kB min:128kB low:128kB 
high:128kB active:0kB inactive:0kB present:0kB pages_scanned:0 all_unreclaimable? 
no
Jun 18 12:50:12 mail kernel: lowmem_reserve[]: 0 0 0 0

Jun 18 12:50:12 mail kernel: DMA: 9*4kB 5*8kB 0*16kB 2*32kB 1*64kB 
0*128kB 1*256kB 0*512kB 0*1024kB 1*2048kB 0*4096kB = 2508kB
Jun 18 12:50:12 mail kernel: DMA32: empty
Jun 18 12:50:12 mail kernel: Normal: empty
Jun 18 12:50:12 mail kernel: HighMem: empty

Jun 18 12:50:12 mail kernel: Swap cache: add 0, delete 0, find 0/0, 
race 0+0
Jun 18 12:50:12 mail kernel: Free swap  = 0kB
Jun 18 12:50:12 mail kernel: Total swap = 0kB
Jun 18 12:50:12 mail kernel: Free swap:            0kB
Jun 18 12:50:12 mail kernel: 100352 pages of RAM
Jun 18 12:50:12 mail kernel: 0 pages of HIGHMEM
Jun 18 12:50:12 mail kernel: 1992 reserved pages
Jun 18 12:50:12 mail kernel: 83 pages shared
Jun 18 12:50:12 mail kernel: 0 pages swap cached
Jun 18 12:50:12 mail kernel: 0 pages dirty
Jun 18 12:50:12 mail kernel: 0 pages writeback
Jun 18 12:50:12 mail kernel: 9 pages mapped
Jun 18 12:50:12 mail kernel: 2796 pages slab
Jun 18 12:50:12 mail kernel: 434 pages pagetables

Still no luck. I have looked at over 100+ google pages. Does anyone 
have a working example of a tcp connection using the non-standard 
method? So far I have not found one. Plenty of 'examples', but no 
actual working code. None of the 'examples' work for me. Everyone 
seems to be using the standard short method. Graham: Neither Path 
or Target worked. I checked the connection on my website and cpanel 
said I was logged in, so I have a connection, but I cannot get the 
correct syntax for 'write', so it goes back to the scheme host path 
port user pass path etc block. I'll buy someone a pint (I'm a Brit) 
or a cup of coffe for a working example of that code!

http://web.syllable.org/pages/about.html#Server

90+% of what you need to do that, Steeve, is already in the Library:

[1] we could (in minutes) add extra valid domains or types so a script 
could be categorised as draw-snippet


[2] the LIbrary doesn't use rebservices for an API. It has an API 
called LDS that predates rebservices (basically, the library team 
got there first). You can use it to download any script (among other 
things too)

http://www.rebol.org/cgi-bin/cgiwrap/rebol/documentation.r?script=lds-local.r#toc-50


[3] using LS to download a snippet every time it is needed would 
be slow and wasteful.....But you could easily write get-draw-snippet 
that caches results locally.
****

That would not be perfect as it would be good to have a page/pages 
showing the images the snippets produce. But if there were enough 
snippets, we could add that.....And, before we do someone else could 
beat us to it on their own website -- they could use LDS to get all 
the snippets and display the images. It'd be a neat bit of Community 
interaction.

====> Perhaps switch to Library for any detailed discussion.

moliad.net   is now on-line.   :-)


Served via cheyenne, using Remark-mod, building pages dynamically.


Now that I've got the look pinned, the server & all dependencies 
sorted out,  I can now concentrate on CONTENT & documentation. :-)


The server is setup with all remarking debugging enabled (which is 
extensive!).  so there might be some slow down sometimes.  Usage 
will allow me to see if its an issue or not. 

Tell me what you think of the style (in ann-reply :-)

Since AltME is very alive in these days I whish to go back to school 
and review with you some basic concepts of REBOL.

The, with the result of these discussion I'll write some pages on 
REBOL2 DocBase and then for REBOL3.
Hope you will help. Tomorrow we will start.

i would say parse is really the thing i need to understand further 
and heavy work on (you can write a 500  pages book only about parse 
and all it's subtilities)

I use Cheyenne with my HTML dialect to host small dynamic pages that 
take a few minutes to write.

Henrik: where are your pages ?

It could be a good base for a remote Wiki editor. Just add an HTML 
generator to convert to static pages tree.

hmm, pages for DevCon are down, so actually it is difficult to say, 
wehn it will happen :-)

I just realized, my postscript pages are gone with my old homepage. 
Moving things over to ...

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.

Doc, are you considering simple HTML templates for .rsp pages, or 
is that already possible?

Such as converting a block of values to a table:

<% print html-table read %. %>

with RSP, would there be an option to only run .rsp files and not 
.r? if I want to serve .rsp pages and allow downloading of .r scripts?

clean and complete separation between HTML and REBOL code
 

So you are not mixing rebol code with html in one file? (like in 
RSP)

But your building web pages using rebol code alone? Is the server 
acting like a serverside "plug-In"?
Sorry if I sound completley novice.

RSP? Ah, server pages ... I exchanged it with services protocol? 
Still do you plan on some remote protocol? Btw - will rebservices 
work upon cheyenne? It probably should, as it can work upon html?

It has some features that make it ideal for serving web pages, DB 
access etc... all the stuff that's right up your alley.

DocKimbel, small request: Would it be possible to post the rsp guide, 
cheatsheet and docs as separate pages directly on the site? It's 
unpractical to have to download Cheyenne every time I switch machine, 
just to read the docs. Thanks.

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?

1. Variable overwrite is a possibility. 2. I don't use PHP fastcgi. 
3. If I could get Cheyenne to serve pages again, I'd be happy to 
recreate the problem. The server is (was?) running on port 80. I 
don't see what or how that could change

got it to serve static pages, but rsp is still not running. I must 
go now, but I'll try continuing tomorrow.

travel oriented websites, rebol is generating static pages, cheyenne 
process dynamic rsp pages and tracks users (so one more rsp hit for 
every page static and dynamic)

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

I'm not at all clear on how to support a  REST call
Say, I have something like this

POST /@api/deki/pages/=patients%252F300/contents HTTP/1.0


how would i process that so the correct rsp page deals with the request?

I didn't see it as a big issue.. served up 500 pages in a few seconds.. 
just wondering why?

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

Is there a chance to use basic authentication instead of using cookies 
to access pages inside the webapp?

static pages ( index.html ) work .. but cgi and rsp don't.

Just a crash involving cgi and rsp.  Static pages are still okay.

are static pages still working when it crashes?

Crashed again ... static pages still serving, just rsp down and this 
is with 9.19

All I'm doing is editing RSP pages, and running them.

So, I guess it was just bad Rebol coding .. ( caused by my last minute 
desire to edit the rsp pages thru the web )

RESTfull systems use virtual pages don't they?

I guess that's different ... you're talking about having real pages 
stored in a virtual filing system

older rsp pages work fine

http://rebol.hmkdesign.dk/site/pages/<-- try this page

Graham, possibly, but I use this method in about 20 other rsp pages 
without problems.

Looks like I'm going to have a very few pages as entry points to 
the application ... and so all the code will only be in a few pages.

Ok, that makes sense ... I didn't want 10 pages of code between <% 
%> !

well, I guess there isn't much published on what is good practice 
on writing RSP pages :)

on-status-code   in  htpd.cfg not work   . I reveive default  http-error-pages: 
[
		400 "<html><body><h1>400 Bad request</h1></body></html>"
		404 "<html><body><h1>404 Page not found</h1></body></html>"

  501 "<html><body><h1>501 Request processing error</h1></body></html>"
	]default

I have tag.r that has 

tag: context [add: does [something]]


I DO tag.r on most of my RSP pages but not on json.rsp yet I'm using 
TAG/ADD in json.rsp without problems.

tag is being set globally but I didn't expect includes to be persistent 
across different pages.

feature request: add on-global-page-start and on-global-page-end, 
same as on-page-start and on-page-end but executed for all rsp pages, 
not only for webapps

New Cheyenne 0.9.19 beta version available for testing at : http://cheyenne-server.org/tmp/cheyenne-r0919.zip


Tested only on Windows  (my Linux image network has currently some 
issues).

ChangeLog (diff-ed from last test version) :


 o RSP: an HTTP redirection in 'on-page-start won't evaluate the page 
 script anymore.
	

 o CGI: mezz function READ-CGI now patched to be compatible with Cheyenne. 
 That's
	  the right way of reading POST data in REBOL CGI scripts.
	  
	o RSP: fixed a bug in session/add when setting a block! value.
	

 o Task-handler: fixed a network error on first packet read (high 
 load + fast hardware).
	

 o Task-handler: TCP keepalive mode activated (test workaround half-closed 
 connections).
	
	o Task-master: 
			o 'no-delay mode removed and replaced by 'keep-alive mode

   o now forks a new process as soon as one dies (not waiting for a 
   new request)

   o fix a long standing bug in queued job module name mismatching (can 
   happen under extreme load)
			o minor code cleanup
	

 o Uniserve: 'no-delay TCP network mode now switched off for all connections. 
 Fixes a

   stability issue on Vista and probably on UNIX with very high load.


 o RSP: fix a bug in 'decode-multipart when there's no file received.
	

 o UniServe: new logger service. Now all info or error logs, and debug 
 messages from

   CGI/RSP scripts are written in %trace.log. Additionnaly, you can 
   now log messages
	  using :
	  
	  		- debug/print msg 	; msg [string!]
	  		- debug/probe value 	; any mold-able value
	  		- ?? word		; works like REBOL's '?? function
	  		- ? msg		; alias for debug/print
	  

 o RSP: in debug mode, page generation time and SQL queries stats 
 now added at bottom
	  of pages.
	  
	o RSP: error in events from %app-init.r now logged.
	

 o RSP: fix a rare RSP freezing issue when an error occurs in %RSP.r 
 (for example, by
	  a user script that breaks RSP sandbox).
	  

 o RSP: sanboxing now protects from Exit/Return/Break calls made outside 
 of a
	  function context.
	  
	o RSP: %misc/rsp-init.r file removed.
	

 o RSP/CGI: New config keyword added in global sections : 'worker-libs. 
 It lists the

   librairies to load when a worker process is started. An optional 
   'on-quit section can

   be added to call cleanup code when the process quits. Examples :
	  
	  		worker-libs [
				%libs/mysql-protocols.r
				...
			]
		or	
			worker-libs [
				%libs/mysql-protocols.r
				...
				on-quit [
					%/libs/free-resources.r
				]
			]
	

 o Task-master: now you can reset all worker processes without stopping 
 Cheyenne. This

   is usefull when you need to force non-RSP/CGI files reload (helper 
   scripts, 3rd party
	  librairies,...). 
	  
	  	Usage:
	
			Windows : tray icon -> Reset Workers
		

   UNIX : kill -s USR1 <pid>	(<pid> is Cheyenne's main process ID)
	 
	 

  o Added a -w command line option to set the worker processes number. 
	 
	   	Usage:
	   
	  		$ cheyenne -w <n>		(n [integer!] : CGI/RSP process number)
	   

    Use -w 0 to help debug CGI/RSP code by resetting worker processes 
    after each request.
	   (it's like calling "Reset workers" after each request).

Btw, here's some stats for cheyenne-server.org web site (online since 
jun-2008) :

Total page viewed : 48224

  - Static pages : 9824
  - Blog : 19179
  - Wiki : 19221

Is there much overhead compressing pages before sending?  I know 
that most modern browsers support deflate...

I just measured loading times on CC using pages with 200 tickets 
listed. On average, before compression ~700ms, after ~300ms. (40ms 
latency between my PC and the server).

I run several domains as virtual domains in lighttpd. And I have 
one document root for Cheyenne. The idea is to be able to add the 
same RSP page (like a shopping cart) to severl domains without having 
to duplicate the RSP code pages.

My directory layout is like this:
cheyenne (containing all RSP pages)
domains
	domain1
	domain2
	domain3
	...

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.

I've played a little with jQuery and jQuery UI, and there doesn't 
seem to be a problem pulling RSP pages into the DOM.

I had a problem the other day where I had what looked binary appearing 
on my RSP pages before everything else.  I had to restart Cheyenne 
for it to go away.  Wierd.

A session is a block! of name / value pairs that is kept in Cheyenne's 
main process and exchanged with worker process. A synchronization 
system is there to avoid concurrency issues. The SID sent by cookie 
to the client is just a lookup key. When sent back to the server, 
this key allows to identify the right session object to pass to the 
RSP script in a worker process.


You are only limited by memory, but remember that the session object 
is MOLDed / LOADed and exchanged by TCP twice for a RSP request. 
So, in order to keep your RSP pages fast enough and scale well with 
a growing number of active users, keep the session block! as small 
as possible.

In one of my RSP based app, I have pages with tabs. I use 2 different 
approach :
 

- for tab panels with data cross-dependencies : I use a unique RSP 
script generating a page with a unique <FORM> tag and each tab content 
is simulated by <DIV> sections that I show or hide (with JS) depending 
on the selected tab.


- for tab panels with no cross-dependencies : I use a separate RSP 
page for each tab content. The tab bar is a unique RSP script included 
by each "tab content" script.

This is a video of my RSP pages showing binary at the top of the 
page.  http://screencast.com/t/WD2j8PJtse

I was creating rsp pages writing them to the www directory and trying 
to browse to them ... and it wasn't working with my test.rsp page

I run 2 cheyenne webites (site-assistant and qwikitodo) and 2 apache 
solr servers and a bunch of rebol bots on 180MB RAM VPS for 12EUR/month.. 
and pages load in a snap (unless I add sqlite update/delete/insert 
to the pageload)

If I code a RSP script I know which methods to expect. So, the normal 
pages only use POST, GET. As soon as I create a site that uses other 
methods, I need to make XMLHttpRequest form the client. Than I know 
which methods to handle.

I don't see a problem here.

If I code a RSP script I know which methods to expect

 Ok, you know but Cheyenne doesn't know unless you told him. So if 
 you don't filter yourself (as you don't want it to be filtered by 
 Cheyenne), you'll most probably return broken pages to client using 
 HTTP methods you didn't expected.

yep... got that ... but can't find the docs for mods on the cheyenne 
site... since the wiki went on line, all pages are empty  ' :-/

Cheyenne Kimball: I often stumbled upon her fan pages searching for 
cheyenne keyword, pretty and talented woman.

I'd say your RSP script should "be" the resulting web page; that's 
the normal way to generate dynamic pages. Why do you think of them 
as separate?

the thing is that in order to save resources, mod-remark will be 
creating MANY static files (including images and css scripts) but 
the content of those pages can ultimately change at each refresh, 
if the user is editing preference type information.

download and double click.... but  I'm working on mod-remark, so 
its not currently serving web pages...

still at first, i did see the standard cheyenne pages and don't have 
any logs.

verbose is at vvvvv (working) and pages are being served... yet I 
have no *.log files.

Back to RSP, if you allow nested RSP and do word capturing BUT passing 
words between parten/child pages, I''d say, yes, Cheyenne's RSP is 
very good.

Word capturing => yes, all RSP running inside a webapp are captured 
in the webapp execution context, to avoid global context pollution. 
This doesn't apply to standalone RSP scripts (outside a webapp), 
but that feature could be easily added.


Page inclusion => yes, you can include RSP scripts in RSP. See http://cheyenne-server.org/docs/rsp-api.html#def-21

context injection with 

captured" words on the subpage" => I don't understand precisely what 
you describe here. In Cheyenne/RSP, subpages are captured in the 
webapp unique context, like parent pages, so there's no special treatment 
for subpages. Do you imply exporting just a selected list of words 
from the subpage script to the parent context?

I'm seeing some odd root kit like behaviours ... cheyenne is clearly 
serving up pages,, but the icon is gone from the system tray and 
it does not appear in the processes list in the windows task manager!

well, for the moment I have fixed the issue by hardcoding the value 
into the rsp pages.

And here I was looking for  some type of caching occuring in Cheyenne 
or my RSP pages

rsp pages should not be cached by default by any browser. Do you 
have firebug in FF can you look at the header fo the response an 
see if there is any difference between the two requests? wireshark 
or tcpflow can be used to look at headers as well

My server traces show that Chrome is not actually visiting the pages 
...

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