World: r3wp

yess... done !

JSON built in Cheyenne: (replying in javascript channel)

I thought I'd just mention it here... a it's a bit odd, and perhaps 
not entirely reproducible.  But I got my JS calendar working.  But 
I could not see any data coming in from my rsp script that was pulling 
data from the db and sending it back as json until I put some debugging 
statements in .. and then it works.  Bizarre.  Or some browser cache 
issue.

Just using a few ?? to log to the trace.log file so it wouldn't even 
be seen by the calling script ...

You can test if it's a browser cache issue by requesting the script 
using the READ function from REBOL console. Can you make a small 
standalone RSP script that  shows this issue?

heh ..  I don't think 'read evaluates JS :)

the docs say you can set the timeout to whatever in the webapp httpd.cfg 
but when I set it to 2:00:00, it still times out well before that.

Where's the curecode for Cheyenne?

Not back online yet.

This works for me :
	webapp [
		virtual-root "/testapp"
		root-dir %www/testapp/
		auth "/testapp/login.rsp" 
		timeout 02:00:00
	]

ahhh.... mea culpa

I used timeout: 02:00:00  .. ie a set word

that should rise an error when starting with -v

SVN r15

FEAT: scheduler lib added
FEAT: 'job config keyword added (CRON-like jobs)

FIX: cheyenne freezing on exiting (only if config reloading was used)

Warning: the scheduler integration with Cheyenne is at beta stage, 
minimaly tested, so if you want to put it in production, take the 
time to test it well.

I've noted in my todo list to extend the RSP API to be able to add/delete 
jobs (for now, the list is static, loaded from config file and cannot 
be accessed from RSP).

FEAT ??

Do you mean "Done ?

FEAT[URE]

yes, means done

Doc - does Cheyenne already enable setting handlers for particular 
filetypes? I mean - equivalence to:

AddHandler rebol-cgi-dispatch .html
Action rebol-cgi-dispatch /cgi-bin/rebol-cgi-dispatch.cgi


For Cheyenne only users, it is not important, they can use RSP, but 
for those who want to have chance to migrate between Apache and Cheyenne 
in CGI mode, it might be usefull. I expect it not being a priority 
for you though ...

But the scheduler is still very fresh, no logging, not much tested,...

Need to check the sources, I don't remember how far we are now.

Currently there's only URL=>script aliasing available, but looking 
at the ALIAS code, I think that : 
	alias ".html" /cgi-bin/rebol-cgi-dispatch.cgi

might work (need to be tested). Do you really think that there's 
much users waiting for that feature?

Is this scheduler part of Cheyenne or Uniserve?  Just not sure what 
it has to do with Cheyenne

Is it to give those tasks hanging around something to do :)

Something I'd like to do is run a backup of my database, compress 
it and upload it to S3.  I use a script for that at the moment .. 
so maybe I can use the scheduler.

Doc - I don't know. But how I got myself to such a solution? Simply 
put - I never got past CGI usage. It is quite comfort and OK for 
small to middle sites. But I wanted to have also index.html being 
a dynamic site, not just some /cgi-bin/my-subpage.cgi?here ....

Your RSP solution might be fine, but if someone wants to feel secure 
= having ability to migrate back to Apache set-up, it will not work.

Petr, in any case, you can "extend" Cheyenne feature-set by using 
a front reverse-proxy (nginx, lighthttpd, stunnel, apache,...).

Scheduler is a standalone library. Cheyenne uses it to manage jobs 
defined in config file. UniServe will use it for example, to retry 
sending emails after x minutes.

The scheduler doesn't spawn any new process by itself. When you specify 
an action, you can use CALL or LAUNCH in the action code to run your 
task in background. You can also use a URL pointing to a local CGI 
or RSP script (making it run in the background using one of the task-master 
worker processes).

I tried to run  Cheyenne as a service.
It installs itself as a service, but does not run.

What OS? Do you have admin rights?

When I test with the scm-100 package, I can open the service manager 
an some pcs, but not on all.
What should I observe, if I want to run Cheyenne as a service?

I used WinXP, Win2000 and Win2003. I have admin rights

I used your latest svn trunk and encapped it with encmd

Testing here on XP, the SVN version doesn't seem to work in service 
mode. You should use latest stable version instead until this get 
fixed.

ok, thanks

encapped with encmd and not encmdface?

doc has said that face prevents rebol apps running as windows services 
.. I didn't know that you could encap without face as cheyenne needs 
that to generate the captcha images ...

I do not need captchas, as I just want to couple some system.

Just curious .. has anyone run phpmyadmin under cheyenne?

I wasn't able to install it even to lamp one time :)

Yes, I had it running a ways back...I did not like the dos window 
that opened up to get php running...

If I want to do REST or SOAP, can I use Cheyenne?
Where do I have to intercept?

Phpmydamin: yes I'm using it sometimes, since PHP support has been 
added. Mostly on Windows. I don't remember seeing the DOS window 
popping up for PHP scripts. Maybe you've used PHP in CGI mode with 
Cheyenne?

no need for an answer anymore, I just looked over some information 
on this

Graham did some work on REST support for Cheyenne. SOAP requires 
a XML encoder/decoder in your RSP script.

Too late :-)

thanks anyway

is there a setting in httpd.comf where I could change how long a 
auth session in webapp lasts?