World: r3wp

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?

Not sure it worthes it. Just comment your test for captcha text.

SID & session/start : I've added that to my todo list, need to think 
about that deeper before implementing.

Graham: you can set your webapp (or at domain level) in debug mode 
(using the 'debug keyword in config file). If the debug mode could 
be tested, it could allow you to enable/disable the captcha system 
(or anything else) based on the working mode (debug / in production). 
I'll add that to the todo list also.

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?

Just wondering how much data I can store in the session object.

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.

I guess it boils down to whether the slow down with large objects 
is still faster then requesting the data from the db.

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 think that the DB will be slower, but it depends on how big are 
your "large objects".

I suspect only a few mbs

Wow...that's huge! Why do you need to maintain so much data in session? 
Why not store it on disk?

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.

That way I wouldn't have to keep fetching the data from the sql db.

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.

If you've requested the data once, why not cache it in the session 
object ?

I guess that's the general question.

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.

Ok, premature optimization then.

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.