World: r3wp

the funny thing is with this angularjs framework is that most of 
the code are static files...
hardly any rsp processing is needed.

small json is generated dynamically, but even the frontend text dictionaries 
are static javascript files,

and angularjs is doing the language switch live without any server 
turn around...

Yeah, because the dynamics are moved to the client

FYI, I plan to work this Sunday on:
- adding proper log file relocation ability for UNIX platforms
- make a draft mod for testing static file compression support

awesome!

Cool

That's nice!

studying v8 + node + express + connect
looks like a great architecture... i wish it was rebol :)

How does it integrate with AngularJS?

i would just use the router and the bodyParser middle wares from 
it, so it does the json parsing back n forth and the restful url 
parsing

https://github.com/joyent/node/wiki/modules#compression
these are the kind of compression solutions for nodejs

they also have a plain gzip command line utility based solution too

The zlib binding is written in C++, with templates

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.