World: r3wp

Moving to Linux.

Seems to me that is a problem with Cheyenne CGI.  You mentioned that 
QM has some globals conflict?  Though I understand CGI inclusion 
is for convenience, some compatibility -- not as the recommended 
development path.

'that is a problem' == 'Vanilla is using globals that conflict with 
Cheyenne'

Yeah, QM conflicts with  request  and Vanilla conflicts with  session 
 (at the quick glance I've taken so far).  These types of problems 
are pretty easy to fix given the motivation.  REBOL is eminently 
readable; all it requires is a little motivation, time and judicious 
use of context or global find and replace.  Collisions are always 
hit or miss, but the web related scripts usually collide just by 
nature of the higher level words being the perfect words for the 
concept at hand.   People running Apache would never see these collisions.


R3 holds a lot of promise in allowing us rebols the freedom for independent 
development that others can combine in fun and magical ways, worry 
free of this issue.  Another year and this type of complaint should 
be a thing of distant memory.

Yes, that is my hope.  I've been pining for the namespaces for some 
time (instead of building up a succession of leaky objects).

I wonder if it makes sense to associate globals with a webapp.

I want to run multiple versions of my portal ... connecting to different 
odbc connections.

This means I have to change the database name in all the rsp pages 
of my app, whereas if the name were confined to the web app, I would 
not need to do so.

It'd be fine if all RSP scripts ran in their own namespace...

Or all the RSP scripts of a single instance.

I'm not sure to understand the issue with Cheyenne CGI ? For RSP, 
there's a list of global words that MUST not be modified like : request, 
session, response... If you want to use, in RSP code, a framework 
that will conflict with RSP words in global space, you'd better wait 
for R3 to cleanly handle those issues, R2 namespace managment is 
just too limited.

Cannot you just use PROTECT to protect these words?
>> x: 1
== 1
>> x: 1 protect 'x
>> x
== 1
>> x: 2
** Script Error: Word x is protected, cannot modify
** Near: x: 2
>>

The global words used by RSP are already PROTECTed. From %RSP.r :

protect [
	do-sql db-cache request response session include
	include-file validate locale say
]

Protecting globals words doesn't solve word conflicting issues between 
frameworks, it just raises cleaner errors.

Has Doc released version 1 yet. I saw in his blog that he hoped to 
relese by Augustt.Perhaps I missed it...

not yet but he is working on a new release, probably a good time 
to send in bugs (if any!) and feature requests http://softinnov.org:8000/curecode/

btw, I stoppend months ago monitoring production Cheyenne servers 
as they just work flowlessly and at great speed ! Dock rules ! 8)

I've been using it also without any real problems. I as hoping to 
get my hands on his admin panel and some more docs on rsp

the admin panel is what's holding up release 1 isn't it ?

What's the best way to do dynamic pages with Cheyenne and Rebol? 
Does it has RSP or something like this build in?

yes, RSP module is supported, and maybe even documented? I don't 
remember correctly. Sadly I can't use Cheyenne yet, as I developed 
another aproach, and the thing is, that I override Apache handler 
for .html files to rsp.cgi, so all my html goes thru this dispatcher. 
Cheyenne can't handle such aproach yet ...

IIRC there was/is something called Magic as well. How is Magic related 
to RSP?

Magic is separate templating system. Don't remember it much, maybe 
that I just did not like it ... can't accept any system, mixing programming 
code and html.

Magic has a more complete framework

You can program wigets into the web page

I've been using rsp for a few small projects but I do not know its 
full capabiltiy. Yesterday I wrote a counter in two lines of code.

RSP is the best way and the faster inexecution/response time (instead 
of Apache cgi, it doesn't need to load rebol and your init library 
at each request), to do dynamic stuff with Cheyenne. The API is very 
sleek and you can read about it in the downloadable documentation 
part of Cheyeene download.

If you haven't, you should at least give it a try, you wont regreat 
! assured! 8-)

I have an Atom semantic network db  framewerk that's nearly ready 
for incorporation into Cheyenne.. check out the !Atom group for more 
details.

Perhaps this is more a chat related issue.  How would you feel if 
you went to a site  index.html  (explicitly .html)  and later found 
out it was actually an rsp  file with an .html filename.   Is that 
dirty-pool in web land?  I'm asking as Cheyenne .rsp makes it so 
easy to keep track of page hits and there are no <script> tags required 
and no redirects etc etc. I haven't turned it on in production peoplecards.ca 
as I think it's dirty-pool.  Looking for other's opinions.

I encapped cheyenne and it appeared to run okay, but I got all sorts 
of odbc errors :(

You need Atom ;)

Hey Doc.. how does Embed work with the latest release?

Ok.. i have a rudimentary version of Atom running with Cheyenne.

There goes my weekend ;(

Anyone considered writing a phpBB in Cheyenne and RSP ?  Something 
that would be capable of hosting 1000s of users

Considered yes, have time to do it, no.

You may not have the time,  I might though :)

Has anyone tried running the actual phpBB from Cheyenne yet?  I got 
close to setting up a test head and then got distracted by news of 
DevBase.  I have visions of user.r being hosted on a Cheyenne/phpBB/mediawiki 
codebase, but I'd prefer to wait (just a little bit longer) to see 
what REBOL solutions may pop up out of the woodwork.

I've been burnt by phpBB when my server got hacked .. so never again

How hard can it be to write a simple BBS ?

We've got server side cookie handling, session support, db  ( mysql, 
postgresql ) and web server

Is this a PITL project ?

Do we need MVC ?

I'm guessing the hardest part is writing all the html that displays 
it all ...

I don't like phpBB as I don't line other such a php apps... they 
seems to be too bloated to me... I think it should not be dificult 
to do it in Rebol. But I don't have time as well.

This could well be something user.r could attack as a testing ground 
for a multi-coder multi-module development.  Do we extend RBBS.r 
or start from first principles.  If it's Cheyenne add-on development, 
I'm in.


If by MVC you mean version control, I'd like to wait and see how 
DevBase looks.  If you mean Model-View-Controller, I've had nothing 
but grief interfacing the REBOL MVC frameworks with Cheyenne due 
to the soon to be managed :) namespace problem.

therein lies the grief with using acronyms :)  I meant the latter.

This would be great .. it's something that people would use, the 
designs are all out there to model upon .. and we can get something 
quite limited up and running