World: r3wp

thanks for the info about bg stuff.  right now I will be concentration 
on reformating remark so its a loadable module... a few details make 
it more complex than it could be.  (remark being so flexible).

Doc, I guess my question is, how can I pass a message from a module, 
to a Uniserve service?

uniserve/shared space or a global function.

are there docs on the shared space?

no, uniserve/shared is just an object, so you can add whatever you 
want in it using the uniserve/share function.

Cheyenne's RSP API Reference doc updated: http://softinnov.org/tmp/rsp-api.html

isn't the value triger in http protocol (4000) too low?

trigger

Are you talking about the SERVER-PORT's example in the doc ?

not in doc... it's more related to uniserve

It should be safe to push it higher in order to increase the bandwidth. 
Let me know how it reacts.

I changed it to value 10240 - the change is not so visible but I 
think it's better as there is not so many on-stream-in calls

An application is just a subdirectory right? And it always requires 
a login?

If so, is there a way to bypass the login>

Take a look at testapp/login.rsp.  I think you just need to session/content/login?: 
yes and response/redirect/ "/theapp/" to get round a login form.

always requires a login

 : no, just remove or comment the 'auth "..." part  in config file.

by default, there's no limitation. If you add the 'auth keyword in 
a web-app definition, you need to be logged in before being able 
to access any resource (that's why you get redirected automatically 
to the login page). Even when 'auth mode is on, you can freely serve 
resources from the /your-web-app/public/ folder.

application = folder (application name) + definition in config file.

knowing there is some some of admin config control panel module, 
is there a way for that control panel to send commands to other modules 
through a web page served from cheyenne?


for example, remark has a custom tags definition which can be changed 
(static & dynamic) .  if a control panel allowed integration to modules, 
I could use it to tell a remark to reload its tag definitions.


is this possible?  or will I have to create some sort of (secret) 
admin page specifically for remark somehow?

otherwise restarting the server is not very cool... maybe the admin 
page allows module restart on the fly?

I am asking,  cause I don't want to have to reload the tag defs at 
each page gen, obviously, that's part of the point of building a 
module in the first place...

fyi - in R0914 the example for the set-tray is a bit clearer so you 
can add some of the samples or other actions aside from Quit to the 
set tray (right mouse) menu.

off-topic, but - has anyone thought about abstracting rebol db access 
already? kind of rdbc (odbc, jdbc)? Especially with R3 model coming? 
db.device? - use rif, mysql, sqlite, rebdb, posgress, mssql, etc. 
The question is, if it is possible to support them all via one interface?

mikeL ahhh that could be an idea  :-)

MikeL: good idea, btw, I plan to add a "Reload Config File" option 
soon in this menu.

Re: config control panel: there's some experimental stuff, but it 
still needs a better internal design. If you need to expose some 
parameters, just fill the words: [...] block in your module definition 
and add some config options.  (this is  not yet documented, but by 
looking in mod-static or mod-action, you'll figure out easily how 
to use that feature).

I changed port-id in httpd.r to 8100, but it still serves on port 
80

I once had the same problem

there were twho httpd.r scripts in the distro.

Doc was fixing that IIRC. One of them was experimental and was supposed 
to be removed.

so - not sure it is your case ...

it's not enough to change it in the httpd.r... start your server 
from shortcut using for example D:\view\rebol2705031.exe -sq cheyenne.r 
-p 800

how is that? why is that not enough?

what is that option in httpd.r there for then? :-)

you can listen no only one port

cheyenne.r -p 800,8100

Thanks, that works.

Cheyenne.r does bypass settings in uniserve.r, httpd.r, etc, which 
is a feature! for example if you set verbosity in httpd.r, it will 
be bypassed by code in cheyenne.r which takes in command line parameters, 
look in the source of cheyenne, on the bottom ;-)

This allows me to pick up my previous cgi-bin scripts from Cheyenne

webapp [
		virtual-root "/cgi-bin"
		root-dir %/c/xitami/cgi-bin/
		debug    
  ]

You should not change the port-id in httpd.r, either change it in 
cheyenne.r, or better, use the -p command line option.

Pekr: it was http.r and http2.r protocols in UniServe.

Any chance of having the custom 404 a rsp page?

Graham.  404 response is defined in  httpd.cfg  and can be set to 
be .rsp e.g. 	
	on-status-code [
		404	  "/custom404.rsp"
	]

But it would be handy if  validate allowed for default values for 
parameters which may or not have been provides similar to what is 
done with the cgi object.

'validate sets parameters to none! if they are not provided. What 
does the cgi object for default values ?

I should extend 'validate spec block to allow custom default values.

Hi Doc,

I was referring to something like this 
   construct/with
                cgi-block
                   make object! [a: 111 b: 222 c: 3]


from http://www.rebol.org/cgi-bin/cgiwrap/rebol/art-display-article.r?article=x60w#toc-20



It could be added by all users to the results of validate but then 
it would be not be a standard cheyenne solution. It makes sense to 
me it is ''validate.

Thanks for the example. I agree, it's a useful feature. I'll see 
how I can improve 'validate to support that while keeping it  short 
and fast.

I think doc said before that it won't be processed as rsp if using 
a custom 404 handler like this.