AltME groups: search

what would be the best way to resize and crop an image after it's 
uploaded on cheyenne .. using commandline imgmagick, I think oldes 
was making an magemagick binding once?, are there more light ways, 
can pure rebol do it?

If I have a domain like rebol.com, how do I make it so that a.rebol.com 
b.rebol.com etc ... work so that a.rebol.com etc appears in the browser 
address bar.  
What I want to do is create virtual domains ....

I think you want multiple subdomains, one for each user, and you 
can simplify that by defining one catch-all IP number in DNS. Then 
define all the virtual hosts in Cheyenne. You do have to add every 
subdomain to Cheyenne, but this way you don't have to maintain DNS 
for each

yes, I wrote the HTML dialect to do a similar thing, though not with 
direct mapping of HTML tags to REBOL words.

Henrik, is version 008 of your dialect not fully baked? What have 
you added since 007? If you could put it up on your site, I guess 
I could just diff the files to see. Also, when you say the docs describe 
005 to 007, do you mean to say that some of the docs are no longer 
relevant since they refer to the older version?

That's what I am having to do ...

exactly. I tried that tonight as I look at cheyenne for the first 
time. However, the on-page-start/end do not seem to work (in debug 
mode). The instructions are so simple I wonder why it would not work 
though.

It sounds like you want to do what I'm doing here http://rebol.wik.is/Cheyenne/Page_Title/HTML_dialect_demo
 

but have the html page act as the template

Good. What route do I go to show the .html extension in the browser 
though?

You say so because in your dialect, the master of the page is yourself. 
What do you do though when you have to interract with web designers?

Terry has mentioned nodejs before .. it's an event driven web server 
... nothing to do with web sockets per se

--- mod-userdir.r.original	2010-05-09 19:28:10.000000000 +0200
+++ mod-userdir.r	2010-05-11 00:45:24.000000000 +0200
@@ -12,40 +12,81 @@
 	on-started: does [do boot-code]
 	on-reload:  does [clear boot-code]
 	
-	get-ugid: func [name [string!] /local file uid gid][
-		if none? attempt [file: read %/etc/passwd][
+	get-ugid: func [name [string!] /local file line uid gid][
+		unless attempt [file: read/lines %/etc/passwd][
 			log/error "accessing /etc/passwd failed"
 			return none
 		]
-		unless parse/all file [
-			thru name 2 [thru col]
-			copy uid to col skip
-			copy gid to col
-			to end
-		][
-			log/error "reading /etc/passwd failed"
+		foreach line file [
+			if all [line: find/case/match line name  col = first line][
+				return either parse/all next line [
+					thru col
+					copy uid to col skip
+					copy gid to col
+					to end
+				][
+					reduce [to-integer uid to-integer gid]
+				][
+					log/error "invalid format reading /etc/passwd !"
+					none
+				]
+			]
+		]
+		log/error "user not found in /etc/passwd"
+		none
+	]
+	
+	get-gid: func [name [string!] /local file line gid][
+		unless attempt [file: read/lines %/etc/group][
+			log/error "accessing /etc/group failed"
 			return none
 		]
-		reduce [to-integer uid to-integer gid]
+		foreach line file [
+			if all [line: find/case/match line name  col = first line][
+				return either parse/all next line [
+					thru col
+					copy gid to col
+					to end
+				][
+					to-integer gid
+				][
+					log/error "invalid format reading /etc/group !"
+					none
+				]
+			]
+		]
+		log/error "group not found in /etc/group"
+		none
 	]
 	
-	change-id: func [id [word! integer!] /user /group][
-		if word? id [
-			if none? id: get-ugid mold id [return none]
-			id: pick id to-logic user

+	change-id: func [id [string! integer!] /user /group /local gid][
+		either string? id [
+			unless id: get-ugid id [return none]
+			set [id gid] id
+		][
+			gid: id
 		]
-		either user [
+		if group [setgid gid]
+		if user [
 			;logger/file.log: join logger/file ["-" id %.log]
 			setuid id
-		][setgid id]
+		]
+	]
+	
+	change-gid: func [id [string! integer!]][
+		if string? id [
+			unless id: get-gid id [return none]
+		]
+		setgid id
 	]
 	
 	words: [
 		user: [word! | integer!] in globals do [
-			repend boot-code ['change-id/user to-lit-word args/1]

+			repend boot-code either word? args/1 [['change-id/user/group 
mold args/1]] [['change-id/user args/1]]
 		]
 		group: [word! | integer!] in globals do [
-			repend boot-code ['change-id/group to-lit-word args/1]
+			unless empty? boot-code [change boot-code [change-id/user]]

+			insert boot-code reduce ['change-gid either word? args/1 [mold 
args/1][args/1]]
 		]
 	]
 ]
\ No newline at end of file

Kaj: I'm applying your patch on mod-userdir.r. I'm changing the user 
/ group arguments datatype from word! to string!, this both reduces 
the code size in mod-userdir and makes the dialect less confusing 
IMO when you use named uid/gid. So, instead of :

user www
group users

we'll have now :

user "www"
group "users"

Do you agree with that change?

I'm wrapping up R3 A107... so if we want to do some test builds for 
2.7.8 on this, let me know.

Depends if you want to keep that local to your webapp or share it 
for all your webapps (using do/global or *do in that case).

Gregg: my solution was missing a 'unset call too (tested with Cheyenne 
sample webapp, works ok) : 

on-application-start: does [
	set 'rsp-include :include
	unprotect 'include

 unset 'include				;-- this one is required to allow %include.r to 
 load properly
	do/global %include.r
	set 'include-path [%//dev/Cheyenne/www/testapp/]
]

Kaj: so, this means that an install script would be required for 
Cheyenne to be able to run on UNIX, this is not something that I 
want for Cheyenne unless really necessary. Do you see any simple 
solution to that issue? If not, I'll revert it to write in /tmp by 
default and add a config option to let users choose alternative location 
when desired.

I'll have to do some more digging Doc, and maybe see what do* does 
since I haven't tried that. I'll actually read some source if need 
be. ;-) 


What I saw with your new change is something I also saw once with 
the previous approach. Plain CGI worked fine until an RSP was run, 
then the CGI failed, *then* both the test RSP and test RSP web app 
started returning with garbage at the top of the page. More garbage 
each time, like a buffer was being added to. Then the plain CGI worked 
again. Doing a reset on the workers solves the garbage problem.


My Cheyenne EXE is from 2009 so I'll check for a new one before doing 
anything else.

Kaj: so, this means that an install script would be required for 
Cheyenne to be able to run on UNIX, this is not something that I 
want for Cheyenne unless really necessary. Do you see any simple 
solution to that issue? If not, I'll revert it to write in /tmp by 
default and add a config option to let users choose alternative location 
when desired.

Packages for Linux package managers do indeed come with stuff to 
install into /var/

SVN r104: 

- FIX: port-id's relocation for multiple Cheyenne instances support, 
wasn't working correctly.


Do not use r103 binaries to run multiple instances of Cheyenne. I'll 
update the binaries asap.

Do you mean the binding to the set-env function in the C library?

So do you have the Library component on OS X? That's what's needed 
to do it

Tracing it. That's odd: the general binding is done in misc/macosx.r. 
I don't see why cgi.r should do it double

The CGI.r code is run in a separate process, it inherits OS bindings 
from misc/macosx.r only when encapped. It should have worked using 
the  /cmd binary, I need to look into it and patch the CGI code to 
not bind twice when encapped.

The actual system will run under Windows but we've encountered a 
strange problem. I'm trying to do some testing on my Mac to try to 
isolate the problem.

do i just format my data result to look like: 
Commuter.dataSource.setData({ ... JSON data ...});
and then 'print' it for the client to catch (read)?

If you view this page https://fd.cloud-ehr.net/drugreactions.rsp?rxcuilist=855348541713 541713 849339 108911


Does your browser complain that it doesn't understand what to do 
with the rsp page?

This is what I am sending

HTTP/1.1 200 OK
Server: Cheyenne/0.9.20
Date: Thu, 02 Dec 2010 15:33:25 GMT
Content-Length: 475
Content-Type: application/vnd.adobe.xfdf
Connection: Keep-Alive
Content-Encoding: deflate
Set-Cookie: RSPSID=XESYTVZSEFSXPQHCTITGRDQG; path=/md; HttpOnly
Cache-Control: private, max-age=0
Expires: -1


Firefox opens up the PDF referenced in the xfdf file that is downloaded.

Chrome just downloads and saves the content.  So maybe it's just 
Chrome's PDF "plugin" that doesn't understand what to do ...

RT's attitude is - do it yourself, as it is 12 pages of C code, and 
we don't care about having R3 doing at least the same stuff as was 
possible with R2. I described the syndrome here


From what Carl told me, producing that code took an enormous amount 
of resources of several of his best coders at the time it was made, 
because there is a lot of trickery involved. It took a lot of research 
and he is therefore probably not inclined to do it again that way 
for R3. Maybe a smarter method will come up, but would you rather 
have him dive into that for 3 months or finish R3?

even 650 USD was not enough
 That just means:

-people who might do it consider it not enough for the time they 
would spent on
or

-noone really needs it so urgent to pay it as contractor work instead 
of bounty

I expect DESIGN of the product being fully in hands of Carl
 - Why?


Part of the point to the host kit application structure is to allow 
Carl to focus on the core stuff and leave the periferal stuff to 
other people. This is partly done to be able to get other perspectives, 
and partly to relieve Carl of work that he doesn't need to do. Don't 
we want the work to go faster?

The other thing is that Carl thinks the solution is so obvious that 
he has not told us what to do, because he expects it to be happening 
now on a per-platform basis as part of the hostkit, just as Cyphre 
describes. So while we're arguing here, and no-one is doing anything, 
in a few months time, he'll be surprised that nothing has happened. 
We should probably get him to make a blog post on it for "directions".

The main plus for FastCGI of REBOL is to cut down on startup overhead. 
You can do things with persistent state too.

Speaking of session affinity, how does Cheyenne do that generally? 
If you serialise the requests for one session to one UniServe task 
master, they must be queued, right?

Btw, worker processes are not equal wrt the load. The first in the 
list gets the more jobs to do, especially if requests can be processed 
fast (which should be the case in most of well-coded scripts). So, 
you get a natural "affinity" to the first worker (having the most 
code and data cached there) for all new incoming requests. 

So, in the long run, you can look at workers memory usage to see 
how the workload is spread, the first one having the biggest memory 
usage, the last one having the lowest. Looking at the last one is 
a good indicator if the number of workers needs to be raised or not, 
if his memory footprint hasn't changed since the last restart, your 
server is doing fine with the load. I should expose some workers 
and job queue usage stats to help fine tune workers numbers.

I do see the asymmetry on our server. I have also had cases, though, 
where the number of workers went above eight or to zero. I'm not 
sure if that is still happening with the recent version

Sorry, that was a question, not a suggestion. Do you actually want 
to authenticate based on client certificates?

MikeL: 

- Download Cheyenne revision 122 source package from here: http://cheyenne-server.org/download.shtml
- Open a 2.7.8 console
- Type: 
>> cd %<path-to-cheyenne-folder>
>> do %cheyenne.r

Graham:  I am happy using Andrew's ML.r with Cheyenne to implement 
Don't Repeat Yourself on the few pages that I do. <%

 include %ml.inc  ; does [%pop.r %push.r %build-tag.r %ml.r] which 
 can be pre-loaded 
	print ml compose/deep [
		h1 "Heading"
		p {Text paragraph}
		p (now)
	]
%>

I don't want logging... I need to look at it live... these services 
actually do network calls and wait on other servers... I need to 
look at them run each on their own... if one blocks... I don't want 
all the other logs to push of the view.


also, the worker process might be having mutually exclusive or causal 
side-effects.   with a different console view opened side-by-side 
its easy to see all these effects.  (one window jams when another 
runs... continues when the other is done... etc.

Dockimbel: I have to thank you for your presentation. Just saw it 
yesterday finally. Now I understand Cheyenne a bit more. Im curious 
about the tricky parts though. Like how do u handle forking and the 
communication between the master and the forks and stuff like that. 
I know it's handled by UniServe

Doc, is it safe to do this:

req/in: make req/in [
	data: value
]

within any/all of the module phases?

The issue with COLLECT is caused by DO. In RSP environment, DO is 
redefined to bind argument code to webapps execution contexts. The 
 RSP mezz DO has a fixed arity (= 1) while the native DO has a variable 
arity (= 3 inside COLLECT), hence the error.

Ok, I've found an (obvious) patch for COLLECT. A reference to the 
DO native is kept in RSP (*do). So the following patch (run in global 
context) would solve the issue:

if pos: find second :collect 'do [pos/1: '*do]

I guess other new mezzs in 2.7.8 might be using DO internally too, 
they would need to be patch one by one by Cheyenne to be used in 
RSP context.

Doc, one thing I have not yet fully mapped out in my mind wrt handlers.

Q1:

how do the handlers actually compile/get their source code... is 
it sent over tcp and run there, or does the handler load a file on 
its own?

Q2:
when exactly does this happen?

Q3:

can I configure the handler source or data in some way before it 
gets compiled/executed,  (at the mod conf parsing stage).


I neet the handler to share some data with the mod which manages 
it in some way.


I don't want to send this config data via the request, at each request 
(makes no sense)

yeah... I've changed my solution a bit.   the handler now has a variable 
to know if its been configured yet, and if it has, it skips that 
part of the code.   so even if I get the cfg at each request, I ignore 
it.


The cool thing is that my mod really doesn't need much configuration 
and most other standard configs are useless to it, so I commented 
just about all of them in my httpd.cfg and my mod still works.  :-)


very lean on the cheyenne side.  I do all the heavy lifting in the 
handler, so it can scale pretty well.

it has something to do with the connection keep-alive

BrianH: I've found a workaround for COLLECT (just replacing DO by 
*DO which refers to the native function in RSP environment). Can 
you tell me if there are other recently added mezzs (from R2/Forward 
mainly) that rely on DO in their implemenation?

In APPLY, the QUOTE function is added to the constructed block containing 
the function call. If you don't do something fancy with that function, 
no rebinding is needed. That function should really be protected 
in the runtime though; a *lot* of runtime code absolutely depends 
on these low-level control functions to behave *exactly* as they 
are expected to. Same goes for ALSO.

I need to work on Red this afternoon, I'll do a pass on things to 
add in Cheyenne tonight.

can anyone get a login for the cheyenne wiki?


I'd really like to put down my trials and errors of building my own 
cheyenne mod (with handler), so that others may benefit of knowing 
the few little caveats which can make the whole thing fail .... 
maybe do something like a step by step tutorial to begin with.


I'd also like to document all the phases of each internal layer of 
cheyenne (there are many), so that we can more easily navigate the 
code, knowing what we are doing and what other phase is part of each 
type of mod,extension, service, etc.   often, we see just one or 
two parts of a system implemented per module and its hard to get 
the whole picture.   


ironically, looking at the base objects is also hard to do, since 
there is so much "internal" code that it gets REALLY hard to understand 
what is internal, what is "interface" and what is provided as helper 
funcs for your own systems to use.  Add the fact that there are many 
layers sitting over each other, some layers which aren't actually 
layers of code, but layers in the "chain of command" and various 
phases.


now that I've made sense of a *portion* of this, I think I'm well 
placed to start documenting this.   I think that having a complete 
api reference for cheyenne would be really good for adoptance.


It would allow many of us to simply create integrated tools which 
just drop into cheyenne.  (like remark)

No time tonight to setup the automated builds, will do that tomorrow 
after finishing 8/16-bit support in Red/System.

but do i need a keyfile to run it? is it legal to run it? if there 
is a version which knows such extra features but still miniscule, 
what's the reason having to separate versions?

compiled versions do not require a key, that is what paying the SDK 
is for.  there is no need to talk about license keys within the binary 
packages... 


there could be another page which lists all the various source license 
and REBOL interpreter requirements though, 
with just a link on this page.  something like:


<a href="rebol-vs-cheyenne-licensing.shtml" >notes about required 
REBOL license and interpreter version requirements for use of source 
versions </a>

keys are only required to do the encapping

so, when will this be available?


*very soon*  I am building my first test release for my client tonight.


most of the research and prototyping is done, I already did some 
client demos for the people who are funding this project and I'm 
now in the "delivery" phase.


The most complicated parts of the system are already working (i.e. 
handler processes, dynamic compilation, automatic api interface building, 
per-host api/config, request/response chain of command, multi-format 
output, and more.)

a lot of details are still "up in the air" as far as implementation 
goes, so if you really have a need for this, PLEASE STAND UP and 
raise your voice.  tell me what you need, how you want it to work, 
etc.

so far I plan to deliver the first release with: 

  support 4 interfaces for calling : GET url, POST XML, POST Form data, 
  POST JSON.

  support 4 output formats : XML, HTML, JSON, TXT (which is in fact 
  rebol native data)


obviously this will be an ongoing project and anyone who is interested 
in helping out is welcomed to do so.  :-)

So, all I have to do is provide the WSDL ?

yeah, but you still have to put the code behind.   the web-api mod, 
provides an interface automatically based on what is actually being 
served.  you could easily build a little WSDL to REBOL api file converter. 
 just load the XML, extract the methods, the parameters and build 
an equivalent rebol function stub.


Then all you'd have to do is implement the function body....  the 
only detail is the xml datatype which don't all map 1:1 within rebol, 
but that can usually be pretty well cornered within the code itself.

It recognises the fast-rebol-cgi keyword in the globals now, but 
it doesn't seem to do anything. It seems to try to execute REBOL 
code as real CGI. It tries to use the shebang line and has permission 
problems with CGI files that it didn't have before

it turns out it was a different problem... he was running core.  
 but the proper way of loading libs (and I've had to do it to make 
it work on 64 bit systems)

how do I prevent the printing of "connecting to: localhost" when 
I read urls?
ex: 
>> read http://localhost:81/   
connecting to: localhost
== 0:00:00.010442948

well, you can still have a gui, but all it needs to do is build URLs 
and confirm the results  :-)

how do u ignore .svn dirs while grepping an svn repo? it's annoying 
to say | grep -v \\.svn all the time

aha. and we can't start the binary in a similar mode, where the errors 
are not caught and logged, but showed in the console instead? (im 
trying to do a do %cheyenne.r now)

http://www.berenddeboer.net/rest/authentication.html

this is a nice walkthru of the http auth theory with examples on 
how to do cross browser logout, forgotten password page, auto logout, 
etc etc

do you want me to commit the changes once I've updated to r135's 
support for min/max workers on the comand-line?

Max: I am very busy today, I am not sure I will have time to review 
your code now (you should send me a copy of the changed files first 
BTW). As you could see, supporting such feature at the config file 
level is complex because of config file being loaded only when HTTPd 
service starts (for historical reasons). I am not sure that initializing 
the HTTPd service ahead is a clean solution (the boot/ line has become 
a bit hard to read with this /no-start flag that loads and init HTTPd 
service...).


The solution I had in mind was to extract the whole config file loading 
from %HTTPd.r and put it in %cheyenne.r. This is a deep and complex 
change, that is why I was waiting to have enough time to do it in 
a single working session. Anyway, I will examine your solution first.

Obviously it's nice to be independent from the server - if you can 
get it to work cross-browser. But I always thought we have View for 
that. Also, it seems nice to have the browser do input checking, 
but if you want a robust app, you will have to get the server to 
guard its own consistency and end up writing all input checking twice

im loading libraries from on-application-start, then i was hoping 
to load some static data too, but the words i assign there can't 
be found in my script later.

the script is called via an alias though which was specified within 
a webapp section.

on-application-start: does [
do %some/lib.r
db: %db/dir/some/where/
]

httpd.cfg:
vhost [
  webapp [
    alias "/xxx" "db.r"
  ]
]


db.r can't access the db variable, although it can use the words 
defined in the library loaded by 'do

ok, probably im trying to do something forbidden there


6/5-17:27:41.971934-[Logger] New request: T6/5-17:27:41.948903-## 
Error in [task-handler-55484] : Make object! [
    code: 312
    type: 'script
    id: 'cannot-use
    arg1: 'path
    arg2: 'none!
    arg3: none
    near: [switch debug-banner/opts/error [
            inline [html-form-error err file] 
            popup [debug-banner/rsp-error: make err [src: file]]
        ]]
    where: 'protected-exec
] !

we have even experienced very strange behaviour with the
unless value? 'some-func [ do %../lib/obj.r  do %../lib/oid.r ]

tactic. our to-object function defined in obj.r didnt have a value.

we modified the script, did not restart cheyenne and it started working!

It recognises the fast-rebol-cgi keyword in the globals now, but 
it doesn't seem to do anything. It seems to try to execute REBOL 
code as real CGI. It tries to use the shebang line and has permission 
problems with CGI files that it didn't have before

I thought so. I'd have to do measurements to be sure

hmm... i thought i can put my shared library code above the webapp 
root, but it seem to fail without any errors.

what exactly is the purpose of the overwritten 'do function in the 
RSP handler?
i don't quite get that depth/1 and arg/3 stuff

i was moving a plain .r script which was aliased in a vhost context 
under a webapp and it started to fail because the 'do didn't seem 
to work properly

REBOL []  do %../lib/obj.r  probe to-object [a: 1]

i moved the library stuff into on-application-start, but still it 
wasted me a lot of time to realize that the 'do is overwritten in 
RSP and works specially (as in, it does not work) in webapp context

what exactly is the purpose of the overwritten 'do function in the 
RSP handler?
 Bind the loaded code to a special per-webapp context.

Right, words definitions that needs to be loaded in global context 
have to be loaded using 'do/global.

REBOL []  do %../lib/obj.r  probe to-object [a: 1]

It works here in a vhost (not in a webapp) using:

%obj.r  => REBOL [] to-object: func [a [block!]][context a]
%test.r => REBOL []  do %../libs/obj.r  probe to-object [a: 1]

Testing within a webapp now...

From a webapp, it works ok too:

%libs/obj.r  => REBOL [] to-object: func [a [block!]][context a]

%www/testapp/test.r => REBOL []  do %../libs/obj.r  probe to-object 
[a: 1]

>> read http://localhost/testapp/test.r
== "make object! [^/    a: 1^/]"

I have disabled the 'auth keyword from /testapp webapp to do this 
test, to avoid being redirected to a login page.

New Cheyenne revision: 138


FIX: RSP code binding issue with nested DO calls (thanks to Tamas 
Herman for
reporting it).


Please pay attention that this fix is really deep in RSP engine, 
I have tested it with all my RSP apps, but regressions are not excluded. 
Be sure to report me any odd changes in your app behaviour after 
upgrading to r138.

Dunno if this is relevant .. but I tend to use 'do* instead of 'do

do* == do/global == native 'do

There are cases where you want to bind your code to global context, 
so you will use 'do/global. For all other cases, you should just 
use 'do (especially now that nested 'do should to be fixed).

The errors I quoted are from crash.log. I'll do the -vvvv thing, 
but have to do it later tonight

any example how do u test pages behind a session?

im trying curl -D- -d 'login=test&pass=letmein' -c jar http://localhost:8080/app/login.rsp

but subsequent curl -D- -c jar http://localhost:8080/app/some.html 
still gives me 302 to login.rsp

any example how do u test pages behind a session?

 You shouldn't use AUTH keyword if you don't want the redirection 
 to a login page.

i'd be interested in looking into the sessions during runtime too.. 
can i do it on the cheyenne console by pressing escape?
You can access them in 3 different ways:


1) if run from sources, escape in the console, then enter: probe 
uniserve/services/httpd/mod-list/mod-rsp/sessions/queue. Type do-event 
when you want to resume Cheyenne.


2) run the %clients/rconsole.r from the source archive, you will 
have a remote console connected to your local Cheyenne process (try 
on prompt: netstat)


3) add this to the config file in globals section: persist [sessions]. 
When you want to look to the sessions, just stop Cheyenne process, 
a .rsp-sessions file is created holding the session objects.

pff.. my-http is not really transparent...

>> do http://www.rebol.org/download-a-script.r?script-name=my-http.r

connecting to: www.rebol.orgScript: "patched HTTP/HTTPS protocol 
with cookies support" (18-Aug-2006)
== none
>> trace/net on
>> read http://localhost:8080/testapp/login.rsp

URL Parse: none none localhost none testapp/ login.rsp** Script Error: 
querying has no value
** Near: http-command: either querying ["HEAD"] ["GET"]

btw, let me micro-interview you here: why the hell are u still using 
windows!? especially for development? :)


I consider that GUI are an improvement over CLI that make my life 
easier and computers simpler and more fun to use. I stick with Windows 
as my main platform because I never got used to Mac OS UI (tried 
for a few weeks, but gave up rapidly) and I found the other UNIX 
GUI less "efficient" than Windows. Also I found Windows to be quite 
transparent for my work, it just doesn't get in my way as other OSes 
tend to do, so I can focus on my work and forgot about the rest (especially 
since Vista days, I am now a very happy Seven user).


I must also add that I was an Amiga and BeOS user for more than a 
decade and spent all my college days on AIX, X-Windows and SunOS.

btw, this is how im listening to netradio rightnow:
$ mplayer http://lounge-radio.com/listen128.m3u

and the good thing is, i could do the very same under windows, while 
i had my windows netbook

Yes, but it is a very basic one and you need to use custom function 
calls, like: do-cache, load-cache, read-cache....

but why am i not getting such a nice and descriptive error?
btw, i was trying to catch this error, but no luck:
>> e: catch [cfg/root-dir]
** Script Error: Invalid path value: root-dir
** Near: cfg/root-dir
>> e: try [cfg/root-dir]  
** Script Error: Invalid path value: root-dir
** Near: cfg/root-dir

how can i get this as an error object, do i can explore?

GrahamC: any url which explains how to do that w google docs?

Well, yes, but I'm only using a plain text .. so an editor that saves 
the current text regularly.

What I do at present is ... create an empty document on googledocs, 
and save the docid in the database.  I then browse to the doc on 
googledocs, edit it and save it.

I then go back to my rsp page and click on a button that imports 
the document as plain text.

I collected links to several HTML editor widgets, but I don't know 
how they would do auto-saving

i would need the request/query-string functionality but on my own 
parameters which has nothing to do w the request params