World: r3wp

I'm creating an API, and each api word maps to a single rsp page 
inside a %rest directory.  It is up to the rsp page to decide which 
actual function is being called, and to deal with all the parameters.

And also to deal with authentication.  Basic authentication will 
be used for each api call .. and the whole site will be behind https.

so, DELETE /@api/fax/jobno and GET /@api/fax/jobno both map to the 
same rsp page.

This scheme sound okay?

I'm not a REST expert, but your code looks ok to me so far.

Tunneling Basic authentication through SSL is a wise decision.

What's the purpose of the .cache.efs file  that gets written . I 
think this was the file I saw before that I didn't have writes to 
write to the local filing system

rights to to write

It's the cache generated for encapping Cheyenne by my encap-fs library. 
It's needed only for encapping.

Is the captcha library still working for other people on v 19 ?

Not working so far for me.

fordidden: charset "iIl1LoO0*àçèéêù"
	allowed: exclude charset [
		#"0" - #"9" #"A" - #"Z" #"a" - #"z" "@àçèéêù*"
	] fordidden

I think you meant 'forbidden

set-fonts-path: func [value [file!]][fonts-path: dirize value]

but set-fonts-path is not called inside 'captcha.r

I've got this in app-init.r


on-application-start: does [
	;--- add here your library / modules loading
    do %private/captcha.r
    captcha/set-fonts-path %private/fonts/
]
but for some reason the do %private/captcha.r is not firing.

More testing. If I remove this code form app-init.r it does not work.
If I don't have 

do %private/captcha.r
captcha/set-fonts-path %private/fonts/

also in my login.rsp, it doesn't work.

So, in summary I need this code both in app-init.r and in my login.rsp

Didn't tested the Captcha code with v19, as a workaround try to move 
the code from on-application-start to on-session or use *do (instead 
of 'do) in on-application-start.

tried that too

*do

I think ... will try again.

Nope, neither of those work.  I neeed to have the code in my login.rsp 
page as well.

Tried again ... *do does work afterall.

Either that or I'm having a very non-deterministic day

Looks like I'm going to have a very few pages as entry points to 
the application ... and so all the code will only be in a few pages.

Anyone got a suggestion on how to modularise the app even more ..

I guess the more general question is how does one write large apps 
in RSP ...

the same way you would a normal rebol app? there isn't much difference 
to RSP from running functions in a console.

Think about RSP as just the display layer. Your application should 
be in .r script like you would do for any other REBOL app.

The View in MVC?

Right.

Ok, that makes sense ... I didn't want 10 pages of code between <% 
%> !

Build your app as it could have an alternative VID UI instead or 
just HTML.

That would be bad pratice.

well, I guess there isn't much published on what is good practice 
on writing RSP pages :)

And i've never done PHP etc

True, but's it's no different from best pratices in ASP, JSP,...

No experience with any of those either ... but I've got a clue now 
:)

What exactly is the difference between 'do and '*do ?

ie. when should I use '*do ?

'*do is just the native DO.

I know

So, why should I need to fall back to '*do ?

Webapps are, from v 19, contained in their own context (object!). 
'do will first bind the loaded code to the webapp context before 
executing it.

and if you're not using a webapp?

*do is just a fallback, if 'do is crashing your code ;-). It should 
be used, but as I had some context issues while testing with my own 
webapps, I've added it as a workaround while figuring out how to 
fix those issues.

if the RSP is not inside a webapp, then 'do will just call the native 
do.

Ok.  Thx

it should = it shouldn't

need R3

badly