World: r3wp

Add this to the $(document).ready(function(){  ... } in chat to submit 
chats using the enter key;

			$("input").keypress(function (e) {
				if (e.which == 13 ) {
					   ws.send('m' + user + ': ' + $("[name=post]").val());
					   $("[name=post]").val('');
					   $("[name=post]").focus();
				}
			});

Updated version of Doc's chat example.. 
- Enter key support for login and posting chats
- Cookie mgmt for user name
- various "tweaks" to the JQuery 

chat2.html:  http://pastebin.com/m66a38d50

Thanks Terry, I've upgraded the chat demo with most of your changes. 
I've also included an alert message for non-compliant web browsers.

Need to fix the 'signout' updates to other ports.. it's not sending 
the "bob leaves" message, and it's not updating the user list <div>

No cookies? I like cookies.

I've opened 2 Chrome windows logged in the online chat demo from 
both of them and I receive correctly in the first window the quit 
message from the second one. How can I reproduce your issue?

Cookies: well, it would be a nice addition to a real chat app, but 
the point in this demo is to show web socket usage, not to build 
a full-featured chat app. If you want to build a full chat app, you're 
free to take my demo code and extend it as far as you wish.

Btw, you may need to Shift+Reload in Chrome to get the latest chat 
code.

Shift + Reload (I am used to it) = F5 btw ....

I'm not sure for Chrome, isn't F5 a simple page reload (without clearing 
the cache)?

Ahh.. shift-reload to clear cache, and nice debugging/developer tools.. 
Chrome is well thought out.

Doc, i was referring to my modified chat.html regarding the 'signout' 
issue.

Does Chrome have anything like FireBug or WebDeveloper extension 
in FF?

That chat.html I made was a quick hack of yours. Need to build proper 
cookie mgmt functions.. deal with sessions etc.

Yeah, in Chrome, hit CTRL-SHIFT- i

All in all doc, cheyenne sockets are very impressive. 
Couple of suggestions.. 

- Have a folder specifically for socket-apps that automatically get 
loaded into the http.conf file.. 

- Create a connection through PHP (if possible.. otherwise can just 
proxy, but adds lag)

Socket apps folder automatic loading : you still need to specify 
the mapping between URL and socket app, no ?

PHP connection: it should be possible with minimal modifications, 
but why would you want that? Is there any  significant PHP socket 
app yet ready to use? My goal in adding web sockets early in Cheyenne 
is to push developers to make nice apps in REBOL, not PHP.

To that end, any chance you could extend your WebSocket framework 
with a somewhat similar Comet-like functionality for older browsers, 
that only uses Ajax?

Doesn't have to be perfect, just facilitate a migration period for 
older browsers

That may be possible, but would be more complicated to support than 
web sockets as the server can't send data without getting a request. 
It will be hard to extend the web socket application framework without 
bloating it. Maybe a separated mod-comet would be a cleaner approach 
(but might duplicate a Iot of code in mod-socket). I will give it 
a look anyway, at least to estimate the time required to support 
it.

I plan on making my apps in Rebol, but 99.99999% of the developer 
world won't be so 'inspired'. You may get away with it if you can 
build a killer app, which may very well happen now.
Otherwise, it will be a hobby, like Rebol.

Ruby on Rails looks interesting, but not interesting enough for me 
to spend more than an hour 'playing' with it. BUT.. if RoR built 
some killer app that let me config it, I would take the time.

Now all you need to do is come up with the killer app :)

Überchat

Terry, the point is that if you want to make PHP apps, you should 
better stick with another web server more adequate to PHP like Apache 
or Lightttpd. Cheyenne's PHP support has been done mainly to be able 
to integrate existing PHP apps in REBOL powered web sites, not build 
new ones.

The other option is to build a higher level dialect of some sort. 
Even developers would switch if the switch was dead simple.

It's not a matter for me to favor REBOL against PHP for builting 
apps (everyone is free to choose), but just that there are better 
tools to run PHP code than Cheyenne. OTOH, I'm not sure there's better 
choice currently than Cheyenne to run REBOL web apps.

In my books, Rebol should change it's name to Cheyenne.

From a purely marketing POV, that might make sense. ;-)

The desktop is dead, unless you're building a better browser, or 
games.. and even that distinction is blurring. I'll bet people play 
more online browser based games than desktop.. Folks have moved from 
desktop to console.

Cheyenne Scripting Language
, sounds good. ;-)

There ya go..

Cheyenne OS

You should probably dual license Cheyenne.

One BSD, the other commercial

Or maybe GPL and commercial

That's the plan once Cheyenne reaches 100K users. ;-)

Btw, the target market that was at the origin of Cheyenne project 
was home web servers, both for local and external use (serving files 
and apps from your home connection). The main feature was supposed 
to be simplicity of use through a very simple, but powerful control 
panel, and on-demand app loading (something like App Store, but for 
web apps). Another market that we've thought about was portable embedded 
web apps (server + apps bundled in a single exe with 0 install, 0 
config).

Write some simple docs outlining websockets, and I'll get you to 
50K in a month.

To start addressing these markets, I need a 1.0 Cheyenne (means finish 
some features + units tests + full docs).

Yeah, my stuff is all using the embedded feature.. very nice.

Still needs an improved virtual filesystem to easily run RSP web 
apps from memory, but for custom embedded REBOL apps, it should work 
ok.

BTW.. i use PHP as a language, not for it's "Hypertext preprocess" 
... 85% of my php has no html in it at all.   Mainly use PHP to receive 
and process AJAX form requests

So, to copy this method into Cheyenne websockets, i need to 'DO' 
.r scripts.. not rsp.

RSP is fine, but I just don't like the whole 'preprocessor ' approach.. 
it's too 1995

I don't like page refreshing.. should trigger an event, and all the 
elments fade out, and new ones fade in. You can do this kind of stuff 
with AJAX, and even more so now with WS

Hi guys. Yes, you really can divide the scripting needs into just 
a few primary categories.

As I wrap up WIP3 for the current website redo, it seems a bit odd 
that each time, the WIP system gets smaller and better.

I would call this "design refactoring" ... a high level form of "code 
refactoring".