World: r3wp

dockimbel, I'm using RSP for the forum and it's working great so 
far. no problems.

LNS or something similar, definitely. I would like something "lighter" 
if possible, than RT's LNS focused on speed and security.

with RSP, would there be an option to only run .rsp files and not 
.r? if I want to serve .rsp pages and allow downloading of .r scripts?

i.e. when the user asks for .r files, not when another .rsp page 
wants to include them

Sure, It's just a matter of configuration in %httpd.cfg file.

Just remove .r from this line : bind-extern CGI to [.cgi .r], and 
.r file will be served as static files.

thanks

What is the advantage of  "x" framework? What kind of stuff does 
it enable us to do?

The main feature has been already exposed above : clean and complete 
separation between HTML and REBOL code.

I would also like to add AJAX and DB abstraction layer, but I didn't 
yet decided what approach would fit the best with REBOL. It needs 
a lot of experimenting first.

My desire is to integrate the best features found around in other 
web frameworks, but in the most efficient way (simple, fast and lightweight).

clean and complete separation between HTML and REBOL code
 

So you are not mixing rebol code with html in one file? (like in 
RSP)

But your building web pages using rebol code alone? Is the server 
acting like a serverside "plug-In"?
Sorry if I sound completley novice.

hmmm... I'm building a dialect that builds HTML code, in a sense, 
weeding out the need for HTML code inside the rebol code. is that 
what "x" does?

Henrik, I like that idea.

Is that what Magic! does somewhat. I know in the docs there seem 
to be widgets.

magic is not there imo

Doc - sounds cool!

Henrik - what he meant was to use some other means of tagging imo. 
Simply no combination of REBOL and html code. That aproach ala PHP 
is total crap

Pekr, "not there". You mean just not powerful or useful enough?

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.