World: r3wp

DB Chat?

Robert - thanks for explanation.. I should of known these things 
but I have been in mysql world too long :)

Pekr a little help for the problem when a existing apache/lamp website 
needs additonal web-app that you would want to write using cheyene 
would be to use Apache's mod_proxy to map just some path to cheyenne 
 > ProxyPass > ProxyPassReverse  -- http://httpd.apache.org/docs/2.0/mod/mod_proxy.html

Cheyenne serves static resources from the main process (UniServe 
process), but CGI and RSP are executed by pre-forked worker processes. 
So yes, writing to the same file from RSP script can be an issue 
if you don't have a mean to ensure that write accesses are serialized. 
I had that issue recently for RSP log/debug file, I had to build 
a small logger service in the main process to be able to serialize 
 write access (after stress testing different file locking solutions 
from REBOL, no one seemed reliable enough to me). 


I thought about adding a synchronization service in Cheyenne that 
could be used to (but not only) address the write file sync issue. 
That could work for low sync needs (like writing to a file once every 
few seconds), but for massive sync needs (dozens or hundreds of sync 
req/s), I'm afraid that the TCP port overhead would be too costly...(maybe 
a separate sync server process with persistent TCP connections could 
be good enough even for heavy uses?)

aha, so rsps work on multiple worker processes, interesting.. well 
I think to me it's not a problem as each user has it's own data files 
so it's hard to imagine multiple writes could happen at the same 
time for the same file. And if I would need something reall y heavy 
duty I would make a server serving files and caching them in ram 
for speed etc, which would also take care for sync. or something 
off the shelf

If you have a page with 2 (or more) frames, each pointing to RSP 
scripts that may all write to user's data file...that could be a 
problem. Same issue if your user opens 2 browser windows, or several 
users using the same account...the risks are not very high, but such 
cases can happen.

since processing of requwest seems to take just 1ms I think chances 
per user are slim. What would happen in it collides? would one of 
processes "get file access error" or something worse can happen by 
your exp? (I was asking about the fear of file getting corrup / half 
written before)

uh I a sleppy already it seems "happen in it collides" = "happen 
if it collides"

Hard to say, but I guess that the second.

There are some wrappers for imagemagick on windows ... but I'm not 
aware of anyone having done that in Linux.  Maybe the qtask guys 
have done that as they use imagemagick ...

It should work with .so as well... I can check it when I will be 
under linux. If you need just the conversion, it's easy.

Let me know how it works :)

You can get file access errors and corrupted data in file (last write 
wins probably). A simple RSP page may be rendered very fast, but 
there's situations where it can take much more time. Imagine a complex 
query on database or using CALL to a third-party command-line tool.


With RSP pages rendering in a few ms, the risk for collision is very 
low, but it's not zero.

but in this case will be cheyenne slow or the database itself ?

There are two things to distinguish:

1. You need a locking strategy on OS/Filesystem level. On Windows 
take a look at the LockFileEx for example, to see how it is handled.

2. Depending on your app, you get/have an application specific locking 
concept. That's what SQLite for example does. This concept than is 
implemented using the different OS calls.

Because different OS use/support different functions, it's a platform 
specific implementation. Smartphone for example most likely don't 
have any locking support at all. So, the app has to fake it completely.

If you just work with plain files, you have to do 2. on your own 
our ensure that files are never accessed by two seperate running 
processes. Faking an exclusive lock is not that easy. You have mostly 
three options:

1. pessimistic locking strategy
2. optimistic locking strategy using conflict counters
3. academic locking strategy

Oh, and if you really think that's it about it. Wait: If your files 
is on a Samba network share you have to deal with the Samba way of 
locking, not the OS where the file is stored on. And Samba locking 
can be problematic as well.

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.