World: r3wp

that request takes several seconds to download in the mentioned scenarios..

those 60ms are worth it if the connection is slower than ~4MByte/sec

It is a waste of server resources.

depends on your usage scenario

even my amazon micro instance is idle mostly...

it would be a waste if it would be happening constantly..

if you have no significant load but your users are typically accessing 
over relatively slow lines, it would result in a significant speedup.


i'd certainly not enable such a thing per default, obviously. but 
for some scenarios (like onetom's, probably) this relatively slow 
on-the-fly compression using CALL would still be worth it.

what kind of connections do u guys live on?

you mean server connections?

no, client connections.

6MBit/s

(from home)

even in the singapore hackerspace we have only 10Mbit, which is far 
from being 10Mbit to most directions,

but at home we just have ~2Mbit -- hardly enough to watch utube realtime, 
then in thailand phuket 2.5Mbit, but maaany many times im on edge 
10-25kB/s or just 4kB/s GPRS

Yep, it's a problem that most software is developed by Westerners

the small instance im running this shit from is a small ec2 instance.

it compresses the mentioned file in 44ms for the 1st time, then ~28ms 
subsequently.


no matter how i look at it, it does worth to support this for the 
usual text mime types, especially within the 10kB - 10MB size range

Kaj: whats u usual client downstream speeds in the netherlands?

s/ u / your /

I'm on 20+ Mbit/s here

But I pretend it's way less when programming :-)

how do u pretend? in ur mind or actually w some traffic shaper? :)

is it really that fast usually?

Well, I don't even pretend. I just design things to be as efficient 
as possible, and that means it almost never needs the speeds here

my macbook could still saturate it though 6 times

The nice thing about this connection is that it's (mostly) symmetric. 
But most people here have downstreams roughly in that order, although 
there's also 2 and 100 MBit around

You're right about the speed relations. We run ancient hardware, 
but what usually matters is network speed

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?