World: r3wp

hmm... cheyenne binary and the source works differently w the same 
configfile.
$ cheyenne --version
0.9.20.129
WORKS
latest source doesn't work with the following config:

modules [ internal extapp static action rsp alias ]
globals [ listen [8080]    bind RSP to [ .r ] ]
guan-huat [ debug root-dir %./ alias "/docs" %jsondb/to-json.r ]

im testing w $ curl http://guan-huat:8080/docs/test/1

bind-extern makes no difference

oh, the problem is im getting a 404 if i run the source version of 
cheyenne

Are you using sources v0.9.20.129 too?

Hmm, shouldn't make much differences between revision 129 and latest 
135...

You should search in the Cheyenne console logs for "[HTTPd] Translated 
file:" to see what file Cheyenne is trying to read. That should give 
you a clue about what is causing the difference.

no, v0.9.20.129 is binary

Translated file: %./jsondb/to-json.r
in case of the source version; so there is no differnece there.

http://piratepad.net/KkvkZ9AtME
i put the correct and the incorrect logs here

i pasted the command lines too

it works if i copy over my stuff into cheyenne's dir and start cheyenne.r 
from there

I guess Cheyenne should be able to figure out where are his own files 
if launched from another folder. I need to setup a test configuration 
on my linux box to investigate such case.

But tomorrow, too late now here. ;-)

Got you email, thanks.

i thank u.

it's 6:34 here, but i slept most of the day coz im close to having 
pneumonia again...

hmm... sessions are not persisted anywhere?

anyone wrote some memcached or tmp file storage for sessions?

They are persisted on disk if you specify in globals section of config 
file:

    persist [sessions]

noted here: http://cheyenne-server.org/wiki/Config/Persist
is it ok, or there is a better place for it?

That is the right place, thanks!

how can i implement a login form without sending the password in 
clear text?

should i ask for digest authorization?

switch to HTTPS.

i can't find the "switch" :) ... i hate this cert and crl based pki 
crap...

any drawback of using http digest, beside not being able to provide 
a nice login page?

Not AFAIK.

http://www.berenddeboer.net/rest/authentication.html

this is a nice walkthru of the http auth theory with examples on 
how to do cross browser logout, forgotten password page, auto logout, 
etc etc

doc, I've been able to add a config for the worker count (min/max) 
within the httpd.cfg file.  it took some doing and a lot of file 
navigation to under the deep secrets of cheyenne's startup processs 
 ;-)

I thought it would have been easy, but it took a bit of doing, since 
the boot process must  *init*  the httpd.r, then setup the config 
and then init the rest.


I could have made it ugly by calling things manually or restarting 
workers, etc... but I ended up adding 2 new options to the uniserve/boot 
spec.


init and no-init which allow us to select what is initialized, without 
knowing the full list of services.

so this code within cheyenne.r:

			shared/pool-start: 	any [
				all [flag? 'debug 0]
				all [flag? 'workers args/workers/1]
				4
			]
			shared/pool-max: 	any [
				all [flag? 'debug 0]
				all [flag? 'workers any [args/workers/2 args/workers/1]]
				8
			]
			shared/job-max: 	1000	;-- CGI/RSP requests queue size


   boot/with/no-wait/no-start [] ; empty block avoids loading modules 
   from disk

----------------------------------------
now becomes:
----------------------------------------


   boot/with/no-wait/no-start [init  [httpd]]   ; empty block avoids 
   loading modules from disk
			shared/pool-start: 	any [
				all [flag? 'debug 0]
				all [flag? 'workers args/workers]
				select services/httpd/conf/globals 'min-workers
				4
			]
			shared/pool-max: 	any [
				all [flag? 'debug 0]
				all [flag? 'workers args/workers]
				select services/httpd/conf/globals 'max-workers
				8
			]
			shared/job-max: 	1000	;-- CGI/RSP requests queue size

   boot/with/no-wait/no-start [no-init [httpd]] ; empty block avoids 
   loading modules from disk

note that this is for a version prior to the latest r135. (I'll update 
the above when I update to r135)

do you want me to commit the changes once I've updated to r135's 
support for min/max workers on the comand-line?

hum... I guess the max workers for debug should be 1  :-/

Most comments are lies. They don't start out to be lies, but gradually 
the get out of date. You might say that developers should be disciplined 
enough to maintain the comments; but this is not reasonable. Comments 
have no detectable binding to what they describe. If you modify a 
function, you have no way of knowing that 1000 lines above you (or 
perhaps in a different file) there is a comment that contradicts 
what you are doing). So comments slowly degrade and turn into misinformation.

 -- http://www.coderanch.com/t/131147/Agile/Clean-Code-Handbook-Agile-Software

u just demonstrated this principle very well ;)

That's an interesting viewpoint. He starts his post with:


I think it would be better if the code were not complex. I think 
it would be better if the code was understandable at a glance. I 
think the effort of writing a comment for complex code is misplaced. 
The effort should be expended on making the code simpler and easier 
to understand.


And we can add: produce the code using a language, that's easy to 
read and understand.

Max: I am very busy today, I am not sure I will have time to review 
your code now (you should send me a copy of the changed files first 
BTW). As you could see, supporting such feature at the config file 
level is complex because of config file being loaded only when HTTPd 
service starts (for historical reasons). I am not sure that initializing 
the HTTPd service ahead is a clean solution (the boot/ line has become 
a bit hard to read with this /no-start flag that loads and init HTTPd 
service...).


The solution I had in mind was to extract the whole config file loading 
from %HTTPd.r and put it in %cheyenne.r. This is a deep and complex 
change, that is why I was waiting to have enough time to do it in 
a single working session. Anyway, I will examine your solution first.

onetom, are you talking about me?   cause there are no comments in 
just about all of the cheyenne code.  this is why its often complicated 
to play into the deeper roots of the app.

Maxim: i was just talking about the comment rot effect. where is 
the empty block here? :)

     boot/with/no-wait/no-start [no-init [httpd]] ; empty block avoids 
     loading modules from disk

ah, actually in my code it was updated  :-)


the post was sent in error, as I was editing it, specifically ... 
editing the comments   :-D

is there a way to show errors as text? somehow it happened to me 
yesterday but no idea how could i achieve it...

(for now im switching to the console each time to see what's the 
error, so it's not a big issue of course...)

how can i define a common layout for my webpages? should i split 
the layout into header and footer and use include explicitely on 
each page?

or make it a webapp and wrap the buffer in the on-page-end event?

hm... daaamn, why is the webapp root-dir is not relative to the vhost 
root-dir? why should i specify a vhost root-dir if i use only webapps 
in it?

ehh... sessions are not lazily created either... and i couldn't even 
set-header 'set-cookie none session/end because it sends down 2 cookies 
then...

it's neither lowlevel nor convenient.. luckily i know how these things 
work in the ruby world, so i hope i will have enough time to bring 
the good things over...

Cheyenne supports SSI

ahha.. plus 1 concept though, but thx for the remainder, i will give 
it a try!

Agreed, I don't use SSI myself. I don't know how easy it would be 
to replicate with RSP, because I don't use RSP, either :-)