World: r3wp

REST & XMLHttpRequest: This question vanished yesterday. Is Cheyenne 
REST compatible?


And, has anyone done a simple way to request an RSP page and put 
the returned content into the DOM of a current page? Or, which JS 
framework would be best to take stuff and put it into the DOM?

I don't know what is REST but I see no reason why XMLHttpRequest 
should not be possible. And I would use JQuery.

REST uses not only POST and GET but UPDATE, DELETE and INFO (IIRC) 
in HTTP requests. And I don't know if the other two need special 
treatment in the web-server or if everything is just routed to RSP 
Page and that's it.

JQuery: Looking at it already.

Robert: maybe this? http://rebol.wik.is/Cheyenne/Mod-rest

thanks for all info.. to me it's important difference if (1) last 
write wins or (2) data get's corrupted meaning you get file that 
doesn't have a rebol data that could be load-ed any more. Well I 
think I have been asking too much and should try experimenting and 
looking what happens. If only (1) can happen with very small probability 
(because I have many separate small files which don't get edited 
most of the time) in case of my current app it seems ok, but I will 
test (also what happens with read and write at the same time.) If 
(2) can happen at all then I will use/make a centralized file/data 
server right now so webapp will access no files directly any more 
and that server will have to take care of locking or serialize all 
reads writes.

I will have a "lab" project today with a title "Try to make a corrupt 
file" , this will be fun

Janko, thanks for the link. Cool!

It's (1) if you work with filesystem files AND Rebol uses the OS 
system locking functions (which I expect).

Robert, that's as far as I got with mod-rest ...let me know how you 
get on.

I've played a little with jQuery and jQuery UI, and there doesn't 
seem to be a problem pulling RSP pages into the DOM.

Janko: keep in mind that your (2) might be OS / flavour / version 
/ filesystem dependent.

REST: Graham's module is the only known attempt to support REST in 
Cheyenne. To be able to accept other HTTP methods like UPDATE, DELETE, 
INFO,..., its mod-rest module needs to be extended by implementing 
the 'method-support callback (to override the default 'method-support 
in mod-static).

jQuery, good choice 8)

REST: Ok, I will give it a try and let you know.

If you have a web app, and you send the user to the login.rsp by 
default, but there is no index.rsp etc, then you get a 404.

Adding %login.rsp to the default block doesn't help.

I had a nasty experience just now.   I had spent the last couple 
of days writing my prototype website .. and got all the ajax stuff 
working.  I decided to reboot because the css wasn't showing properly 
in chrome but was working in FF.  Big mistake.  Windows Vista reported 
a problem booting, and started it's recovery process.  At the end 
of it, all my RSP files I had created, or edited, in the last 2 days 
were gone!  Other files ( html ) were untouched.  System restore 
failed to recover these files and using file recovery tools also 
was unable to locate them.

I guess Windows does not recognize RSP files and decides that they 
are potentially malicious ie. not a document file, and so removes 
them :(

The lesson I guess is that one should store RSP files you're working 
on in the My Documents path to prevent windows trashing them.

Oh yeah ... every directory that I had rsp files from today were 
affected.

That's a nasty experience.

I think it's more a Windows problem than anything else.  Vista did 
that to me back during (I think) Thanksgiving with my Warcraft III 
install, and XP before that with Spore.

Perhaps a version control system would be a good place to store all 
your RSPs and all your other code and supporting files for that matter.

jQuery: Have spent the past 3 days with it, and although the syntax 
is weird, it's far easier to get started with than YUI.

I guess Microsoft has recognised the upcoming threat Cheyenne poses 
to them, and taken countermeasures ;-)

How do you add another webapp?  Just place it in the same block as 
the existing webapp [ ] block?

domain.com [
	webapp [virtual-root "/app1" ...]
	webapp [virtual-root "/app2" ...]
 	...
]

so, this should be okay?

default [
	webapp [ ]
	webapp [ ]
]

Henrik, I did the same thing the last 3 days :-). Yes, weired syntax. 
It took me 30min to SEE that I have missed a # to reference an element... 
To many braces. But really simple to use than. Do we have a jQuery 
group?

Sessions: Just using session/start at the beginning of a RSP page 
doesn't start a session. You have to add at least one name/value 
pair to get back a SID. Is this intended?

Robert, the private javascript group doubles as a jquery group.

Graham: yes as long as you put something inside the brackets ;-).

Sessions: when you use session/start, you don't have the SID available 
immediatly, but  the SID is sent in the response. The reason is that 
RSP session management is done inside the main process and not in 
the RSP process. So, from the RSP point of vue, the SID is only available 
on the next client request. I think that this can be changed so that 
session/start generates a new SID that can be used at once in the 
RSP.

I'll try it again ... I was getting something odd where Cheyenne 
kept looking for // in the path to my webapp files

I had a problem the other day where I had what looked binary appearing 
on my RSP pages before everything else.  I had to restart Cheyenne 
for it to go away.  Wierd.

Sessions: Doc, I think making the change makes sense. Because otherwise 
one need to trick around with a dummy call to get the SID into the 
next (the real) RSP call.


IMO thing would become much simpler if session/start immediatly gives 
the SID / access to the SID.

Graham: you should check your 'on-page-start handler, maybe you've 
forgot some code inside (you can found it in %app-init.r)

Session: sure, it might be useful, but there's no simple way to garantee 
that the new SID is not already used in the main process...The new 
SID should be random enought, but anyway, I guess you'll just have 
to cross fingers ;-)

this is all I have



on-application-start: does [
	;--- add here your library / modules loading
    *do %private/captcha.r
    captcha/set-fonts-path %private/fonts/
]

Sessions: I thought RSP processes are started from the main process. 
So, why not create a new SID (if necessary) in the main process and 
give it to the new RSP process?

Database: Are all database drivers included in Cheyenne or do I need 
to load them on my own? And if, how?

Sessions: RSP processes are started from the main process. The SID 
*are* created in the main process that's why you can't have your 
SID at once when you call session/start, you're in the RSP process, 
not the main one.

If you meant : create a new SID each time a RSP is called in case 
the RSP script uses session/start, that could be a solution, but 
not very elegant.

Database: no driver included, you have to load them. The best place 
is in 'worker-libs config block (see ChangeLog.txt). For webapps 
specific libraries, the best place is 'on-application-start in %app-init.r.

Sessions: Maybe my model of how sessions are handled is wrong. I 
think/thought it works like this:
1. Main process gets request from client

2. Main process checks if for this client a SID exists, if not creates 
a unique one
3. Main process starts RSP process and provides SID
4. RSP process either uses SID or not.

Not all RSP need to run in a session. You're wasting some resources 
there. But I agree that the SID should be available as soon as session/start 
is invoked.

Does it has so much overhead?

How about just creating the SID and do the rest as soon as session/start 
is invoked?

cross-post ... doc, do we have a captcha level of 0 so that a blank 
captcha is generated for testing purposes?