AltME groups: search

OK
You said "15-november" :

Okay, my READ-IO emulation has been removed in the last version. 
I've replaced it with a safe 'cgi-read-io function. I plan to put 
it back soon, I think I know how to make it work reliably now.


I need a cheyenne.exe with this done. Is there one somewhere or do 
you need to build it ?

Assuming my ISP is running Linux, what do I have to get them to do 
to be able to run Cheyenne? (if this is all doc'ed, just point me 
to the URL ... thanks).

All my stuff is hosted on http://www.webarama.com.au/and they've 
been pretty amenable to my other requests. Is it just a case of getting 
them to "install" REBOL for me much as Perl is? If so, which version 
of REBOL do I need? Can I get away with /base?

That's rather similar to mine, but there's a lot it doesn't do yet

I'm trying to serve JPGs through an RSP Page.  The following is the 
entire contents of the RSP Page:

<% 
	do %init.r

 results: SQL rejoin [{SELECT data FROM images WHERE id="#^{} select 
 request/content 'id {^}"}]
	unless empty? results [
		img: first first results
		response/reset
		response/set-header 'Content-Type "image/jpg"
		prin img
		response/end
	]
	print "FAIL!!!!"
%>


This seems to almost work. But I have to load the result twice in 
REBOL to actually get the image.


view layout [image load load http://localhost/image.rsp?id=375A5EDB9102ECB08B3A185186650D3C]


Displays the image.  The value returned from the Database is Binary! 
so it should be the same as read/binary as shown in the example of 
how to do this in the Cheyenne docs, shouldn't it?

Any ideas?

Hrm...  The script wasn't loading the image where I thought it was. 
The data was actually Binary!  not Image!  so I'll have to do some 
more digging...

Strange...  


I added some working JSON...  Somehow the .rsp file handling the 
JSON request is using functions that aren't including in the rsp 
file.  Is it supposed to do that?

Has anyone written Atom or RSS output code in RSP? I am going to 
need to do so right away and every possible speedup helps.

Do the Cheyenne processes disappear when your test fails? If not, 
did you try to access a web page to see if it's still responding?

REBOL/View 2.7.6.3.1 14-Mar-2008
Copyright 2000-2008 REBOL Technologies.  All rights reserved.
REBOL is a trademark of REBOL Technologies. WWW.REBOL.COM
>> do %cheyenne.r
make object! [
    code: 303
    type: 'script
    id: 'expect-arg
    arg1: 'context
    arg2: 'blk
    arg3: [block!]
    near: [extension-class: context list]
    where: func [/local list][
        list: extract phases 2
        forall list [change list to-set-word list/1]
        repend list [to-set-word 'service none]
        extension-class: context list
    ]
]
>>

BrianH: do you have a list of patches to apply to R2.7.6 ?

I thought that you would do that  just before sending your laptop 
to Carl. ;-)

Same idea here Doc. Apps can do individual logging, which can then 
be merged for analysis. But if you need everything to go to a single 
log file, you need a controller for them to go through. I'm also 
still very big on the DTrace model.

It would require a change in the RSP DO-SQL function to cope with 
several result sets.

Robert, one thing you can do for sure is reverse proxy rsp to cheyenne 
and serve static from lighthttpd 8)

of course you'll have to enable the proper modules in apache and 
for the first example, you only need ProxyPassReverseCookiePath if 
path do not match 8)

Before setting-up the reverse-proxy config so that I can use cheyenne 
with all RSP features I have some questions:


1. Session handling: I understand that sessions can now be used via 
cookie, URL-parameter or POST data. How do I select which method 
to use? Can I start with Cookies and if this fails (can this be detected?) 
fall back to the other methods?

2. This one http://www.rebol.org/view-script.r?script=sqlite3-protocol.r
should work with RSP's DO-SQL, but untested. You still have the option 
to bypass RSP's DB layer to use any driver you like as you would 
in a normal script. Just remember that your code will be executed 
in several processes, so you can't rely on global words, nor assume 
that opening the connection just once will be enough...


Btw, doesn't SQLite have issues with write accesses from multiple 
processes? I've read that each process has to synchronize with others 
for write operations because SQLite don't provide such layer. Is 
this still true with recent SQLite version?  (Maybe I've just misunderstood, 
I have no experience using SQLite).

1. "You can send it back by cookie or included in GET or POST data." 
Well, my understanding is that the YOU here refers to the delivered 
page. So, the page needs to be prepared a priori to delivering with 
either the session-id etc.

But if I do this, I won't need a cookie at all.


So, I first need to check if cookies work? Is there a simple test 
function in RSP like: COOKIES-AVAILABLE?

1. Good point. You need to use the session/active? to test if a session 
has been automatically created, if not, that means no cookie support 
(require to serve a RSP page first, then check on the next call to 
a RSP page, an HTTP redirection might help you do so). Then, you 
can use session/start to manually start the session and send back 
the SID.

How safe it's nowif I would use call from task? For example to do 
image processing?

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.

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

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.

What you describe would mean, than you can only do one CGI request 
at the time. Cheyenne will launch new CGI process at each request, 
hence your file operations could collide. I like SQLite very much, 
but they don't provide server level functionality. They are able 
to work at file-lock level, but dunno how solid it is ...

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

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

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?

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

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

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.

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" ] )  .
	...

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.

In theory, it should be possible to set to none each new webapp variables 
used in RSP scripts by querying the webapp context object. In practice, 
I'm not sure it can be made 100% reliable because you can always 
declare words using SET in global context (which would be much more 
difficult to clean up without breaking the RSP engine). The other 
reason is that, as a side effect, it allows some dynamic code caching 
like this one :
<%
	if not value? 'my-lib-loaded? [
		do %private/my-lib.r
		my-lib-loaded: yes
	]
%> 

This can be used when you don't want to pre-load some libs from the 
on-* handler, but load them dynamically, only when needed. So you 
pay the cost of loading only once for each RSP process when the script 
is first called (and you can clean it when no more required by, for 
example, setting the word referring to the lib context to none)

Yes, that gives quite extreme performance. It's an elegant way to 
solve the problem of caching that others are providing via expensive 
slap-on solutions rather than by design. This is also why I got the 
idea that you would be able to create VID-like applications in the 
browser, because data is always resident server side, like an app.

The session data problem gets reversed: You have to avoid data to 
spill over to the next user of the app. This could provide a very 
unique way to handle form data, by simply dumping POST data in a 
resident object. Then you can quietly decide what to do with that 
data without having to worry that it's forgotten at the next page 
load.


Session data is about storing that data in a context isolated for 
that user. I've not studied closely how Cheyenne handles session 
data, but I've been working a bit on the form issues for REBOL/Forum.

Dockimbel, that might solve some problems I had with form submission.


My intent with forms was to provide an easy way to have all form 
data provided by the server via an object. When you create a new 
object it would hold info for when the form was created and a unique 
ID for the form.

Through that you can tie a form instance to a specific browser instance, 
and when the form is submitted, you can do server-side verification. 
If the verification fails, the form object remains and the page is 
redisplayed. If the form object validates, then the form object is 
removed or copied away from the block of existing form instances 
and can no longer be used from that form instance, if you attempt 
to submit again. This would eliminate accidental double submission, 
although not regular spamming. By having that framework, setting 
up a flow for how to handle form data, server side, would be simpler.

This doesn't sound like so much, but I happen to have an HTML dialect 
around, where I can create forms as objects in a simple way, and 
applying actions or handlers to forms, makes it much more like programming 
a real GUI. It could probably scale down to single text fields and 
a bit of AJAX.

I would initially not try to do VID graphics directly, but to do 
something like this:

html-view [
	text (reform "The current server time is" now/precise)
	display-name: text
	name: field

 button "Submit" [set-html-face display-name get-html-face name] ; 
 'name is stored on server too
]

... well, let's see how easy that is in JS :-)

I normally do this, but for some reaason I was thinking cgi instead 
of rsp, and so thought I didn't need to do that.

Is there anything I can do to debug what is going on?

REBOL [
	Purpose: "RSP environement init code"
]

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

on-application-end: does [
	;--- add here your library / modules proper closing
]

on-session-start: does [
	;--- add here your per session init code
	;--- ex: session/add 'foo 0
	;--- that can be latter accessed with : session/content/foo
	
	session/add 'user "guest"
	session/add 'hits 1
]

on-session-end: does [
	;--- add here your per session closing/cleanup code

]

on-page-start: has [][
	set 't0 now/time/precise
]

on-page-end: has [pos time][
	if pos: find response/buffer "</body>" [
		time: to-integer 1000 * to-decimal (now/time/precise - t0)
		insert pos reform [
			"<br><br><small>Processed in :"
			either zero? time ["< 1"][time]
			"ms.</small>"
		]
	]
]

If there's nothing I can do to debug this, I'll restart cheyenne

I will also expand the href to "http://www.compkarori.co.nz:8000/pdfs/testpdf4.pdf? 
+ now (  I do this stop caching the form contents )

Well, I think that I should make the timings optional. I'll add that 
to the to-do list, thanks.

I am trying to move my webapp to the real server (which runs on debian 
linux) ... and I have some problems with making cheyenne work with 
SQLITE on linux.. did anyone do that already?


cheyenne runs fine but when I come to the part that includes sqlite.r 
it crashes...  I installed sqlite3 via apt-get, I copied rebol core 
into same directory as cheyenne (exec) is and also in same directory 
where sqlite.r is (because after some testing with >> do %sqlite.r 
<< in normal rebol I saw that it searches it in that directory) ... 
 but I get the same error .. I can't test including sqlite in ordinary 
rebol fully because when I set the right path rebol says >> feature 
not available in this REBOL << (I have rebol core 2.7.6)

I want server to "flush" responses as fast as it can and client render 
them without compressing/decompressing ... I might be wrong and I 
will test if there are any differences, but I had bad exper. when 
we tried to minimize and *gzip* js libs (like they usually) do the 
website latency actually became much worse with gzip than without

can users access a web app using basic authentication .. or do we 
have to write that ourselves?

How do you handle file uploads in Cheyenne RSP? I have a need to 
upload a file regularly. Post is fine - I don't need put.

Ok, I will try. Even I don't fully undertand what to do.

IIRC, he said that it was maybe just a flag to set to activate server 
mode, but he had to do some research about it first.

I use Cheyenne as a reverse proxy. I think in this setup the HTTPS 
things is handled by the primary web-server, communication to the 
revers proxy is non encrypted and hence this setup should make it 
possible to use Cheyenne's RSP with HTTPS. Not elegant but it should 
do the job.

To build a binary from Cheyenne source, just do : enpro (or enface) 
cheyenne.r

I need to be able to verify a connection from a client right when 
it happens.  so that I can refuse it based on some conditions and 
do some other client-internal stuff.

SSI from RSP: you can load it, but it won't be processed. There's 
no buitlin way to process SSI from RSP, but you can extract the processing 
code from SSI.r and load it in your RSP to do that (maybe not the 
simpliest solution...).

the main job will be to do build a set of tags which provide easy 
.net type form post back handling, without the need to have 15 scripts 
or  excessively complex php-like scripts to properly handle form 
data.

that is actually easier to do than the form stuff hehehe

I'll probably do the remark v3 as I am doing the module... so when 
that is done, plumbing will be quite literal term for uniserve wrt 
to the module   ;-D

thanks sooo much for keeping with me... I know its a redundant thing 
to do (supporting noobies all over again), but its really appreciated.

Will, no. It is not like load testing app or something like that 
, it is meant to test functionality of webapp backends -- if they 
do as they are supposed to

Not sure what you're trying to do, but, you shouldn't need to lost 
time of low level async stuff. UniServe is meant to offer a complete 
client and server API that should save you from working on low level 
stuff (unless what you're trying to do is not supported by UniServe's 
API).

Why do you need to intercept it so early?

ok, I'll do an out of uniserve test to see.

unless I do a write-io and catch the 517 error... that would be an 
ugly way to poll the system, until it stops raising an error... hehehe

now that I can see output this is what's going on... I see that on-page-start 
is called, I do " do %bin/somelib.r   do %bin/somelib2.r ..." there 
, but libs don't seem to get included

I guess you're using 0.9.19. DO has been redefined in the RSP engine 
to bind, by default, loaded code to webapp context. If you want to 
load libs that have to be visible in the global context, you have 
to use DO/GLOBAL.

Hi Doc. I am "porting" to 0.9.19 , the main thing that was causing 
causing the confusion since I didn't yet fully get it  was that "do" 
inside one of  another file that was "do-ed" didn't seem to use path 
relative to the that file but to web-app and before that wirtualroot 
property wasn't correct, I added the folder below root path.. now 
it works, and debug makes the whole output visible so I made it work 
better also.

I'm checking the code to see if there's a simple way to do that.

ok, thanks a lot ... one day soon I will buy rebol so I can do little 
hacks and "recompile" myself , so I won't need to bug you for smaller 
stuff

aha, mine is reverse, no stress testing but functionality... I made 
it for webapps but with it you could also do automated testing on 
a sample of scripts and see at any point if all the features work 
.. it is very much in devel still ... I used it for testing site-assistant 
but it's more manual at this point.. I will impove it as one of my 
clients needs it for their app. I hope it will be more edible or 
usable soon, I will show it to you then.

yes, dialect based solution would be very interesting ... I was thinking 
about dialects a little too (not concrete yet) ... currently my testing 
engine is made so that it uses a proxy and it records your what you 
do via browser and then it can repeat the same and comparte the output 
(it already figures out that it needs to set different cookie and 
some basic stuff to login for example , and I have idea to make it 
scriptable for other dynamic data but I haven't come that far yet 
) . It also doesn't do any smart comparisson of the outputs, but 
more of a report for human to view for now

so if your test will generate some relatively compatible data and 
if it would make sense to be presented like this we can do it

As a result of an RSP script I want to return a new web-page that's 
on the file-system. I do it like this:

print read %payment/index.html


So far this works. What I need to do is, to insert some dynamic content 
into the read HTML file.

I'd say your RSP script should "be" the resulting web page; that's 
the normal way to generate dynamic pages. Why do you think of them 
as separate?

thanks... wrt CRON... when you release the next version, I could 
drop that into it and send it back to you.  you don`t have to do 
everything yourself   :-D

I'd like to not do everything by myself, but it's not that easy. 
I have some deep concerns for Cheyenne core part such as speed, memory 
usage, stability and security. Cheyenne has become a *critical* part 
of our business, I have to garantee that a new version won't break 
our webapps in production, nor make them instable, insecure or noticeably 
slower. My responsibility also extends to other companies that are 
selling products or services based on Cheyenne.


I've already accepted small patches on Cheyenne core in the past, 
but it takes me a lot of time to study and test each line of code 
an rewrite them if required. If your code has only a local impact, 
I might use it, if it needs to patch a lot of parts of Cheyenne/UniServe, 
I probably won't. Anyway, you can send it to me, it's always a good 
inspiration to see how other developers solved some specific problem.

Well, maybe you can't. I haven't given any thought to what it takes. 
I was only thinking of the basics like large file transfer and proper 
working async ports and threading. some basics that a good webserver 
can do.

libevent was suggested in the past, along with links to liboop etc. 
Not sure the licence is OK. Anyway - I wonder where do we go such 
a way? I can already imagine complete mess and tens of versions of 
custom R3s, if such low level things as main event loop are open-sourced 
and replaceable.

BrianH: how do you want to bring something like Cheyenne (Uniserve) 
to R3, if such low level stuff as concurency is not designed yet? 
Wouldn't it (using tasks or not) influence its design? So do we wait 
for new R3 concurency model, or do we proceed with protocols, and 
rewrite later? (we can move to R3 chat instead)

how do I use rconsole to tell cheyenne to reload a mod that has changed 
on disk... 


or does cheyenne detect mod-file changes and reload them automatically?

doc, I have noticed a usage in your mods which you might want to 
change for speed reasons.


you use the word return a lot... and in my tests, it causes a BIG 
performance hit on function calling... I really mean noticeable when 
you do loop profiling ... a minimum of 20% slow down IIRC.

so instead of:

    phase: func [svc req conf][
        if declined? [return none]
        ...
        if let-others [return false]
        ...
        true
    ]

you really should be doing 

phase: func [svc req conf][
        if accept? req [
              ...
             true =  let-others? req
       ]
] 

just my two cents.

I rarely need to do so... I implement the loop conditions properly, 
usually.


obviously there are cases where you really can't live without out 
it... but as a general rule, I rarelly ever need break.

I know in apache "virtualhost" commnad needs to be uncommented...I 
do not see anything else in the config file that idicates vhosting..

I have no problems with subdomains, but maybe it has to do with the 
dynamic DNS

doc: might I do a RFE (request for enhancement)?


add a ./conf/  dir to cheyenne and load every file that ends with 
.cfg


this would allow us to distribute a configuration file with a module 
and provide setups per mod... its much more flexible to manage.

we could also have a setup for each vhost in our system, if that 
makes sense for the web admin.

I'm adding words which are commands within remarks' module using 
the do variant of config definition...  this allows me to grow a 
config by calling the same command multiple times.... this would 
be very unweildy to implement any other way (but not impossible)...


maybe a function-based api could allow us to "hook" into the GUI 
but its pretty hard to cover all possibilities in any case... anhow... 
back to modulating remark.

There's a builtin "process" function in config DO blocks allowing 
to process nested blocks (see mod-static/if-loaded? definition).

when the config do is performed, I noticed you do a bind on the block... 
the thing I wonder is to what it is bound... its not obvious to me

Thanks. I thought it might have something to do with RSP but I see 
it is even simpler than that...

What are the requirements to get a connection to a mysql database?

I have a %httpd.cfg as below   


--------------------------httpd.cfg --------------------------------

globals [  ...  worker-libs [  ...  %path/to/mysql-driver/mysql-protocol.r 
  ...  ]  ...  ]

my.virtual.host [   ....    databases [ db-name   mysql://root:[lpass-:-127-:-0-:-0-:-1]/table]	 
....   ]

----------------------------------------------------------------------


As far as I can see from the documentation and sample files, I should 
now be able to use SEND-SQL a alike on DB-NAME, but that gives nothing 
but script errors

	** Script Error : db-name has no value 
	** Where: rsp-script 
	** Near:  [print mold db-name  


I've already spent hours on this without getting a clue on what to 
do.

DO-SQL is higher level than SEND-SQL. You don't have to deal with 
ports using DO-SQL.

I think I was using DO-SQL with a LIT-WORD! database name and a simple 
STRING! select statement, which - hard to tell - may have had a type 
back then. Hard to tell afterwards; I'm not able to reproduce that 
particular error message now. And I've deleted the trace log once 
things started to fall into place. Putting the select statement in 
a block seemed to be what solved my problem, but I tried so many 
things that I don't recall the actual order in which I changed my 
.rsp-code.

Doc asked "Third party tools can be used to tunnel SSL, like stunnel 
or nginx. About RSP, does Cheyenne's RSP miss some features required 
by Qtask?"

Maarten might be best to answer this.


BrianH wrote ""because they use PHP I'm guessing" - the promotional 
web site uses some PHP, but the main site is all REBOL."


I want to rephrase this, to help make it clear.  Qtask is written 
100% in REBOL.  We call this the "service".  The website on the other 
hand (which has nothign to do with the service), uses PHP, becuase 
there are many tools that the Webmaster wanted to use in PHP.

Back to RSP, if you allow nested RSP and do word capturing BUT passing 
words between parten/child pages, I''d say, yes, Cheyenne's RSP is 
very good.

Word capturing => yes, all RSP running inside a webapp are captured 
in the webapp execution context, to avoid global context pollution. 
This doesn't apply to standalone RSP scripts (outside a webapp), 
but that feature could be easily added.


Page inclusion => yes, you can include RSP scripts in RSP. See http://cheyenne-server.org/docs/rsp-api.html#def-21

context injection with 

captured" words on the subpage" => I don't understand precisely what 
you describe here. In Cheyenne/RSP, subpages are captured in the 
webapp unique context, like parent pages, so there's no special treatment 
for subpages. Do you imply exporting just a selected list of words 
from the subpage script to the parent context?

Do vhosts work with stunnel ?  ie. I can redirect incomming https 
to different vhosts?

'set-tray-remote-events is called only in 'do-tray-app which is called 
when Cheyenne is running as a service to install a standalone version 
of the tray icon with menus (for remote control of the Cheyenne service).

What would cause a browser to complain about a RSP page ... asking 
what to do with it?  As long as Cheyenne is sending the correct content 
header .. there should be no issues, right?

*do means "bind to the global context", but even the wrapper DO wouldn't 
help you there. As a rule of thumb, *always* initialize your global 
variables in your RSP script (or at least put them in some local 
context). Never expect that a variable would be available in another 
RSP script unless you put it in session object.

Cheyenne is very powerful and very stable. It is also very sensible, 
so you have to take care much of what you do, I have also many instances 
serving millions hits per month, no problem at all 8)