World: r3wp

cheyenne-admin also has a *VERY* nice GUI, using GLayout.

already using cheyenne-admin to setup my bash user config files (~/.xxxx 
files) copying files locally, editing in ultra-edit, and uploading 
them back  
all via one click for xfer   :-)
I'm lazy  hehehehe

what do you use the admin for ?

Note this is a linux server-side only tool (currently).
currently:
	-remote browing of files in a gui.
	-uploading/downloading any files to/from the webserver
	-running command-lines remotely
soon: 
	-chmoding remote files
	-handling webserver start/stop/restart  remotely.
	-more as time goes by.

so you run the tool on the server PC?

ie. you can't run it from a client PC?

nope locally.

I meant the server has to be a linux box.

anyone know if there is a detailed doc on sessions within cheyenne?

what we need with !cheyenne are minial examples of services and mods 
which implement all callbacks and give just a small comment on why 
and when it is called... this would help soo much in understanding 
how to implement cheyenne extensions.


I am currently looking at the rsp code and its so huge and complex 
that its a big daunting to grasp the whole by looking at its parts.

Mod-RSP is the most complex one and it does a lot of things. Sessions 
in Cheyenne are RSP-specific. There's a synchronization system in 
RSP sessions for protection of session data from corruption in concurrent 
executions. That may be easy to understand by just reading the code. 
Anyway, feel free to ask for explanations of specific code parts.

yep it is complex hehe

you mean that if two requests are sent to different task-handlers 
they will resync when the later is done?

or is it rather some kind of semaphore?

there are too few comments (read as almost none ;-) in your code, 
 and that doesn't slow down server in any way   ;-D

I mean... more comments wouldn't slow down the server hehehe

Sorry: that may be easy = that may not be easy

It works using a semaphore (session/busy?: yes|no). It used to be 
very fined-grained with distinction of RSP scripts just reading session 
data from scripts modifying session data, but it was even more complex 
to maintain and the RSP source static analysis I was doing could 
never be 100% accurate (it''s easy to bypass any form of static analysis 
in R2). So now, it just blocks concurrency inside a user session 
(only 1 RSP script per user session allowed).

Session data is passed to task-handlers along with each request and 
saved back in main process on task-handlers response.

so an rsp script cannot call another rsp script within its links 
for images, for example?

well, actually it can... its just not going to download concurrently.

Yes it can, from the server perspective, it's just a sequence of 
RSP requests.

If you can think of a solid method for allowing concurrency in the 
same user session, while preserving session data from corruption, 
I'll be very interested.

I should add : without loosing performances.

a part from having handler tcp interaction, I can't think of any 
a part from identifying a way to detect which session data is being 
used by both scripts.

It's always possible to write session data to disk or to a DB and 
rely on the DB locking system to ensure that data is safe, but there's 
a performance overhead in that case that I'm afraid, may not result 
in any speed gain for the user. It also requires to have a DB engine 
installed on all servers running Cheyenne using RSP sessions, which 
might be overkill in some situations.

this being said... mod-remark will be using persistent liquid nodes 
for session and post/get parameter side of things, and its possible 
that I might store session data outside of the server itself, using 
a liquid-tcp node. 


so that access to actuall session data could be brokered outside 
the server's jurisdiction, extremely efficiently, locked one value 
at a time. and any access/change could be perpetuated to other handlers 
when they attempt to lock to one session value.

the idea being that interacting via xml request or full page refresh, 
with only part of a page parameters, creates the same output  :-)

sorry, stores the same session information.  allowing the same output 
depending on the required refresh.

you could actually have one page sending xml requests to the server 
in ajax, and another page refreshes with the results of those requests...


the second page could also send a page request with the some parameters 
sent, and the server will reflect all changes to the current session/page 
so far.

I thought also about doing a TCP based session server (with session 
variable granularity), but the overhead in synchronization would 
hit performances (and scalability) too much IMO. If each time you're 
setting a new value to a session variable in a script, you have to 
query a TCP server (even a local one), that would have a huge impact 
on a script execution time.

That impact may not be significant (nor noticeable) if your server 
is handling 1req/s, but it would be if you have to handle 50req/s.

might still be much faster than a db call.  but the real game-changing 
aspect of mod-remark is that a document in ram, will only render 
parts of itself which are changed, or which cannot be cached, so, 
unless you've actually changed a parameter, it knows that it hasn't 
changed and will not need to ask for the broker to give it back the 
value.  in fact, it wont even process that part of the page, only 
using the data in its local node cache directly.

header/ footer / current login state box/ static page content... 
this can be shared accross sessions, across the entire site, or as 
granular as a single page request.

a news reader could have all the news items cached already and all 
its doing is assembling those which are matched via the request... 
really only doing a fast rejoin of many items, and then a rejoin 
of header news and footer and then spit it out.

all the code which was originally called to create the news items 
is skipped... until some site parameter changes how the news items 
are built, which will automatically cause the news item to reprocess... 
 but on the page and server side, nothing special needs to be done. 
 liquid's internal caching will fork the processing by itself, and 
then start serving the new cached data the very next time any single 
news item is asked for again.

That's quite close to how RSP are working. Each RSP script is compiled 
to optimized REBOL code and cached in memory. A RSP request will 
then result in evaluating the REBOL code which mostly just append 
static and dynamic parts in the output buffer.

nice.

the difference is that with liquid, its explicit, and I can explicitely 
share some data accross many scripts, but just some of them.    the 
headers can be half cached, where each page uses half the common 
header, inserts its local menu into it, and that header is now permanently 
cached for all further requests of that page, but it used part of 
data which was already cached by another page.

the current issue is trying to share the cached data between different 
handlers... which pits me against a liquid value broker, but its 
the creation of the data on the broker which might become complex... 
so not yet shure how I will proceed..

with threads, this issue would be much simpler to solve.

Max, applying dataflows principles to a web framework looks really 
appealing, when will be able to see some demos?

I am aiming for sometime next week, just a few simple prototypes 
to explore how to handle the difference in  nature of web requests 
opposed to persistent  data.

I am pretty sure I wont tackle handlers for a while...  because of 
the code sharing complexity added.

if the lazy processing equates to as much saved processing as I have 
seen with graphics work so far, I might not even need external handlers 
to handle many requests/sec.  It would be nice if you could pit your 
stress testing setup against mod-remark once it starts actually doing 
its thing.  :-)

at this point, this is still all research, but the more I apply liquid 
to specific problems, the more confidence I am generating,  as it 
almost always lives up to its potential.  When it doesnt', its usually 
that I just didn't find the proper way to use it.

query-string: Ah, the problem comes from a wrong rewrite rule for 
GET requests. I need to figure out how to handle this case.


That's what I like about web-stuff: There are so many possibilities 
and places that something can fail...

Graham: Is this a cheyenne issue?
Robert: Yes, I just checked the LOG files. [...]

So, no, it's not an issue with Cheyenne.

I didn't think so

No, it's not. The LOG files are correct but I didn't saw the double 
" ?" ... Sorry, as said: To many places where something can go wrong.


Perhaps, it€s possible to throw an error if a male-formed query string 
is found.