World: r3wp

might still be much faster than a db call.  but the real game-changing 
aspect of mod-remark is that a document in ram, will only render 
parts of itself which are changed, or which cannot be cached, so, 
unless you've actually changed a parameter, it knows that it hasn't 
changed and will not need to ask for the broker to give it back the 
value.  in fact, it wont even process that part of the page, only 
using the data in its local node cache directly.

header/ footer / current login state box/ static page content... 
this can be shared accross sessions, across the entire site, or as 
granular as a single page request.

a news reader could have all the news items cached already and all 
its doing is assembling those which are matched via the request... 
really only doing a fast rejoin of many items, and then a rejoin 
of header news and footer and then spit it out.

all the code which was originally called to create the news items 
is skipped... until some site parameter changes how the news items 
are built, which will automatically cause the news item to reprocess... 
 but on the page and server side, nothing special needs to be done. 
 liquid's internal caching will fork the processing by itself, and 
then start serving the new cached data the very next time any single 
news item is asked for again.

That's quite close to how RSP are working. Each RSP script is compiled 
to optimized REBOL code and cached in memory. A RSP request will 
then result in evaluating the REBOL code which mostly just append 
static and dynamic parts in the output buffer.

nice.

the difference is that with liquid, its explicit, and I can explicitely 
share some data accross many scripts, but just some of them.    the 
headers can be half cached, where each page uses half the common 
header, inserts its local menu into it, and that header is now permanently 
cached for all further requests of that page, but it used part of 
data which was already cached by another page.

the current issue is trying to share the cached data between different 
handlers... which pits me against a liquid value broker, but its 
the creation of the data on the broker which might become complex... 
so not yet shure how I will proceed..

with threads, this issue would be much simpler to solve.

Max, applying dataflows principles to a web framework looks really 
appealing, when will be able to see some demos?

I am aiming for sometime next week, just a few simple prototypes 
to explore how to handle the difference in  nature of web requests 
opposed to persistent  data.

I am pretty sure I wont tackle handlers for a while...  because of 
the code sharing complexity added.

if the lazy processing equates to as much saved processing as I have 
seen with graphics work so far, I might not even need external handlers 
to handle many requests/sec.  It would be nice if you could pit your 
stress testing setup against mod-remark once it starts actually doing 
its thing.  :-)

at this point, this is still all research, but the more I apply liquid 
to specific problems, the more confidence I am generating,  as it 
almost always lives up to its potential.  When it doesnt', its usually 
that I just didn't find the proper way to use it.

query-string: Ah, the problem comes from a wrong rewrite rule for 
GET requests. I need to figure out how to handle this case.


That's what I like about web-stuff: There are so many possibilities 
and places that something can fail...

Graham: Is this a cheyenne issue?
Robert: Yes, I just checked the LOG files. [...]

So, no, it's not an issue with Cheyenne.

I didn't think so

No, it's not. The LOG files are correct but I didn't saw the double 
" ?" ... Sorry, as said: To many places where something can go wrong.


Perhaps, it€s possible to throw an error if a male-formed query string 
is found.

I'd rather throw parties on *female* formed queries   ;-D

It's hard to define "mal-formed" precisely. If you strictly apply 
the RFC rules for URL, you'll find out that a lot of web sites are 
using "mal-formed" URL.

its actually a global property of php that you can change the url 
parameter separators for your site in order to fight back against 
bots and make hacking a bit more complicated.

Wouldn't that break most of JS/AJAX frameworks?

not if you edit the code so the urls match your site's separators. 
 I have come across some sites with strange separators.

but as written in the php docs... obfuscation isn't a replacement 
for real security.

so most people put their time on tackling the real problems like 
sql injection and https use properly

and use https properly.

doc, I have noticed a usage in your mods which you might want to 
change for speed reasons.


you use the word return a lot... and in my tests, it causes a BIG 
performance hit on function calling... I really mean noticeable when 
you do loop profiling ... a minimum of 20% slow down IIRC.

so instead of:

    phase: func [svc req conf][
        if declined? [return none]
        ...
        if let-others [return false]
        ...
        true
    ]

you really should be doing 

phase: func [svc req conf][
        if accept? req [
              ...
             true =  let-others? req
       ]
] 

just my two cents.

oops... reversed the emaning of that last return value...  this is 
better

phase: func [svc req conf][
        if accept? req [
              ...
             end-phase? req
       ]
]

so just drop off the end?

Doc.. just a tiny bug report.. when I am working with latest version 
in debug mode firebug reports me javascript warning: I haven't been 
digging into if this is supposed to be a bug or intentional...
>> test for equality (==) mistyped as assignment (=)?

>> [Break on this error] if (node = document.getElementById('menu' 
+ id)) {\n

yes graham, all functions return a value, a rare few return unset!.

'IF, for example,  returns none when the condition isn't true.

well, I wasn't aware of a hit using 'return.

returns enables the catch/throw as does break IIRC, so there is overhead 
in the function's calling.

so 20% of what?

let me do an example

>> s: now/precise a: func [][return none] loop 1000000 [a]  difference 
now s
== 0:00:01.032

>> s: now/precise a: func [][none] loop 1000000 [a]  difference now 
s
== -0:00:00.296

in this case the difference is 70%

now if I have a 1000 line function that either teminates in a return 
or just the value .. how much does it affect it?

the larger the func, the less hit, you can see that each function 
call is taking more time to initialise because of the return.

its just a question of maximising performance, and I know dockimbel 
is very serious about improving cheyenne's .

so, in reality it may matter very little

he is using return everywhere, without possibly realising that it 
might be affecting the whole by 5% overall.

in all processing loops I've measure a resonably high latency, to 
actualy ban it from all of my code.

so how do you break out of a loop ?

I rarely need to do so... I implement the loop conditions properly, 
usually.


obviously there are cases where you really can't live without out 
it... but as a general rule, I rarelly ever need break.

isn't there a way to set the verbose level in the httpd.cfg file?


  I want no arguments to running cheyenne, only config... using args 
  for persistent app is the first point of failure in panic maintenance.

my god cheyenne needs docs.

don't read the above as multiple instances of Doc (although that 
might be the real answer  ;-)

help! cheyenne has no trace.log file in logs, and I can't get the 
verbosity to work without using command-line args which isn't an 
option in my current setup.

what do you mean no trace.log ?