World: r3wp

Hi guys, there's a tiny issue with Cheyenne running on 2.7.6 due 
to a bug fixed in EXTRACT. To fix it just open %HTTPd.r file and 
find the  following line :

what is the bug in extract?

extension-class: context list

and replace it with :

extension-class: context to-block list

EXTRACT (on pre 2.7.6) was always returning a block! value.

Ahh, yeah I think that change came about from discussions that me 
and BrianH had.

Next Cheyenne release will include this bug fix. The next release 
should be soon because I intend to make some deep internal changes 
in RSP to support different HTML processing engines (not only the 
current one with mixed HTML and REBOL code). This shouldn't affect 
the RSP API or behaviour, just the internal design. So, I plan to 
make a new release before starting these changes.

Great to hear Doc!

RSP? Ah, server pages ... I exchanged it with services protocol? 
Still do you plan on some remote protocol? Btw - will rebservices 
work upon cheyenne? It probably should, as it can work upon html?

The new RSP framework will borrow ideas from some top Java web frameworks, 
like XMLc or Wicked. It will follow the MVC design pattern. Currently 
the View part is almost ready (complete separation of HTML and REBOL 
code and 100% pure HTML templates). I plan to work soon on the Model 
part  trying to make an abstraction layer similar to the Object-Relationnal 
mapping solution found in the Java worl like Hibernate. For the Controller 
part, I didn't yet decided on how it should be, I plan to release 
only the MV part first.

I don't know if current rebservices can use HTTP protocol as transport. 
Rebservices can run in the same process as Cheyenne, but processing 
rebservices requests may slow down Cheyenne's performances a lot. 
R3 threading will solve that kind of issue, so we'll see in a few 
monthes. ;-)

rebservices should theoretically work over http, cgi or other layers. 
We will see ...

Sure, but is it supported in current implementation ?

It's not used in the current implementation (in DevBase), but I've 
seen no evidence that it was removed.

I'm pretty sure that Gregg uses Rebol/Services via HTTP & CGI. I 
believe that he found it slower but more reliable than via TCP.

Watch out with EXTRACT: There is a bug in the 2.7.6 version with 
binary values that was fixed, but the fix never made it into 2.7.6. 
You can get the working version from DevBase r2-mezz-series #396.

The discussions that Paul and I had resulted in some R2 optimizations 
for EXTRACT, but those optimizations never made it into the 2.7.6 
release. The semantic changes that prompted your bug fix originated 
in the R3 version of EXTRACT that we wrote back in November, and 
were a result of discussions of the severe limitations and bugs of 
the old EXTRACT.

Fortunately the binary bug only arose during the testing of the R2 
version of the new EXTRACT - the old version of EXTRACT never really 
worked with anything other than blocks anyways.

Thanks for the info.

Bug: it looks that reloading config does not updates databases.

True and there's a small limitation there that I will need to solve 
in the future versions.

Are you sure you want to set url, path, target and ext inside parse-request-line? 
If you do that, you cannot simply rewrite using mods.

I mean path, target and ext. Url should be set here of course so 
it can be parsed after url-translate.

Although now I see I should use mod-alias. But somehow don't know 
how - only redirect seems to work here.

ok.. found it... BUG:  if there is specified other alias type than 
'file ot 'path - Cheyenne halts on uncatched error.

And it looks the Alias is not finished as it looks just for redirects:)

Interesting comments, I should maybe move the URL parsing later in 
the processing pipeline or, instead, provide a hook for modules to 
be able to rewrite the URL before it is parsed. Anyway, you can change 
the URL, path, target and ext (+ req/vhost) in any module's phases 
if needed, but a clean way to do it is preferable. The hard part 
for making a good rewriting engine is, IMO, to invent a good clear, 
clean and compact dialect to achieve that...regexp are not really 
my taste.

You're right about mod-alias, it's not completed yet. I found it 
might be redundant with a rewriting engine, so I left it unfinished 
until mod-rewrite comes.

I'm letting the little indian go out : http://cheyenne-server.org
;-)

This will be the new official web site for Cheyenne. I still needs 
some time to migrate all the old stuff, including the blog.

Very nice Doc!

looks pretty 8-)

Excellent. The graphics look really good.

Cool

If I have a proxy server made in Uniserve, what is the best way to 
join it with Cheyenne?

1) Add you service in %UniServe/services/
2) Edit %Cheyenne/cheyenne.r

3) Add in the 'set-cache block inside the %services/ section, the 
name of your service.
4) In 'do-cheyenne-app function :


- find the line "do-cache %HTTPd.r" and add after that : "do-cache 
%your-service.r"

- find the line "control/start/only 'task-master none" and add after 
that :
    "control/start/only 'your-service-name none"

That way it will work both in source mode and encapped.

I will try it.. thanks.

How much time will you be spending on Cheyenne Doc?

Hard to answer, but as it's propably the most important software 
component for my company, quite a lot I guess.

And where I should add protocol? If I used to start the proxy using:

uniserve/boot/with/no-loop [services [proxy-http] protocols [http]]

I see... do-cache uniserve-path/protocols/HTTP.r

On the web site linked above in the Chunk-encoding section: transferts 
-> transfers

With PHP I often use code like:
<? if(something) { ?>
 normal HTML is here
<? } else { ?>
 something else here
<? } ?>

Don't you miss some way to do such a conditions?

And as I'm now writing RSP I found the RSP's <%%> tag much more difficult 
to write than PHP's <??>

remap your keyboard??

or, remap your keyboard%%

Typo fixed, thanks Brian.

Same in RSP :

<% either something [ %>
    normal HTML is here
<% ][ %>
    something else here
<% ] %>

Just as a reminder for those currently using Cheyenne/RSP, you can 
add the DEBUG keyword in your webapp config section in %httpd.cfg 
to display a menu with useful debugging info.

impressed! 8) I finally gave another try at php support in cheyenne 
and after patching fastcgi.c as suggested it now works like a charm.

If you are on os x and use macports, here is a way to patch and compile:

sudo port install php5 +mysql5 +fastcgi
sudo port uninstall php5
cd /opt/local/var/macports/distfiles/php5/
sudo tar -xjf php-5.2.6.tar.bz2
>> run patch below
tar -cjf php-5.2.6.tar.bz2 php-5.2.6
sudo port install php5 +mysql5 +fastcgi checksum.skip=yes

copy of Dockimbel's patch with path fixed for this example

;---- cut'n paste the following code in REBOL's console ----

patch-php: has [buffer pos][ target: %php-5.2.6/sapi/cgi/fastcgi.c 
if none? attempt [buffer: read target][ print "unable to find the 
file to patch!!" exit ] either parse buffer [ thru "int fcgi_accept_request(" 
to "if (req->fd >= 0) {" pos: to end ][ insert pos "^/^-^-^-^-break;^/^-^-^-^-" 
write target buffer print "patch applied." ][ print "failed to locate 
the line to patch!!" ] ]
patch-php ;---- end of code ----

tar -cjf php-5.2.6.tar.bz2 php-5.2.6
should be:
sudo tar -cjf php-5.2.6.tar.bz2 php-5.2.6