World: r3wp

The ScripTiny stuff looks very good

except bolding doesnt work as a switch (in chrome)... i came across 
this in the 3rd second of trying it...

Sounds like Chrome's fault, then

even in FF the text area loses the focus when i click on the Bold 
button

im preparing a redirect to google maps from an rsp script.
how can i assemble it in a less low-level way than this:

gmaps: http://maps.google.com/maps?

response/redirect rejoin [gmaps "saddr=" closest/address "&" "daddr=" 
params/dest]

i would need the request/query-string functionality but on my own 
parameters which has nothing to do w the request params

Untested, but should work: 

build-query: func [url [url!] spec [block!] /local cnt][
    cnt: request/content
    request/content: reduce spec
    also 
        rejoin [url "?" request/query-string]
        request/content: cnt
]


response/redirect build-query http://maps.google.com/maps['saddr 
closest/address 'daddr params/dest]

okay, thanks... i was thinking about creating an empty request somehow. 
that would have been simpler. otherwise i would just overwrite the 
content...

Automatic output compression (using deflate method)
hmm... it doesn't seem to happen for static files

is that normal?

Yes, it is only supported for RSP output.

Adding transparent compression for static resources was also planned, 
but:
- it is not easy to support efficiently

- when static file serving performance really matters, a fast front-end 
like nginx is preferable

So that feature is low priority unless we can found a simple way 
to implement it while keeping it efficient and transparent for the 
user.

we are showing around our stuff in thailand, china, hungary while 
the server is in singapore (ec2) and we are using the non minimized 
angular.js which is 320k.

there would be no reason to use the minimized one if it would be 
compressed.

but we dont want to complicate the deploy process by switching between 
the minimized and non minimized versions, however we need from time 
to time to check out the source and even tweak it sometimes

so for us it would be freaking efficient :)

otherwise we are veeeery far from hitting the raw static file throughput 
...

You can pre-compress it in gzip format, but Cheyenne will need to 
be patched to send the appropriate Content-Encoding header (should 
be part of a dedicated Cheyenne mod, that could also handle the pre-compression 
on disk).

i wouldnt even mind calling gzip every time...

it would still speedup the transfer in most situations

Well, writing such mod is trivial, the non-trivial part is avoiding 
making a mess of the web app folders or cluttering the disk with 
unused files.

In other words: give me an efficient set of rules to manage the compressed 
versions of served files and I will code the mod. ;-)

and a plain filesize check, like if 10'000 < select info? file 'size 
[call "gzip..."]

i would do on the fly compression only. for "personal" usage, it's 
a good compromise

On the fly: that scheme doesn't work for big files (think 10MB or 
100MB

if you have to re-compress the file on each request

maybe if u r serving to a 100Mbit connection from a Pentium I...

such automatic compression makes sense only for mid sized files, 
where the file needs to be seemlessly uncompressed on the other side. 
if the file is bigger, u want to be more specific about the compression 
method anyway...

on  the other hand, i just ran a
time gzip -c some.avi > /dev/null

where the avi was 1.2GB and the runtime was 1m19s on my mac laptop, 
which is

15MByte / sec, so 150MBit/s roughly.... i use wifi most of the time, 
which is below 100Mbit usually...

gzipping angular 0.9.15 reduces size from 330k to 86k in 0.06 seconds 
on my machine (with CALL/wait of gzip from within REBOL).

60 ms for a single request is way too much.

so on-the-fly compression of only static *.js *.css files would probably 
be worth it

muhhahahaaa :)

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