World: r3wp

Dockimbel: could you work on the log file location / compressoin 
stuff?

imean were u able to work?

not yet

as im browsing nodejs, i see so many features implemented which is 
missing from cheyenne, but i have already wanted to use, which makes 
me seriously consider switching to node.


cheyenne has the right foundations, but i feel it requires too much 
studying of the internals to extend it in a practical way.


i think it's better if u focus on red. that's something which not 
many ppl can and want to do, but would be able to affect the world 
big time.

for example i was mapping a company directory service under each 
companies own subdomains, just to allow them to contribute to this 
shared directory of companies.


but as i see there is a cross origin resource sharing module for 
nodejs' connect framework, which can take care of sending the access-control-allow-origin 
headers

Red has even less features for the moment being, and switching from 
NodeJS to Red will be harder than from Cheyenne to Red

i think it's more a economical usage of our resources if we use nodejs' 
ecosystem for the next 1-2yrs and copy it to red later.

How so? You'd have switching costs twice in 1-2 years

im not sure were talking about the same switching.

i just have a couple of kilobytes of code in rebol behind cheyenne.
other part of the system is in angularjs.
im trying to switch that little backend to nodejs from cheyenne.

as a result im hoping to have this cross origin services, compression, 
digest auth working and have a convenient url router too.

So you'll have costs switching all that to Red later. In practice, 
this usually simply doesn't happen

i was not thinking about switching all this to red... but i would 
love to write newer projects on top of a red based async webframework, 
rather than javascript...

even the javascript guys hate javascript, i think. that's why they 
made coffe-script, which looks more like rebol, except they borrowed 
the indentation from python to achieve less syntax

Doc, any plans for a JS backend that compiles Red to JavaScript?

French presentation of Cheyenne available here on http://www.red-chronicle.com
| Documentation

this cross site request crap would require the handling of OPTION 
methods too for the so called preflight request which tells the browser 
what can it expect from the "other origin" -- just saying

With a server side framework you don't need this

It's one of the consequences of moving functionality to the browser

hmm... ok, i step back and think about it. thx, for ringing the complexity 
alarm! :)


on the other hand, i just saw there is https://github.com/nodejitsu/node-http-proxy
which is a reverse proxy for nodejs.

if u remember, i was missing this functionality from cheyenne too.


i think what carl was aiming w rebol is happening w javascript / 
json now...
it's not as advanced as rebol, though, but it's

Yes, the good-enough-trauma

AKA Worse Is Better

Red is the only way we have to save a piece of the dream

I've just switched NginX in front of Cheyenne to do the reverse proxying, 
and other things

well, i was successfully using the 5k mini webserver as a plain/text 
webservice ~2yrs ago and i could even chop it down to ~2kb, but in 
my current project the scenario is not very simple...

switched nginx
? u mean switched TO nginx?

No, NginX is the reverse proxy for Cheyenne (and Fossil). Several 
people here went before me

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.