World: r3wp

(Requires Chrome beta..  http://www.google.com/chrome/eula.html?extra=devchannel
(windows)

4.0.302.2 dev

works great :-)

If you want to see the debug tools in Chrome, hit CTRL-SHIFT-i

hehe looks like they hired the firebug coder to build the debug tools 
in chrome ;-)

yeah.. i still occasionaly use Firebug.. but rarely

Terry: echo is much faster now (1-2s delay only). 


For the 30s pause, that might be caused by a network timeout on a 
sync port action. 
>> system/schemes/default/timeout
== 30

yeah, I need an async https port.. still getting overlapping tts 
broadcasts when two or more people submit at thesame time.

It's like people trying to talk over one another, using the exact 
same voice :)

The delay is quite a bit less now - not too bad. I noticed that the 
last word (or part of one) seems to get cut off? Are you guys seeing 
the same?

yeah last word often gets cut on shorter strings .. need to get xml 
via https:// POST working for a solution.

It seems Rebol is causing the problem with the last word getting 
cut off..  I use a read/binary - write/binary of an .ogg file and 
the last bit is cut somehow?

Does it work outside of Cheyenne?

the read/write is fine.. I think it might be Cheyenne's dishing up 
of .ogg files.. ?

couldn't try it ..your server was offline

hmm.. maybe Chrome

Cheyenne has nothing against .ogg files. Are you removing ogg files 
once sent?

If Cheyenne would refuse .ogg files, then it would belong to Belief 
Systems :-)

ok.. did some tests.. it's Chrome.

Try this with FF and Chrome

http://shinyrockets.com/delme.html

(running on Apache)

although i did add the ogg to Cheyenne mime-types

http://code.google.com/p/chromium/issues/detail?id=33139

huh, I have to comment something.. I went looking what curecode looks 
like .. and founc this one http://curecode.org/rebol3/view-tickets.rsp
.. when I am clicking links the page reloaded so quickly that I couldn't 
determine if you are doing an ayax call or the whole page is reloading 
and I can't see it.. I also noticed this on my cheyenne projects. 


I don't get how you managed to do this. There are numerous servers 
outthere and rebol is not the fastest language and I haven't seen 
something like that anywhere?!?!? I mean I think also the static 
pages that you load from some webserver take some more time.. ?

I don't believe that cheyenne can be **THAT** much faster so that 
it's so visibly obvous. Do you send the page in some specific way?

:-)

No AJAX calls, nor other tricks. It's very fast for several reasons 
:
- almost no images.

- no JS lib to load and no JS code to execute when page is loaded.
- server is far from being overloaded.

- MySQL backend is very fast for read accesses (MySQL has a very 
efficient caching system for queries).

- Cheyenne RSP engine *is* fast (RSP scripts are compiled to REBOL 
code and generated code is cached in memory)

The result is so fast that it looks like a RIA application, you hardly 
notice the redraw delay.

yes, I was intentionally looking but I couldn't see it-.. I had to 
select the header to see if selection will disappear

hm.. maybe it's the combination of vary fast app server with everything 
in ram and caching and also unbloated web development which rebol 
programmers maybe practice more than the regular webdevs

yes, with curecode I also had to account the fact that it's querying 
the database and it's still so fast.. anyway .. it's very good feeling 
to have responsive webapps

I agree that the application design counts also, being bloat-free 
helps a lot.

my cebelca,biz app is also quite big and "fancy" and uses only 1 
14x14 image file (icon for filters) :) ..

curecode is also visually full while very clear and clean

but it's not only that, I made apps like this in php and python before 
but they still loaded normally .. the fast loading in my cheyenne 
apps vas also noticed by others with comments "how come it's loading 
THAT fast" ? .. I just said "wasn't me :)"

I wonder how far this kind of approach can be used instead of JS-based 
RIA.

well JS still gives you interactiviry on the client level which would 
be hard to fully duplicate with the server (overlays, popin div-s 
...)

I must admit that, a few years ago, I was the first surprized when 
I put only my first RSP scripts, even more when I added db queries...

only=>online

cebelca.bit iz 90% rendered by the javascript on the client side 
..

but with or without that fast server  is much much better than slow

Right, a lot of UI effects are easier to implement in JS rather than 
generated server-side.

I will send you one DM :)

hehe, thanks :-)

Is there anything stopping a R3 uniserve and cheyenne?

yes, the lack of non-finished tasking model

I think that Doc is not willing to port it to r3, unless threading 
can be used ...

Did R3 reached beta?

nope

Ok nice, so I don't have to list all the other requirements. ;-)