World: r3wp

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? :)

hehehe, will be providing the link to my site once its on-line, and 
then will start working on revault, for which I also purchased domains.

I am using this site as a showcase for all of my work.  including 
web, visual arts, music, design, programming, etc.

I have soooo much stuff on my disk which is just screaming to be 
released!

cheyenne-admin also has a *VERY* nice GUI, using GLayout.

already using cheyenne-admin to setup my bash user config files (~/.xxxx 
files) copying files locally, editing in ultra-edit, and uploading 
them back  
all via one click for xfer   :-)
I'm lazy  hehehehe

what do you use the admin for ?

Note this is a linux server-side only tool (currently).
currently:
	-remote browing of files in a gui.
	-uploading/downloading any files to/from the webserver
	-running command-lines remotely
soon: 
	-chmoding remote files
	-handling webserver start/stop/restart  remotely.
	-more as time goes by.

so you run the tool on the server PC?

ie. you can't run it from a client PC?

nope locally.

I meant the server has to be a linux box.

anyone know if there is a detailed doc on sessions within cheyenne?

what we need with !cheyenne are minial examples of services and mods 
which implement all callbacks and give just a small comment on why 
and when it is called... this would help soo much in understanding 
how to implement cheyenne extensions.


I am currently looking at the rsp code and its so huge and complex 
that its a big daunting to grasp the whole by looking at its parts.

Mod-RSP is the most complex one and it does a lot of things. Sessions 
in Cheyenne are RSP-specific. There's a synchronization system in 
RSP sessions for protection of session data from corruption in concurrent 
executions. That may be easy to understand by just reading the code. 
Anyway, feel free to ask for explanations of specific code parts.

yep it is complex hehe

you mean that if two requests are sent to different task-handlers 
they will resync when the later is done?

or is it rather some kind of semaphore?

there are too few comments (read as almost none ;-) in your code, 
 and that doesn't slow down server in any way   ;-D