World: r3wp

node.js is a v8 javascript interpreter that could be used server-side 
to make tcp server.

So, not only web server but server with persistent connection too, 
like web sockets.

Javascript on the server side isn't a new idea, but V8 is very fast 
and more light without the html dom complexity.
It's all event driven and seems very fun to play with it.

SVN revision 89: removed View engine dependency for displaying error 
messages produced by switching to Windows Service mode.

if there are other "hot" issues to fix in Cheyenne, please let me 
know.

Btw, Windows Service mode seems to run OK under Windows 7 if Cheyenne 
is started with admin privileges (tested with an enpro kernel).

Dockimbel, will you provide an encapped version again? Last time 
I had quite a mess figuring out what Cheyenne version worked with 
what REBOL version, so I just avoid upgrades unless there is an encapped 
version.

I distribute encapped versions only when making new releases. If 
you need a intermediary revision encapped, just let me know the OS 
and encap kernel and I'll make you one. Also, I think I should release 
a new version now, the current SVN code base seems stable enough 
now.

ok

hum...I forget about the SDK licensing issue, you can't distribute 
encapped binaries that allow running arbitrary REBOL code (Cheyenne 
allows that through CGI and RSP scripts).

ok

RE: SDK licensing issue:

So you could not make an ecapped app that uses rebol as its scripting 
language? Like a paint program that allows you to make your own macros 
for repetitive  tasks?

if your paint program allows anyone to run any Rebol script, then 
I guess no.

does it also say that if you use a plain enface? isn't this related 
to having access to pro/command features?

This is what the SDK license says (so related to any encapping kernel): 
[...]

REBOL API Restriction. If you choose to export the REBOL API (function 
and objects of REBOL) for users of programs created by REBOL/SDK 
(in other words, you allow users of your programs to write and execute 
REBOL scripts within your program), you must obtain a separate commercial 
distribution license from REBOL Technologies. If your program does 
not allow users to access the REBOL API, then no additional license 
is required.
[...]
http://www.rebol.com/docs/sdk/sdkintro.html

So, in fact, it's not forbidden, you just have to "obtain a separate 
commercial distribution license".

My experience with RT is, that if you try to communicate, you might 
get special deal. So - maybe /Command is no more a source of revenue 
stream for RT. What about asking them to relax the restrictions?

Pekr, feel free to ask.

Doc - I think you guys might be wrong, no? IMO the restriction applies 
to app, directly exposing REBOL scripts. Does encapped Cheynne does 
so? Can we regard CGI being such an exposure? Is it identical to 
doing a script "normal way"?

Pekr, the definition : "(in other words, you allow users of your 
programs to write and execute REBOL scripts within your program)" 
seems broad enough to me to include CGI. But as I'm not a native 
english speaker, I might understand it wrongly.

*I might not

damn...shouldn't chat on more than 3 windows at the same time...:-)

:-)

I discussed this with Carl before and it's okay.

Anyway it seems that restriction is now obsolete as ssl and odbc 
are now free.  And IOS is dead.  The license prevented you from creating 
a clone of IOS

if there are other 
hot" issues to fix in Cheyenne, please let me know."

Doc, how about committing my user/group switching patch? It doesn't 
completely seem to fix the problem yet, but it fixes many bugs on 
the way there

I updated to the lastest svn and encapped using encmd.exe from 14 
March 2008

Running from an administrator dos shell, I start cheyenne.

It says on hover, listening on port 8000 and cgi/rsp/html work

I click on the run as service and it changes to "Cheyenne is running" 
with no port now specifed.  Html/rsp and cgi all now fail.

This is on windows 7

If anyone wants to test it .. http://www.compkarori.com/cheyenne/cheyenne.exe

Once I switch it back to a user application using the menu, it starts 
to work again

I confirm this behaviour, but if you launch Cheyenne by using right-click 
on cheyenne.exe and select "Run as administrator", then once in service 
mode, it works ok.

Yes, though oddly that's is what I first tried and it didn't work. 
 Which is why I switched to running from the dos shell.  Maybe I 
didn't get the right sequence!

Kaj: I can't find your patch, can you give me any pointer to your 
code? IIRC, there was some hard-to-fix issues with running in user-mode, 
like not being able to use the verbose/debug/trace mode anymore.

*there were

It's above here, at May 11:

--- 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

I don't know why that would break debugging, so that sounds like 
an extra issue

Because Cheyenne must start as root user to be able to open listen 
ports < 1024, then only, SU to a non-root user. Unfortunately, all 
the log files generated during the root phase of Cheyenne's boot 
process are owned by root, so can't be used anymore once su-ed to 
a non-root user. An easy way to fix that (but looks a bit ugly to 
me) could be to chown( ) / chgrp( ) all generated log files before 
giving up root rights...A cleaner way would involve rethinking the 
whole boot up process of Cheyenne and Uniserve with deep code architecture 
impacts (too much work). Any idea on the best way to solve these 
issues are welcome.

There's also the Cheyenne PID file written in /tmp/cheyenne.pid that 
will suffer the same issue.

separate logging service?

So then all Cheyenne instances could use the same logger

Yes, using the system logger daemon would be good

By the way, /tmp/cheyenne.pid contains "none" on my server, so that 
looks like a bug

http://www.rebol.it/power-mezz/mezz/logging.html

re System logging service: it's not an option because :
- not a cross-platform solution

- some files *have* to be generated directly by Cheyenne (like the 
HTTP log file)

- the trace output in debug mode can generate huge entries that are 
inappropriate for syslog

- the trace output needs to be free from non-Cheyenne entries (or 
it might become unpractical to use for developers)

re Cheyenne PID: your OS ID returned by system/version/4 might not 
be the same as the Linux one. Open %misc/os.r and add a new entry 
in the SWITCH block with your system/version/4 value and [%misc/unix.r], 
then try again.

Anyway, sending a few messages to syslog daemon to notify Cheyenne's 
starting/stopping or signals received might be a useful thing to 
be more sysadmin-friendly.

My system/version/4 on Syllable Server is 4, so something else is 
wrong