World: r3wp

It's more or less the original web server that did the ultra efficient 
event I/O that NodeJS is now also doing

JS backend: I thought about that, it should be very doable and probably 
easier than to support a new CPU target. It would require some deep 
changes in %emitter.r to make storage for global data platform-specific 
(this change would be required for other real VMs support like JVM, 
CLR or AVM2). I've planned to use one of these VM for starting such 
change on a separate branch of code, as I would probably work on 
it from time to time during next months in experimental mode.

New revision 144:
- added -f option to change working folder location
- added -c option to load the config file from  a new location

See %changelog.txt for more details.

Tested only on Windows in encapped mode, will test on Linux tomorrow 
(sleep time here).

Re compression: after a deeper look, there is no way to support "on-the-fly" 
compression of static files without totally killing Cheyenne performances. 


If it is done in a mod, it will totally freeze Cheyenne on every 
CALL. If it is done in an handler, most of benefits from the async 
I/O main engine is lost, and Cheyenne will be limited to serve small 
files only (they will be transfered from workers to main process) 
and limited to 1 request per worker (so if 4 workers, maximum simultaneous 
request = 4, all others will be put in queue and waiting).


So, the only way to support static file compression is by pre-compressing 
files and adding some config options to let Cheyenne know which files 
are compressed (file sufix alone is not enough). Pre-compressing 
means having to manage compressed versions of static files (When 
and how to compress? Where to put the files? When to delete them? 
etc...)

Nginx might have a good solution to that problem, but if Cheyenne 
has to copy the nginx approach and performances are required, I guess 
that it would be more efficient to just use nginx as front-end directly 
for static files.

Dockimble: I thought u got that performance is not an issue.

Streaming out 80kB of compressed data over 10-20kB/s connection takes 
seconds, while u can compress it in less than a tenth of a second.
the difference is 100x


even if it halts the worker process for a few 10ms, it still worth 
it.

it's not just better than nothing. it's a lot lot better than nothing...

especially if u think about that u made the introduction of another 
component to the system architecture unnecessary (no need for nginx)

we did a test on mobile net and it took around MINUTE to load all 
the crap. so i doubt compression could make it any worse but better 
instead.
i mailed u screenshots of the network activities

I read it more that implementing "on-the-fly" compression would affect 
all current requests not just the single reuqest being compressed 
at the time

I ran a test of Cheyenne as a service on Windows 7 and have managed 
to lose the system tray icon to turn it back to running as an application. 
Any suggestions on where to find it?

This what I did in total:
1. Run cheyenne as administrator from my user account.

2. Use the system tray icon to change Cheyenne to run as a service.
3. Log-off.
4. Check  Cheyenne was runnning.

5. Log back in to my user account - no Cheyenne icon in the system 
tray.
6. Log into the Administrator account - it wasn't there either.

onetom: I think there is any easy way to implement nginx to give 
you what you want without interfering with your current Cheyenne 
setup. It is to use nginx on another port (say 8000) to serve all 
your .js files. I've found nginx easy to install and configure. The 
only change you'd need to make to your system is to update the urls 
of the javascript files in your html with the port number.

There shouldn't be any performance penalties with this approach (no 
reuqest forwarding) and it is available now.

PeterWood: The point would be to keep the architecture simple.

I don't want to introduce another component, unless it gives a lot 
of value.

otherwise, im very well aware of how simple nginx is. i used it a 
lot as a frontend for rails/sinatra projects and even php, then once 
as an upstream for haproxy too.

but exactly because it's so simple what im expecting from it to do, 
i dont feel like adding it to my application stack which currently 
consist of rebol only...

Tamas, Cheyenne's main usage scenario is not in using it as a stream 
server. If you want a server which should provide large files for 
many clients, I recomend NginX as a frontend as well. Btw. you can 
see that many WordPress providers replaced Apache with NginX to provide 
cached content.

Oldes: serving a non minified 300kb javascript framework doesnt sounds 
like a "stream server" scenario.

on the other hand, cheyenne is doing the streaming in 2kb chucks 
something, iirc.
it also does compression on rsp generated pages.
i don't really understand what is all this resistance...

but, nevermind, i will try nodejs first and see how these things 
work there, how hard is it to integrate the various implementation 
techniques into the middleware stack

Peter: When Cheyenne is in Service mode, the tray icon app is a second, 
separated instance of Cheyenne. If Win7 is not starting the second 
instance, you need to start it manually to get the tray icon.

Thanks.

Streaming: Cheyenne is sending big files in chunks of 1KB up to ~64KB, 
depending on the connection. It can serve multiple big files, but 
the scalability might be limited by the blocking disk read accesses 
delays. Other C-based servers can use OS API for async disk read 
accesses that we can't integrate into REBOL native ports.

onetom: "i don't really understand what is all this resistance" Well, 
you will probably be the only one to use that feature. Others would 
just install nginx and have maximum performances for static files, 
compression and SSL support.


I will add the compression feature in main process today, but will 
strongly discourage everyone from using it in the documentation (to 
avoid deceiving users in the general use case).

fair enough.

I have tested successfully config file relocation/renaming and Cheyenne 
working directory relocations both on Windows and Linux. Let me know 
if something is not working as expected.

I have tested using the encapped version only, it might work fine 
from the sources too, but it is not guaranteed.

I'm getting a *very* weird problem launching cheyenne from win7.


using a clean download of the latest build sources, if I try to start 
up the cheyenne.r by double-clicking on it in windows, it fails. 
 

no tray icon appears, the rebol process is running buts its dead 
(no pages are served, and no workers are launched).


if I try to run it a second time, I get the console which tells me 
it can't open the rconsole and logger ports (so cheyenne actually 
did start)., but the "no response" flag appears on the window title 
and its as dead as the first instance (I even get the busy mouse 
cursor treatment). 


but if I start it from the command-line, using the exact same command-line 
that I see in the task manager, I have no problem!


to make this even more strange, dragging the cheyenne.r script icon 
on the rebol.exe icon, launches cheyenne without any issues!

launching it from my editor's automated script launching setups also 
works without issues.

all of these show the exact same command-line in the task-manager 
(which includes the -qs rebol flags).

note, I am *not* running cheyenne as a service.

Questions:
1) can any one else replicate this (am I going mad ?  ;-)
2) why does this happen?
2) can this be solved?

I never tried that, as all my .r files are associated with my code 
editor.

Changed association to point to rebpro.exe 2.7.8, clicking on %cheyenne.r 
launches and it responds flawlessly.

I must add that my user account has admin privileges, so your issue 
might be related to user rights restriction.

Maxim, I wonder if there is anything in the system log?

i happen to have a win7 laptop around. i will git it a try, if u 
can be more specific about the versions of ur environment
run http://cheyenne-server.org/tmp/cheyenne-sources-r146.zip
with http://www.rebol.com/downloads/v278/rebol-view-278-3-1.exe?

i happen to have a win7 laptop around. i will git it a try, if u 
can be more specific about the versions of ur environment
run http://cheyenne-server.org/tmp/cheyenne-sources-r146.zip
with http://www.rebol.com/downloads/v278/rebol-view-278-3-1.exe?

rebol-view-278-3-1.exe doing an svn checkout  (r146) which should 
be the same as the .zip

win7 (not yet upgraded to sp1)  with UAC turned on.

dir opus has a mode where you can elevate the explorer to have administrative 
rights enabled (which is independent of being an admin user) and 
this doesn't change anything.

In the database connections, can Cheyenne connect to an odbc dnsless 
connection?

dsn-less

Cheyenne just calls "open" on the URL you pass in the databases block, 
so if you can connect from console, Cheyenne can too.

It has to be a url?  In a dsn-less connection you provide a spec 
block

You are lucky, Cheyenne does not check the syntax of the 'databases 
config block, so a block! should work (as long as it is accepted 
by OPEN).

:)

Config question on stack overflow:
   http://stackoverflow.com/questions/6367201

Maarten, this is the Cheyenne group.

Yep, didn't see it first.

Question stands: can I encap an embbed Cheyenne, and if so, how?

Should be possible by following the embed documentation, but I've 
never done it

In httpd.cfg, activate embed module :
modules [
embed
]

From http://cheyenne-server.org/wiki/Config/Struct:

Note that the embed module, if activated, will disable all the other 
ones (required for proper working of embedded mode).

So far, that's I don't know either :(

Hi Maarten, been quite busy these last days, nice to see you back 
in REBOL world.