World: r3wp

Yeah, the intention is that a GUI console will be written in REBOL, 
part of the community-created, open-source portion. Then you can 
use or adapt the console for your own apps as well if you like. How 
about having RConsole being implemented with that? :)


Right now the GUI doesn't have good-enough Unicode support to make 
the console yet, so the GUI console will have to wait for the release 
of the host code (the current priority), and the subsequent resumption 
of the GUI work.

Be sure to select the QuickEdit Mode and Insert Mode options for 
the DOS console - they make your life easier :)

.

How exactly does Cheyenne cache file loads? I have trouble getting 
a specific REBOL script to load.

I think I have found a bug where Cheyenne keeps serving an empty 
file, if I have first had it put in a server directory as a MacOSX 
shortcut and then replaced it with a real file of the same name.

Not sure how shortcut are handled by REBOL for OSX. The cached version 
is reloaded only if the file modification timestamp changed.

I'll investigate it further if I get the time.

is there a way to prevent caching and logging?

logging: See %changelog.txt (search for disable-log and no-log)

caching: no, why would you prevent that? There's several caching 
systems in Cheyenne: static resources, RSP scripts, some HTTP headers 
generation,...

cause I need to handle it myself in mod_remark.. is this part of 
the module api?

Depends on what king of resources you're talking about. Static caching 
is done in mod-static like most other HTTP header caching. RSP script 
caching is done in helper processes.

If you want mod-remark to take other mod-static caching, just provide 
a 'make-response handler in mod-remark, give it a higher priority 
and make sure to return a TRUE value (that will end the phase shadowing 
mod-static's handler for that phase). You can also just unload mod-static 
by commenting it inside GLOBALS section in config file (you'll have 
then to provide all the adequate handlers for serving static resources).

ok, that answers my question perfectly... the caching is handled 
by mods.  VERY cool.  :-)

Right, each mod can provide its own caching system if required.

the thing is that in order to save resources, mod-remark will be 
creating MANY static files (including images and css scripts) but 
the content of those pages can ultimately change at each refresh, 
if the user is editing preference type information.

Just remember one important thing : mods live in the main process 
(the one running UniServe), so you have to keep mod handlers fast 
enough to not slow down the whole server. That's why Task-master 
service and it's helper process are here, to handle the load for 
the main process. See mod-action as an example of unloading the main 
process from the burden of running CGI scripts.

yep.  I know all about the task handlers... they are one reason I 
was having difficulty tracking where and how dynamic code was being 
run in my client's app.   ;-)

in mod_remark, all that can be forked to the task handlers will be. 
   remark will be using liquid for many things, allowing the task 
handlers to cache just about every CPU intensive task which doesn't 
need to be recalculated.  I expect it to be one of the fastest dynamic 
web systems on any platform.

but testing will reveal if that is the case  :-)

Looks like you've gone really deep in UniServe. Sending job to helper 
processes has a cost (building message, MOLDing, transmitting through 
TCP, LOADing, decoding message). With R3 and multithreading, this 
cost will reduce to zero, thanks to shared memory (or equivalent 
system).

yep... I'm now pretty versed in how uniserve handle's its universe 
 ;-)

yep threads will be a big plus in R3... many apps are much easier 
to write with threads (of any kind).  it breaks up the domain of 
many problems into smaller pieces.

I have the following problem. Depending if I send via POST or GET 
the CONTENT is different.

1. POST: [paymethod "paypal" rest "payment"]
2. GET: [rest "payment?paymethod"]

Why this? Where is the VALUE part in the GET request?

I use code like this:

<input type="radio" name="paymethod" value="paypal" />
<input type="radio" name="paymethod" value="somethingelse" />

And this code is wrapped in a DIV.

I expected to have the same structure of CONTENT within my RSP page 
independent if I use POST or GET.

It looks like the JS lib toQueryString creates two differnt versions... 
I'm using mooTools. Very strange. Or is there a cause for this?

Is this a cheyenne issue?

Yes, I just checked the LOG files. My normal HTTP server gets:

[24/May/2009:06:01:36 -0500] "GET /rest-cart/payment?paymethod=ueberweisung 
HTTP/1.1" 200 56

Cheyenne gets:

127.0.0.1 - - [24/May/2009:12:58:33 +0200] "GET test.rsp?rest=payment?paymethod=ueberweisung 
HTTP/1.0" 200 56

So, it looks like everything from client to server, to cheyenne is 
passed correctly. And than inside the RSP page it's lost.

toQueryString: This was a false alarm, it's working correct.

Are you using response/forward in your payment RSP script?

No, I load the answer HTML page and insert some HTML on the fly before 
returning the page via a PRINT.

That's why I'm really wondering what's happening...

Any other idea? Until this is solved I will use POST but GET would 
really  fit better.

I've never encountered such issue. Can you reproduce it using the 
%show.rsp script? (you can find show.rsp in the source archive in 
%www/)

It looks like you've added a reformed query-string to a URL already 
having a query-string. Are you using request/query-string?

how do I use rconsole to tell cheyenne to reload a mod that has changed 
on disk... 


or does cheyenne detect mod-file changes and reload them automatically?

You can't. Mods are part of Cheyenne's kernel and the priority of 
each mod's callback is determined relatively to the other mods during 
Cheyenne boot (kind of competition for higher priority for each phase). 
Reloading a mod would required reloading all the mods, breaking most 
of the active connections (CGI, RSP, FastCGI,...). So the answer 
is : kill and reload Cheyenne.

<required> = require

with your permission I would like to rebrand ssh-admin to  Cheyenne-admin.

its like a stand-alone cpanel for cheyenne-based systems.


All the current file and system commands options to manage the host 
server too will be complimented with any tools needed to configure 
and control cheyenne and any mods which are installed.

ok, so you build static blocks of callbacks, when loading the mods... 
I guess.

Exactly.

ok, so first cheyenne command in cheyenne-admin: "restart"  :-)

I make a hash! list of all the phases' callbacks, so the impact on 
performances remains very low.

:-)

so is the branding of cheyenne-admin ok with you?

Go on for the name, my own Cheyenne admin panel is still at a very 
early stage.

mine is already capable of all the file browsing/upload/download 
to the server  :-)

Link? :)