World: r3wp

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 :-)

what do u use then? direct output from .r scripts? (i used that too 
so far because the templating is done on client side w angularjs, 
so the backend is pure json(p))

hmm... how can i map a directory under a certain path in vhost? im 
trying this:
yp [  root-dir %~/p/ob/yp  alias "/public" %../public/ ]

then for curl http://yp:8080/public/angular-0.9.15.min.js  i get

HTTP/1.1 301 Moved Permanently
Location: /public/angular-0.9.15.min.js/

wtf?

i remember seeing something like "/some/path" [ options ] in a vhost 
config block, but i can't find anything about it now

i did a
~/p/ob/yp $ ln -s ../public public

as a workaround, but how can i achieve the same from the config file?

im guessing that i cant point out from the root-dir for one, but 
why?

I use my own app platform, which is based on a pervasive templating 
system

It's in REBOL, so the templating is done on the server. The concepts 
actually overlap with AngularJS quite well, but it's serverside

Kaj: overlap w angular? as in u have 2 way databinding? do u have 
some example sites?

It depends on the definition, but that's the direction I'm moving 
in. The structure is roughly MVC, and I have a method of updating 
web pages without the browser having to know what it means

Try REBOL is the first dynamic site I've done that way. You stay 
on the same page, send in data to a service interface and get data 
back that updates arbitrary parts of the page

So you get conceptually the same effect as AngularJS, but it goes 
through the server. One of my goals is to maximise the REBOL part 
and minimise the JS part. AngularJS pulls everything in the client 
and is thus tied to JS and the browser incompatibilities that go 
with that

Obviously it's nice to be independent from the server - if you can 
get it to work cross-browser. But I always thought we have View for 
that. Also, it seems nice to have the browser do input checking, 
but if you want a robust app, you will have to get the server to 
guard its own consistency and end up writing all input checking twice

In general, I notice that almost all web platform projects (and operating 
system projects for that matter) are either very focused on the server, 
or very focused on the client, apparently depending on the preference 
and abilities of the founders. This doesn't make sense to me: a network 
app by definition needs to deal with both sides of the connection, 
and find the best balance

i wish rebol/view was that good to replace the browser, but im typing 
this on a mac w ugly, aliased, miniature fonts and i can't even use 
the maximize button because it fucks up the screen size and layout...

angularjs is surprisingly backward compatible, btw... but serverside 
validation is still a must of course.

in this particular project we tried view, btw, but we need it on 
a tablet later in a warehouse, so /view is not an option at the end 
:(