World: r3wp

comes with a REST api

REST?

Lots of apache rewriting going on .. so i just use the vmware appliance

REpresentational State Transfer

VMWARE Appliance...Which one? One with Apache?

http://rest.blueoxen.net/cgi-bin/wiki.pl?FrontPage

Hayes Deki

http://wiki.mindtouch.com/Deki_wiki

My brain hurts..I'm using Rebol to make my life easier. I do not 
have time to figure out a new wiki or  whatever every other day.. 
Nothing against you smarter guys but Iove rebol because I'm finally 
able to see a problem or need and solve it with a simple rebol app. 
!Cheyenne is my hope for an easy rebol path to the web without Java 
script, php, perl, AJAX etc.

Graham; Think I should persevere with Vanilla?  It is REBOL.  I'm 
questing for a good forum/wiki combo and the search started today, 
so I'll take any and all advice...as long it includes the word Cheyenne 
in it.  :)  I've decided to branch out of all REBOL mode but not 
too far and not at all if possible.  But RBBS is not going to cut 
it for a forum in the long haul.

I have some major hopes for R3 and the web. I've seen what adobe 
and microsoft  Silverlight offer and I want to be able to do thses 
things with rebol

Btiffin ..now I appologize for interrupting a conversation

Nothing left to do but smile smile smile.

No problem Alan.  I like what you are saying.

have a vanilla running in rsp not cgi, but still need to replace 
the session+logio with cheyenne session+login and I'd also want to 
put snip in a db

I don't think I would have pursued setting up peoplecards.ca without 
a REBOL web server behind it, and now to patiently wait for (or get 
motivated to write) a nice REBOL forum.  :)

As much as I like the idea of Cheyenne i thing the Rebol plugin is 
the future. The adobe and Microsoft solutions seem to bypass HTML. 
 If R3 can offer aht I think it promises why creat an html base site 
if you can make a rebol app and "plug it in"  to the site.

aht = what

This conversation has made me decide to pursue getting vanilla running 
under .9.16  So close to Cheyenne 1.0rc1 though.   I think it'll 
be time well wasted.  


Alan...still need something delivering off of port 80 though no? 
 Maybe not HTML in the future but Cheyenne is an awesome http delivery 
system.  imho.

Agreed...Cheyenne is simple to deploy and setup and great if you 
plan to use rebol for RSP...You will always need an HTML server to 
deliver content but the form of the content?  Is Cheyenne, knowing 
that its Rebol based and supports RSP, does it offer something that 
is ground breaking..or unusual...not seen before.

It may be too late, but I've always wondered why there isn't a REBOL 
browser in the offing.  In the beginning, a whole decade ago, which 
is 70 internet years, the Hot Java browser got more press than Oak 
ever did.

Oak?

Java.  Before Gosling was sitting in a cafe worried about naming 
conflicts.

With R# I would like to some way to atleast display a web page in 
a window/face..

R# = R3

Yep.  It would close the gaping hole in the whole.  :)

The problem with Vanilla is that it does not appear to be updated 
anymore by the authors

To be pragamatic, one has to look for something that is being updated.

I'm running ubuntu 7 with vmware server - and then running my apps 
as appliances.

I'm finding that (like most non-trivial REBOL web apps) vanilla is 
using globals that conflict with Cheyenne.  session in the first 
case I've tracked down.  It won't be that hard to fix, but name collisions 
are a pain in the...

Graham;  I was a polyFORTH programmer.  'being updated?'  Why that's 
for young whippersnappers.  :)  Old and stale is way better.

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 ?