World: r3wp

:-)

I think there's only one issue left, for which I don't see an easy 
solution. If you specify both a user and a separate group, it must 
be in that order in the configuration file, because the group definition 
modifies the boot code that the user definition generates. Reversing 
them gives you the group belonging to the user, instead of the separate 
group

Oh, we can have the user definiton check for exisiting boot code, 
of course

Or is the configuration always processed in the order of the module? 
In that case, there's no problem

websockets coming to firefox in next release
http://ajaxian.com/archives/firefox-4-html5-and-native-json-store

After some serious benchmarking with Redis using a couple of php 
libraries, it's become clear that a Cheyenne + Rebol blocks is by 
far the fastest solution.

I think the main issue with Redis is the I/O between PHP and Redis 
itself.. the only way to access Redis data is via a port.


ie: Apache <-> PHP <-> Redis  .. each I/0 adds precious milliseconds

Cheyenne has an advantage, as Rebol blocks are native.


I must admit, I didn't expect these results. Accesss to data stored 
within Rebol blocks  is crazy fast... and very flexible.

I have  a rebol block with 10 million integers.. i can crawl the 
entire block with a foreach [a b] loop in 0.17 seconds

Now if i can just figure out how to reduce the large block into a 
few smaller blocks, and run parallel foreach loops, it will be a 
killer app.

Terry, if you are able to simulate thousands of users, that would 
be a killer app too.

Well, as Doc pointed out, 1000s of simultaneous users makes for a 
VERY popular website.. take the millions  of $ and work it out as 
necessary.

I'm looking for say 100 users able to work on a very large datasets 
quickly.

Doc, would it be safe to say processing large blocks are non-blocking 
with Cheyenne?

What do you mean by that? Cheyenne's UniServe task masters run in 
separate processes, so when one request takes time other task masters 
handle other requests, but within one request your code is executed 
serially, the way you program it. REBOL is single-tasking, after 
all

Terry: you need to be more specific, "processing" is very vague. 
Also are you talking about running code in CGI/RSP or in Cheyenne's 
main process?

Kaj: I keep having big issues starting Cheyenne as not-root user, 
the debug files are created while Cheyenne is stil root...The issue 
is deeper. The UNIX port number <1024 limitation, is a true PIA. 
Does someone know if there's a way for a process not started as root, 
to temporary get root privileges for opening a network socket?

Doc, the way that normally works (eg. apache) is that you start as 
root, open the socket, then drop privileges.

Yes. However, I had no further problems, because the main Cheyenne 
process keeps running as root, and can thus answer port 80. Are you 
doing it differently, Doc?

Well, that is to say, I couldn't test it to the end, because I currently 
have to use View for the library interface, and my graphical Linux 
doesn't fully support X under non-root yet, so maybe I hadn't advanced 
as far as your problem

I assumed it was just my Linux not being fully configured yet

Is there a core version of cheyenne for windows that can run as a 
service without issues?

Has anyone created any multi-tenanted applications?

what would cause sudden 403 Forbidden errors on certain pages? Everything 
was fine, restarted the server.. 403

403 is also Access Restricted, so it depends what's in your settings.

But as I'm checking the sources, in Cheyenne itself there is no code 
forcing 403.

nvm - i had a rogue apache service firing up on boot.

Has anyone run pmwiki or any of the other php wiki's with Cheyenne?

All the buzz in javascript land of late is around  Node.js and Redis.. 
And I've been in a heated debate with the Redis group over the latency 
issues. Cheyenne + Rocket (a Rebol key/value store I've been working 
on) makes the Node.js + Redis throughput look sick.
Why do these inferior technologies always get the buzz?

anyone used Bernstein's daemontools to control Cheyenne?

I did my own using SSH and a few server-side scripts and tricks.

I can start/restart the server without it requiring to be setup as 
a daemon.

and without requiring any active ssh session open.

by active I mean persistent.  even when I close the ssh session cheyenne 
remains running.

why not use the embedded remote console? cheyenne/UniServe/services/RConsole.r

you can use the remote, if the server isn't running ;-)

can = can't

humm... true.. 8-)

the usual problem is that when you do a remote login, whenever you 
logout, any application you launched gets killed with the session 
when it quits.

Cheyenne should just be started by the system's init scripts (or 
whatever equivalent on Windows)

If you don't want to kill your running apps on session end, use  
"disown" command.

Would it be possible to encap cheyenne with webapp files into single 
exe?

daemontools are for keeping things going if stopped, as well as starting 
them.

webapp.exe is on Doc's todo liset

Hey Doc.. I can access a websocket page from the interweb, but the 
socket communcations isn't working at all? However, it works fine 
accessing on the local network? Any ideas?

Maybe it's some FW issue.

Is there a core version of cheyenne for windows that can run as a 
service without issues?

 AFAIK, encaping Cheyenne with enpro should work ok with Windows XP 
 (not sure for Vista/7).

Has anyone created any multi-tenanted applications?
 Could you be more specific?

Has anyone run pmwiki or any of the other php wiki's with Cheyenne?

 Yes, Cheyenne docs wiki is running on pmwiki : http://cheyenne-server.org/wiki

anyone used Bernstein's daemontools to control Cheyenne?

 I think some french reboler did in the past, but not sure it was 
 with Cheyenne, try searching through the french rebol forum.

I can access a websocket page from the interweb, but the socket communcations 
isn't working at all? However, it works fine accessing on the local 
network? Any ideas?

 Is there any HTTP proxy in between? Does it require SSL? Cheyenne 
 current websocket implementation doesn't support HTTPS yet.

good to see pmwiki working .... I hadn't realized before when on 
your site that it was a php wiki!

BTW, it looks like your "print" link menu item doesn't do anything.

 Is there any HTTP proxy in between? Does it require SSL?
 - No proxy, no ssl.