World: r3wp

Thanks for the FYI

Gabrielle !
http://www.youtube.com/watch?v=7QS6Op-vV94

seems to be encrypted

at the end ?

codec du francois

lol

But I prefer this one Gabrielle = Gaby
http://www.youtube.com/watch?v=mey8GokRFf4

doc is going to kick us out of his group soon!

Don't Bother, I know how to deal with him :-)

Gabriele: in the temple.r file, the word CONTEXT is used to define 
some functions, then you export them with the 'export function defined 
in the utility.r file. Is there a 'best practice' about it as I don't 
see the difference compared to simply defining it within the scope 
of the file?

I think it's Gabriele's module system. Similar functionality is standard 
in REBOL 3. When you export explicitly, you can choose what to export 
and what to leave internal to the context, so you have minimum potential 
for conflicts with the global context

Got it. Pattern #1.

Kaj: well, it's not my module system, but it's basically the same 
thing as using SET 'WORD instead of WORD: , except that it is more 
readable (a newbie can guess what "export" means, while it's harder 
to guess that SET 'WORD is different from WORD:)


Florin: since R2 does not natively include the concept of "modules", 
all of us have been doing various things to avoid polluting the global 
context too much. I eventually got tired of all this and created 
this instead: http://www.rebol.it/power-mezz/mezz/module.html

Hi all, just to let you know that I'm upgrading Cheyenne websocket 
support to the last ws draft RFC, the handshaking part has changed 
and is not compatible with the previous version, causing all current 
Cheyenne ws apps to not work with latest browsers (like Chrome 6).

I've made a func to calculate the challengin code given the header 
request.

It was in the "I'm new" section, but it works nicely, I'm using it 
very often, so it's well tested.


ws-chall: funct [header [string!]] [		
	
	cnt: funct [k] [
		n: copy "" 
		ns: 0 
		repeat x k [
			if all [x >= #"0" x <= #"9"][
				append n x
			] 
			if x = #" " [
				ns: ns + 1
			]
		]
		if ns = 0 [
			return none
		]			
		(to decimal! n) / ns
	]
	
	int-2-char: funct [n [integer! decimal!]] [
		;n: to decimal! n
		head insert insert insert insert make string! 4
			to char! n / 16777216
			to char! (n // 16777216) / 65536 
			to char! (n // 65536) / 256
			to char! n // 256
	]

	attempt [
		t: parse/all replace/all header crlf lf "^/"

  l: copy [] repeat x t [if n: find x ":" [insert tail l reduce [copy/part 
  x (index? n) - 1 next n]]] l: head l
		k1: next select l "Sec-WebSocket-Key1"
		k2: next select l "Sec-WebSocket-Key2"
		k3: next next find header "^/^/"
		aux1: cnt k1
		aux2: cnt k2
	]

	if any [none? aux1 none? aux2 none? k3] [return ""]

 to-string checksum/method rejoin [int-2-char aux1 int-2-char aux2 
 k3] 'md5		
]

Thanks for the code, but the handshake implementation was trivial. 
My current issue is the fact that the new ws draft is breaking HTTP 
specifications by using a GET request with a message body...WTF?

I'm not the only one to find that odd: http://blog.iworks.at/?/archives/69-WebSockets-Handshake-non-HTTP-conforming.html

SVN revision 87: websocket support updated to follow draft 76 specs 
(works with Chrome 6+)

Is http://nodejs.orgsimilar to what websockets does? I found it 
when reading about upcoming Palm (HP) WebOS 2.0 release ...

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

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