AltME groups: search

I've used YUI with Cheyenne before ... but am now looking at a different 
Javascript library.

jQuery seems to have a lot of traction, and there is this great set 
of introductory videos on how to use it http://nettuts.com/articles/web-roundups/jquery-for-absolute-beginners-video-series/

all I did was create a new webapp directory and renamed the webapp 
directorie to point to the new directory.

Warning message: that's normal and part of the RSP script I use for 
testing. Currently the internal request forwarding system has a hard 
limit (4) on the number of recursive calls. When the limit is reached, 
a warning message is logged.

From faq:

A webapp is a directory in the webspace which is protected by an 
authentication cookie. It is specified inside the httpd.cfg, where 
there is a sample "testapp".

Well... what is "webspace"`? Is a webapp useable by all virtual hosted 
domains? And what do I do with it?

Not sure I understand all this (yet). Let me start with a simple 
thing. :-)


Are there are any RSP examples to look at? I just need to get started 
and see how it works.

Would a simple file containing:

<% now %>

work?

A webapp is just a container for a bunch of RSP scripts working together 
and protected from outside (you need to log in to get access). There's 
some events that can be used (defined in %app-init.r). There's also 
support for /public and /private sub-folders.

Btw, if you don't know how to build RSP scripts, you should first 
have a look at ASP or JSP online documentation, so you can get the 
concept and usage. RSP API can be found on http://cheyenne-server.org/docs/rsp-api.html

If anyone wants to contribute to Cheyenne's wiki, just send me a 
private message and you'll get an account.

As a design principle, I don't want to have code inside the config 
file. Why would you need that?

I run several domains as virtual domains in lighttpd. And I have 
one document root for Cheyenne. The idea is to be able to add the 
same RSP page (like a shopping cart) to severl domains without having 
to duplicate the RSP code pages.

If a request to an RSP page via domain2 comes in, I would like to 
be able to reference directories inside the domain2 directory.

without the -q it's impossible to run the server as a background.

Doing a search .. looks like I was having that conversation with 
Gabriele about the linux SdK and launch in 2006.

Oldes: Graham is using CALL from RSP scripts to do image processing 
IIRC. I never used CALL from RSP myself, so I can't tell. It seems 
to me that it would be faster/safer to wrap an image processing DLL 
than launching a new process for each new request. Using CALL from 
a RSP is like dropping to CGI, you're loosing most of RSP speed benefits.

I have one page of my hylafax application that calls imagemagick 
to convert a tiff to png so it can be viewed in the browser ...

Ok.. then we should write a wraper for imagick, because that's what 
I want to use as well.

Thinking about web-app appliances. Not sure if this idea alreaday 
exists but IMO a good thing to think about.


If I have a RSP based web-app (for example my super-cool-all-you-need-shooping-cart 
system) that I would like to sell it would be nice to bundle cheyenne 
and all the RSP stuff into one package. The user just installs it, 
sets up a simple reverse-proxy and has everything up & running.

IMO this would be a killer feature for Cheyenne.

We can't expect people to change their existing web-server. We can't 
expect them to install Rebol interpreter, create new CGI setup etc.


But we can expect people to install something on their system, add 
a little config stuff to the existing setup and have a cool web-app 
up& running.

Most web-apps or modules are just to all-or-nothing. I just want 
a simple thing but get a bunch of stuff I don't want to use but I'm 
forced to.

Very interesting idea. My easy-cgi tries to serve as a "package", 
which can be just copied to any cgi-enabled site. I am at very beginning, 
not really trying to do more than simple cgi stuff, sqlite, sessions 
....

If Cheyenne as a whole could work this way, I might consider using 
it. Other than that, I can't easily replace Apache at hosting location 
....

The main problem I have with a lot of the available tools is, that 
integrating several of them into one solution is far from easy. There 
is no loose coupling possible.


You need PHP version XYZ with module ABC and libc version IJK etc. 
getting all this to work togehter is horrible. It's fragile and hence 
a nightmare to scale or operate.

Being able to install web-appliances with a smart and simple integration-interface 
would be very cool.


I'm going to try this with the shopping cart stuff. We will see how 
it will work. Adding a simple deploying mechanism shouldn't be that 
hard than.

Robert, what your explaining is one of the main goal of Cheyenne. 
:-) Simple, lightweight, all-in-one file web applications deployement. 
Still some work to be able to achieve that, the main missing feature 
is a good and lightweight virtual file system for RSP scripts (so 
you can run them in source form or encapped with Cheyenne without 
changing anything).

Sure you can rent your own server but this implies that you know 
what to do with it and how to operate it. Something a lot of people 
can't do.

Tweaking: I'm all for it but via a simple dialect driven way. Keep 
it simple. I don't want to hack several CSS, HTML, pre- post-processor 
files etc.

and I can also think of situations where prepackaged app in a single 
exe would be preferred, so I agree back :)

Pekr: I made a deal to get a smaller VPS in slovenia for my local 
projects. I pay 12EUR and I am currently running one cheyenne webapp, 
2 apache solr engines with multiple 1000 records (search engine / 
indexer),  and a multitude of bots for search engine.. without any 
problems . All VPS-s in slovenia start at 36EUR and are bigger (more 
HD more RAM) , but I started asking various providers if they can 
get me smaller package for smaller fee and I got one :) . If you 
are looking international you have good and cheap VPS-s at Linode 
, I also used miniVDS which is only 5EUR I think (and intend to again 
in future)

I have one question... after working in various other languages + 
mysql/sqlite I am using normal files with rebol structures and LOAD 
for my first projects here. Now I have a little more serrious project 
up so I started thinking if by using just files I can corrupt data 
somehow. I am not that good on low level details, but I imagine that 
I don't have to worry too much. Because cheyenne is single process 
I imagine only single write to file can happen to some file at any 
given time. Am I correct or wrong?

Janko - renting external box is not what I regard being a deployment. 
You can't easily request all your customers to move their already 
existing sites to your new hosted server. That is not much practical, 
but I do understand your reasoning ...

I am not sure if cheyenne starts new process for each request , I 
suspect it uses async sockets and serves request at a time

ok, that is true .. if some company has a website and wants some 
additional app there it's not good option to say relocate it all 
to vps..

yes, that is another problem and I am aware of it (basically that 
is not a problem here).. the last writer wins... I am just worried 
if any data corruption can somehow happen

that is the same if you have a simpler mysql based webapp.. one person 
starts editing text, another person starts editing , first saves, 
second saves.. first person looses the changes.. that is basically 
problem on application level and is the same here as if using RDBMS

Petr, the filesystem will ensure that this won't happen. The thing 
is, that for the time you write to the file, you get a file-lock. 
But this is immediatly released after you finished. So, if you try 
to write to a file with a lock, you get an error.

A DB handles this by having one file lock for the database file all 
the time, taking several request at the same time and doinga  DB 
locking scheme on-top of the filesystem locking.

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.

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

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.

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.

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?

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

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.

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.

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 :(

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.

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.

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 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.

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?

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.

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.

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

That could be already tested right now, thought. Just use : 

debug?: to-logic find request/config 'debug

(the 'on-page-start handler could be a good place for that)

doc, what exactly is a session object?  Is it something that is server 
side only?  Or is transmitted to the client as a cookie?

A session is a block! of name / value pairs that is kept in Cheyenne's 
main process and exchanged with worker process. A synchronization 
system is there to avoid concurrency issues. The SID sent by cookie 
to the client is just a lookup key. When sent back to the server, 
this key allows to identify the right session object to pass to the 
RSP script in a worker process.


You are only limited by memory, but remember that the session object 
is MOLDed / LOADed and exchanged by TCP twice for a RSP request. 
So, in order to keep your RSP pages fast enough and scale well with 
a growing number of active users, keep the session block! as small 
as possible.

This is precisely where Cheyenne could benefit a lot from a multihreaded 
REBOL kernel : no more need to MOLD / LOAD session block and request 
object, no more need to exchange it through TCP with other processes...That 
would allow a big boost of RSP performances and reduce Cheyenne's 
whole memory usage.

I suspect only a few mbs

If I want to keep all the data for a patient in a session .. and 
have mutliple  patients, I was thinking of keeping all the results, 
consults etc in the session object.

Or, if I have just the one patient as an object .. then if I move 
to a diffferent rsp page, and then back again, I don't have to refetch 
all the data.

I'm just wondering how to simulate tabs in a rsp page ... do I have 
to recreate the tab each time I switch to it, or can I keep all the 
data in a session.

Do you really need several megabytes of data to display each page? 
That sounds very odd to me.You should store your data in a DB on 
disk and only request from DB the data needed for display.

Tabs: that's a client side question to solve using HTML/CSS/JS. Tabs 
are not a standard HTML element, so the solution depends on  how 
you build your tabs, how you want to manage them,...

General answer: session data is exchanged by TCP for each RSP request, 
so the performance penality can be high for huge session data. That 
also means that your server won't be able to handle a lot of user 
session at the same time.

In one of my RSP based app, I have pages with tabs. I use 2 different 
approach :
 

- for tab panels with data cross-dependencies : I use a unique RSP 
script generating a page with a unique <FORM> tag and each tab content 
is simulated by <DIV> sections that I show or hide (with JS) depending 
on the selected tab.


- for tab panels with no cross-dependencies : I use a separate RSP 
page for each tab content. The tab bar is a unique RSP script included 
by each "tab content" script.

I currently doing the latter ... and I guess it's better to let the 
client store the data in their browser in a hidden div rather than 
the server store it in a session.
Not sure what you mean by  unique form tags though.

That just means that, in that case, when I have multiple forms spread 
out in several tabs, I use a unique <FORM> tag to be able to send 
all data together when I need to save all the forms.

Let us know if it's reliable, I guess that a lot of people here who 
would like to know (including me).

Any feedback on this filter-validate-process dialect is velcome.. 
(it is meant for processing posted form data)

first word in row is request field name ;;; req | opt  is  required 
| optional + default value  ;;; than you can have a chain of aditional 
validators like int , string , email, url , one-word ;;; then you 
can have check which executes your custom code and if it returns 
a string it uses it as validation notice ( to check something app 
specific or in DB for example ) ;;; then you can process the value 
with do and again custom code the returned value of that block of 
code is set to that field ..

filter-validate-process-example: 
[
	id req and int .
	username req .

 email req and email check ( either email-exists email [ "email taken"] 
 [ none ] ) .
	website opt "" do ( to-visible-url website ) .
	adress opt "not given" .
]

I am not 100% on few things ... should I use short names like req 
opt  or whole required optional ... and more technical about check 
and do (I will rename this to proc or process )  .. should I create/bind 
to words that are the same as field names , like this upthere ... 
or maybe use something like this so you use ( to-visible-url this 
) I don't like creating a bunch of words that won't get used mostly... 
but I thought I need to so I can use this for typical password / 
retype password example like this 
	...
	password req .

 password2 req check ( either password == password2 [ none ] [ "passwords 
 don't match" ] )  .
	...

Defining a good dialect (simple, short, efficient) isn't an easy 
task. Chris did some work about such form validation dialect in QM. 
See http://www.rebol.org/documentation.r?script=filtered-import.r

I found a possible bug in RSP yesterday: When RSP gets the values 
passed to it as get query parameters, it removes url-encoded html 
tags and comments from the values. This is not correct with values 
that come from a textarea, or probably other values as well. I haven't 
tested with multipart/form-data encoding yet.


This might be a setting change rather than a bug in RSP, but if so 
then show.rsp should be changed to not strip tags from values and 
then html-encode the values when shown.

If it is a setting change, I would like to edit my local copy of 
show.rsp accordingly asap. I'm using show.rsp for browser analysis.

IIRC, it just apply a DEHEX, but I'm not sure to understand what's 
the issue. I agree with adding html-encode in %show.rsp. Could you 
provide a short example?

Can you be a little more specific please?  Are you talking about 
"values" from request/content or your own one?

I'm programming RSP scripts since than more a year now on a daily 
basis and I never noticed such behaviour with values received from 
form submission and accessed through request/content (which is the 
way you should use to access passed values).

basically:

data: select request/content 'submitteddata ( from a textarea )
parse/all data [ thru "phone" copy phone to etc  ]

print the parsed data ... but the printed data when none would produce 
data from a previous form submission .. weird as though it were preserving 
the context somehow.  

fixed it by initializing all the variables I am expecting to parse 
out to none at the top of the rsp page.

This is for a web app

What I am doing is taking a text screen dump from an AS400 terminal 
( see http://synapsedirect.com/forums/permalink/7675/7675/ShowThread.aspx#7675
) and parsing the data so that I can grab the patient demographics 
and add them to the database.

I once used the telnet scheme from F. Sievertsen to script and query 
automatically a host system. Maybe this can help too.

What about closing your data in a context?

Let's clarify a few things :


- Request/content is working OK in your example, there's no issue 
with that.


- Using variables in PARSE rules without initializing them is a bad 
programming practice in my book. You *should* initialize them before 
using them (unless wrapped in a function which will do the work for 
you). If your parse rule fails, your code may error out (or you may 
get an unexpected value) when trying to print 'phone because it hasn't 
been initialized. 


- You seem to expect that RSP script will be evaluated in a fresh 
REBOL session each time. This is not the way RSP works. RSP uses 
persistent pre-forked processes for performances. If you expect a 
fresh REBOL session each time, then this is the CGI model which is 
an order of magnitude slower than RSP. 


- Even if RSP processes are persistent, they can be restarted or 
killed and you can't control which process will executed your script, 
so, just as a warning, you can't expect that a "global" variable 
will be still there for the next RSP script evaluation. If you need 
value persistency, use a session variable or write it to disk.

That's the main feature making Cheyenne/RSP a much faster solution 
than Apache/CGI for server-side REBOL code.