World: r3wp

wrt api server speed  adding up all the required cheyenne server 
handling and tcp xfer we get:


>> s: chrono-time    read http://localhost:81/echo.xml?value=tadam 
     difference chrono-time s
connecting to: localhost
== 0:00:00.010442948

how do I prevent the printing of "connecting to: localhost" when 
I read urls?
ex: 
>> read http://localhost:81/   
connecting to: localhost
== 0:00:00.010442948

sorry... question was meant for network group

is there a way for worker threads to change the req others than the 
content, in order to tell the mod that it should switch mime types?

I guess this is the only real way to pass messages back to the cheyenne 
server:
within the mod...

task-done: func [req][
	load/all req/out/content
]

Right, if you need to pass more than just the raw data to send back 
to the client, you need to build a custom data structure from your 
handler that you would decode in the mod receiving it.

did anyone used single signon (kerberos) w cheyenne?

doc, in req/out   I have   both a value called   mime:   and   mime-type: 
   it seems that within mod phases, we are supposed to set   mime: 
   to a lit-path   ....


why is this so?  wouldn't it be simpler to have just one and set 
it as a string directly, to be used in the header construction after?

i.e, doesn't mime-type:  suffice?

There is no 'mime-type in the request object, only 'mime?? Maybe 
you were thinking about the 'set-mime-type callback?


Lit-path: for historical reason, I wanted to be able to manage content-types 
using mime classes (text/*, image/*,application/*, ...), but I didn't 
use it so far.

oh... looked at it again... my bad... I'm returning mime-type: in 
my response and the probe was really confusingly showing it as if 
the mime-type: was in the same object as the req object.

for those who might be using dividers and don't look at all the groups, 
I posted the release of mod-web-api in the announce group, yesterday.

Graham, did you try the webservice mod?

I am wondering if I can use this to control various applications 
I have running.  They currently run with GUIs, but I think I should 
use a web service module to control them so that I can run them all 
GUI less.

well, you can still have a gui, but all it needs to do is build URLs 
and confirm the results  :-)

the web service would communicate internally via a tcp port ... so 
that should work.

2/5-19:59:12.259281-## Error in [conf-parser] : Error in conf file 
at: !
does this look familiar to anyone?
there is no ! in the httpd.cfg of course

Never saw such error before.

im trying to put an alias into a webapp. is it possible?

In theory, it should be possible, but never tested. I'm having a 
quick look at 'alias code atm...

I don't see anything in the 'alias implementation preventing it to 
work from within a webapp.

Doing a quick test...

Works here. Here is my webapp config:
	webapp [
		virtual-root "/testapp"
		root-dir %www/testapp/
		auth "/testapp/login.rsp" 
	
		alias "/testapp/hello" %testapp/login.rsp
	]

hmm.. it doesn't throw an error if im trying to load a non-existant 
module

how do u ignore .svn dirs while grepping an svn repo? it's annoying 
to say | grep -v \\.svn all the time

Grepping: don't know. I would do a  "svn export" of the SVN repository 
in such case.

ah, it goes into the crashlog if a module is not found.

im not sure how would it be the best but it's freaking hard to debug 
like this.

1, i won't know the names of the chey-pid-*.log files and there are 
multiple of them, so i can't easily tail -F them

2, trace and crash logs are created where the cheyenne executable 
or rebol source is located. -- that place usually not writable and 
it's somewhere else, not where the application is.

3, i won't know what is logged where unless i check all of these 
logs -- i could imagine a non-daemonizing mode where every fucking 
things is just dumped onto the stderr

i won't know the names of the chey-pid-*.log files

 As the -pid- part suggests, you just need to search for the one having 
 the same PID as the current Cheyenne main process.

i mean, i can't know it in advance. now im running cheyenne with 
-w 1 and having a look at the log with less *pid*log

btw, that error at ! is logged even if my cfg file is only
$ cat httpd.cfg
modules [ internal extapp static action rsp alias ]
globals [ listen [8080]    bind-extern RSP to [ .r ] ]

I wonder why you guys are make things harder by trying to debug your 
apps under production conditions? 


Why don't you make a local development setup using Cheyenne from 
sources, lauching it from a console in verbose mode to have a direct 
look at everything that could go wrong. The only log file I need 
to look at during Cheyenne development is %trace.log file (and even 
this one is accessible from your browser in RSP 'debug mode...).

im writing a json webservice and actually it's very annoying when 
i get a RSP error html page, instead of the usual rebol error.

what do u mean by production condition, btw? there is nothing in 
production yet

i have a global debug option just as a per-vhost one and im starting 
cheyenne w -vvv beside -w 1

Production mode: using the binary version as a daemon, instead of 
using the source version from a REBOL console.

im writing a json webservice and actually it's very annoying when 
i get a RSP error html page, instead of the usual rebol error.
 


debug/off should fix that: http://cheyenne-server.org/docs/rsp-api.html#def-65

because - normally - i shouldn't care about the webserver. that would 
be one of the great things about cheyenne. it's just a 1-file-webserver

(meanwhile i see there should be 1 vhost definition at least, so 
that's why the conf-parser fails; the error at: ! still doesn't make 
sense though :)
anyway, i keep on debugging)

I don't care about Cheyenne while coding RSP scripts or webapps, 
*but*, I always launch it in source mode (and never as a binary) 
on my local development box. That way, when something odd happens, 
I just have a look at the REBOL console and scroll up until I see 
what happened (so I never need to look at any %chey-pid* or %crash.log 
during development).

aha. and we can't start the binary in a similar mode, where the errors 
are not caught and logged, but showed in the console instead? (im 
trying to do a do %cheyenne.r now)

The Cheyenne binary version is meant for production, so all things 
are logged in files. If you want to have them in a REBOL console 
from the binary, you need to build a custom binary and change the 
encap options in the %cheyenne.r header. Removing the 'no-window 
option will redirect all logs (except %trace.log) to a REBOL console.

hm.. is this no-window thing documented?

BTW, if you launch Cheyenne from REBOL console, you can still pass 
it command line options, my local Cheyenne is launched using:

rebol -s cheyenne.r -vvv -w 0

No-window: yes, it's part of REBOL/SDK documentation.

i was trying:

onetom ~/p/ob $ rebol -qs --do 'do/args %~/rebol/cheyenne/Cheyenne/cheyenne.r 
"-w 1 -vvv"'

is this no-window option equivalent to the -w option?

IIRC, yes it is.

-w as REBOL option (to not confuse with Cheyenne's -w option).

sure

Here is the SDK documentation about encap headers: http://www.rebol.com/docs/sdk/encap.html#section-8