World: r3wp
[!Cheyenne] Discussions about the Cheyenne Web Server
| older newer | first last |
| Dockimbel 18-Apr-2011 [9860] | i have a couple of ideas how to hack this, but what would be the
correct" way?"
You could try using the ALIAS config option. Add this to the httpd.cfg
file in a domain section (not sure if it would work in a webapp context):
alias "/rest" %rest.rsp
and call your REST resources with:
/rest/asd
/rest/qwe
In %rest.rsp, you can put your URL parsing code to produce a "REST
routing" and return the JSON object. It might also work with "/"
(untested).
|
| Maxim 18-Apr-2011 [9861] | Doc, wrt req/in: make req/in [] so far it works flawlessly. I'm using this to store computed data from an early phase and sending it to the handler later. This allows me to prevent double or tripple processing the same thing (a decision based on the url) |
| Dockimbel 18-Apr-2011 [9862x2] | Extending the req/in object! is a good solution. I should maybe add a 'user field in request object for storing custom mod data... |
(just to make it cleaner) | |
| Maxim 18-Apr-2011 [9864x3] | don't know, since then more than one mod might start to clobber it, and we'd be fighting for the space (same difference, just one level down ;-) and, since those extra bytes get molded/sent/loaded to and from handers... it seems like waste when for most people this data will not be used. I'd actually rather document how a module should expand a request... like spelling any new word, starting with the mod's name to prevent collisions. |
and documenting that its supported and safe too :-) | |
(since it seems safe so far) | |
| Dockimbel 18-Apr-2011 [9867] | Agreed. |
| Maxim 18-Apr-2011 [9868] | (no need to go down the RoR path ;-) |
| onetom 18-Apr-2011 [9869] | Dockimbel: the alias "/" %x.r works too. beautiful. |
| Dockimbel 18-Apr-2011 [9870] | Good! :-) |
| ChristianE 18-Apr-2011 [9871x4] | Should the following .rsp script work and deliver something like ... <p>123</p> ... |
<html> 2 <head> 3 <title>Test</title> 4 </head> 5 <body> 6 <p> 7 <%= ajoin collect [repeat i 3 [keep i]] %> 8 </p> 9 </body> 10 </html> | |
(sorry, ignore the line numbers) | |
I tend to use COLLECT a lot in REBOL scripts, but it seems it can't be used with Cheyenne. | |
| Dockimbel 18-Apr-2011 [9875] | Which Cheyenne version are you using? |
| ChristianE 18-Apr-2011 [9876x4] | All I get is |
#[object! [ code: 302 type: script id: no-arg arg1: arg1 arg2: keep arg3: #[none] near: [err/arg1] where: reduce-error ]] | |
wheter I'm in DEBUG mode or not.. | |
I'm running version 0.9.20.125 | |
| Dockimbel 18-Apr-2011 [9880] | Seems that the RSP error catching has some trouble with COLLECT. |
| ChristianE 18-Apr-2011 [9881x6] | Another error I'm running into fairly regular is |
#[object! [ code: 502 type: access id: cannot-open arg1: %/usr/local/bin/cheyenne/ arg2: #[none] arg3: #[none] near: [change-dir save-path compress-output unless response/buffered? ] where: #[none] ]] | |
when doing something | |
like | |
<% ... query: "select * from database.table" ... do-sql query ... %> | |
Cheyenne doesn't like the QUERY word being overriden. But doing so is probably just silly on my behalf. | |
| Dockimbel 18-Apr-2011 [9887x2] | QUERY is a REBOL native function |
You should *never* redefine such word that is used in several mezzanines. | |
| ChristianE 18-Apr-2011 [9889] | Yeah, so, as I said, just silly on my part. |
| Dockimbel 18-Apr-2011 [9890x9] | The issue with COLLECT is caused by DO. In RSP environment, DO is redefined to bind argument code to webapps execution contexts. The RSP mezz DO has a fixed arity (= 1) while the native DO has a variable arity (= 3 inside COLLECT), hence the error. |
I see no simple way to fix that on the RSP side as they is no reachable way to emulate the "variable arity" at mezz level. | |
So, I'll see if I can patch COLLECT instead. | |
Hard to fix COLLECT without destroying Brian's code pattern... | |
I will ask BrianH for that. | |
Ok, I've found an (obvious) patch for COLLECT. A reference to the DO native is kept in RSP (*do). So the following patch (run in global context) would solve the issue: if pos: find second :collect 'do [pos/1: '*do] | |
I guess other new mezzs in 2.7.8 might be using DO internally too, they would need to be patch one by one by Cheyenne to be used in RSP context. | |
ChristianE: I've commited a fix to Cheyenne public repository. It will be available as a new source package in http://cheyenne-server.org/download.shtml in about an hour. But I won't build new binaries now (takes too much time). | |
If you're using the binary version and don't have the SDK, you can put the one-line patch in a REBOL script and load it in your app's startup code or better, load it using the 'worker-libs config keyword. | |
| ChristianE 18-Apr-2011 [9899] | Nenad, that's great! Thanks for all the work and effort you put into Cheyenne! And don't even think of taking any extra time to build binaries for just a little fix like this one, really, I can wait and happily use the patch. |
| Dockimbel 18-Apr-2011 [9900] | Cool :-) |
| Maxim 18-Apr-2011 [9901x3] | Doc, one thing I have not yet fully mapped out in my mind wrt handlers. Q1: how do the handlers actually compile/get their source code... is it sent over tcp and run there, or does the handler load a file on its own? Q2: when exactly does this happen? Q3: can I configure the handler source or data in some way before it gets compiled/executed, (at the mod conf parsing stage). I neet the handler to share some data with the mod which manages it in some way. I don't want to send this config data via the request, at each request (makes no sense) |
ah... don't bother, I just figured out... I've been reverse engineering the whole task-handler/master code for a few hours... finally found the magic lines I was looking for. its neet, you load the files on demand, loading each module, only if its actually required. best of both worlds. | |
so I guess, the best way to configure the handlers through cheyenne's httpd.cfg system, is to save out a temporary configuration file on the fly when the conf parser is run. this file would be executed by my handler when it is launched by any of the worker processes. | |
| Dockimbel 19-Apr-2011 [9904x2] | Looking at COLLECT code again, DO's arity is not 3, it is 2 or 10, depending on how one count arguments. |
Temporary conf file: right, that should be the simplest solution. | |
| Maxim 19-Apr-2011 [9906x2] | yeah... I've changed my solution a bit. the handler now has a variable to know if its been configured yet, and if it has, it skips that part of the code. so even if I get the cfg at each request, I ignore it. The cool thing is that my mod really doesn't need much configuration and most other standard configs are useless to it, so I commented just about all of them in my httpd.cfg and my mod still works. :-) very lean on the cheyenne side. I do all the heavy lifting in the handler, so it can scale pretty well. |
one strange thing though... in the task-master.r lib I set workers like this: pool-start: 1 ; number of helper process when Uniserve starts pool-max: 2 ; maximum number of helper process and it always opens up 4 anyways. is there anything else to do? | |
| Dockimbel 19-Apr-2011 [9908] | These default settings are superseded by the ones from %cheyenne.r. |
| Maxim 19-Apr-2011 [9909] | ah. |
| older newer | first last |