World: r3wp

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

Why aren't you using Cheyenne for rebol.com ?

what Terry tries to say imo is, that nowadays the web proceeded, 
and it is much more dynamic, so that even RSP sounds old-school ...

I call it "why didn't we have this 10 years ago".

G: It runs on a large hosted provider.

H: yes, it's a bit odd. I thought CGI was dead 8 years ago.... but 
then, NO.

Reason is, if you don't want to use Php, and you want economies of 
large hosting providers, that's your main choice. Else, Perl. <gag>

slicehost is $10 or $20 a month

Last week, when reviewing the R2 build... I finally had a regret 
that we never released the apache mod for R2.

Hmm, that would have been interesting.

But, I felt it was a kludge back in 2000.... however I think Jeff 
K was right.

I assume an R3 apache mod would not be far away, possiblity wise?

G: slicehost allows running your own server??

And he's come back to tell you this??  :)