World: r3wp

I'll be putting a demo server on-line probably later tonight.

as well as all sources and docs as a .zip which simply appens to 
the cheyenne folders.

so you running as a local service?

the default setup is set for localhost, but it can run online, just 
set it up in one of the vhosts you are serving.

I didn't try running cheyenne as a windows service though, if that 
is what you meant.

No, I was asking the former .. if it's being used primarily as localhost

yes, right now, while testing, but there is no difference internally 
wrt using it on localhost or via vhost.

the module handler is pretty fast, considering, we are using external 
code and user hooks to setup the process.

calling this url on my meagre 1.5core2 duo
	http://localhost:81/echo.xml?value=tadam

returns this xml


<result status="success" method="echo" time-delta="0:00:00.000723302" 
phase="format-response">
    <echo value="tadam"/>
</result>

time delta is precise-timed using cpu frequency counters.

Seems very short time for an echo

Maxim: the path notation works on file! valued variables too:

>> f: join to-rebol-file get-env "HOME" %/system32
== %/Users/onetom/system32

>> f/some32.dll
== %/Users/onetom/system32/some32.dll

that's true, I always forget :-)

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)