World: r3wp

I've tried to get it up and running (Magic!) but have never got it 
to work. Apachi always gives me a hard time. Since its CGI based 
I tried with Cheyenne but again unsuccessful.

The new framework will still use HTML for UI but without mixing it 
with REBOL code.

Doc, if you have specific complaints about LNS, please chime in - 
I am looking over the code now.

HTML templates will be static files and some advanced widgets (like 
those AJAX-based) may be generated dynamically.

Are you going towards a asp.net style special tags model for the 
dynamic widgets?

Brian, nothing specific, it just looked "too big" last time I've 
checked the source code which was a year ago. I should have a look 
in Devbase for the latest version of LNS.

Nope, no custom tags, just plain HTML/xHTML.

I put in some minor fixes yesterday, but I haven't yet had the chance 
to really look it over properly. Any advice would be appreciated, 
especially related to speed, size and security.

I didn't decided yet, but I may use <span> tag for extending the 
set of HTML standard widgets.

(Sorry, my internet connection died in the middle of the conversation.)

I've been wondering what it would be like to have a rebol version 
of asp.net.  I'd like to see a solution that separates the HTML and 
the logic as discussed, but also get rid of the css, javascript, 
xml and other languagues that get in the way of a streamlined solution.

quoting btiffin,  GO DOC GO!!

Brock: trashing HTML, CSS and javascript, in favor of REBOL *is* 
the final goal ;-) First step is clean separation with HTML.

with = from

Quoting Brock.  Go Doc Go!

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"