AltME groups: search

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.

I can implement a clean-up routine for RSP variables declared in 
a webapp context, but this would be a partial solution (won't clean 
up global space), and in all cases, you *should* initialized all 
variables before using them either by declaring them in a function! 
as local words or by explicitely setting them to a default value. 
Such clean-up routine could be usefull to enhance security by avoiding 
to reveal other user data in case of a RSP script programming error.


Btw, you can already detect uninitialized variables in your RSP code 
by running Cheyenne with the -w 0 command line option. This would 
tell Cheyenne to use a single RSP worker process that will be restarted 
after each request (CGI like beahaviour). An uninitialized variable 
will likely error out in that case.

Having a Cheyenne running locally using a browser window to display 
VID dialect looks like very doable. I think that even 'move events 
would work fast enough. That would solve a lot of current View/VID 
issues while providing a cross-platform GUI. Add a proxy service 
to Cheyenne, and you got a nice RIA platform with online/offline 
working capabilities.  Anyone rich enough here to sponsor such project? 
:-)

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.

This is a video of my RSP pages showing binary at the top of the 
page.  http://screencast.com/t/WD2j8PJtse

The binary appears on a new RSP session

- The garbage binary data looks like compressed data. 

- "more binary appears..." => issue with a string! or binary! buffer 
not cleared or initialized as literal value instead of using MAKE.

- "...above my html" => check your 'on-page-start event handler in 
%app.init.r

This has happened a few times now .. I mentioned it before.  And 
usually only when I am rewriting RSP code.

You can restart it, I've a copy of the output.

You should carefully examine each use of response/buffer in your 
RSP code. See if you're not inserting in response/buffer a growing 
 series?

Need to go now, will give it a look tonight.

A suspect :)

I think that I should add a "RSP best practice" or "RSP warnings" 
section to Cheyenne's wiki.

Robert, xfdf is a deprecated format once used by Adobe to specify 
the contents of fields in a PDF.  So, the above xfdf file will populate 
the fields TextField1, TextField2, syupdfid with $fname, $surname, 
and $syupdfid ... ( well,  I will replace those before I send the 
pdf. )

I have a submit button on the pdf which then sends the data back 
to me.

Maybe someone here using one of these 64bits OS would be kind enough 
to run a few tests for you?

well, as a temporary measure, if my application can't connect-to 
Cheyenne, it will drop back to the REBOL micro web server which does 
work.  Maybe the user has changed the default port, or has a firewall 
blocking it ... will have to find out.

Everybody expects from a web server to run by default on port 80, 
that's the specification. From RFC2616 : "HTTP communication usually 
takes place over TCP/IP connections. The default port is TCP 80 but 
other ports can be used.".

Regarding httpd.cfg file, I'll look on how to avoid writing it down 
on disk when running from a custom encapped binary.

An improvement for Cheyenne on Vista could be to display a standard 
OS security requester asking for admin pass when Cheyenne  needs 
to run on port < 1024.

Not sure that's the right place. It's supposed to be a static information 
from the user POV, so the documentation might be a better place.


Btw, after reading again your posts above about that issue, you should 
have provided an encapped Cheyenne with your own httpd.cfg config 
file built-in (instead of using the default one). Moving the binary 
aournd wouldn't been an issue then.

The yellow tooltip message when mouse is over the systray icon could 
be a good place. Instead of "Cheyenne is running" could be "Cheyenne 
is listening on port(s) ...". I'll think about it.

I think "cheyenne is listening on port " would be good because I 
run a number of cheyenne instances launched by different apps, so 
I can't tell which one is which unless I see the port information.

Reproduced it on a different pc.

Multiple running instances :


1 ) Cheyenne uses a port translation method for task-master to avoid 
clashing between Cheyenne's instances. This translation is currently 
triggered by the -p command line option specifying on which port(s) 
Cheyenne should listen. So the 'listen keyword in config file doesn't 
trigger the translation. After a quick look, it should be fixable.


2) Logger and RConsole services ports are not translated. This should 
be fixed too.


3) As a consequence of 1) & 2), Cheyenne can't currently run multiple 
instances on the same machine.


I am running two instances because the web app uses the same database 
name
 :


4) I very well aware of this issue and I intend to find a solution 
asap.

OpenSCManager failed : Access is denied
 :


5) I should load that routine! only if trying to run as a Windows 
Service without having admin rights.

for one user emr points to one database, but for another user it 
points to a different database

So, to use a single instance of cheyenne, I have to go thru all my 
source and change the database name so that it's different each time 
I want to run more than one instance of this web app

I'm working on the support of per webapp databases definition instead 
of being global. So you could have a 'emr database definition different 
for each webapp (while keeping the same name in sources).

I have a demo database that contains dummy data ... anyone can access 
it.

I have a real database which I don't let anyone except myself access 
:)

Graham, I have a working patch that supports setting same DB virtual 
name to different connections URL per webapps. Here's an example 
definition of 2 webapps using this new feature :

	webapp [
		virtual-root "/curecode1/"
		root-dir %//dev/curecode/
		locales-dir %private/locales/
		
		databases [
			bugs	mysql://[root-:-localhost]/bugs1
		]
	]
	webapp [
		virtual-root "/curecode2/"
		root-dir %//dev/curecode/
		locales-dir %private/locales/

		databases [
			bugs	mysql://[root-:-localhost]/bugs2
		]
	]

what's the process of acccessing a rsp page ?

An RSP page can be accessed standalone without a webapp. The webapp 
gives  you some additional features like automatic session starting, 
optional authentification protection, private folders, app-init events, 
etc...

Isn't the above the correct way to add a browser to the webapp?

I don't understand why you need this code if you're in a webapp context.

If I want to login in users from a particular ip address to the webapp?

The login? session special value is used only to control access when 
authentication protection is set using the AUTH keyword in config 
file. You need to set it only when you consider that the user has 
provided enough credentials to let him in (for example once he has 
filled a login form with correct ID / pass values).

Session/start has only been provided to manually start a session 
for RSP scripts that are not inside a webapp.

Just a little observation .... you have this timing script at the 
bottom of the page ( in app-init.r )

the xml i was emitting also had a </body> in it ...

All this to avoid a blank Acrobat page appearing.  if you call an 
*.xfdf file, acrobat opens up, and then the browser plugin starts 
up to load the remote PDF.  so, you have this blank PDF on screen 
as well. But if I use localhost to create a web page that emits the 
xfdf, then I only get one browser window with the pdf and no more 
blank Acrobat instance.

Has anyone tried to use things like Google API etc. from inside a 
RSP page?

I'm thinking about using the js-kit.com commenting service. But I 
would "hide" it via a RSP page to have more control how to integrate 
it.

I've been writing a web app which I have been distributing as a zip 
archive.  People just unzip the latest over their copy, and I ask 
them to write protect their own changes.

Perhaps a Cheyenne rsp script that downloads a catalog, and then 
downloads any changes to the local site?

none of them needs a server

no, you can start a server to let other people access *your* repository

mercurial in particular works fine as a simple CGI if you want to 
give read access to the repository

needs a web server?

you can still just send any changes from a given revision forward 
as a single file (bundle)

If anyone has the stamina, I did a few videos linked to here http://synapsedirect.com/forums/permalink/7870/7869/ShowThread.aspx#7869

1. Shows the creation of an interactive PDF using Acrobat Pro 9
2. How to register the PDF on my Cheyenne web site

3. How the new registered PDF can be prefilled on download, completed, 
submitted and retrieved

even if you don't collaborate with anyone, it's still very useful 
to have the code in a VCS, and a DVCS allows you doing so without 
needing to set up a server.

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

No builtin support for basic auth. You need to provide your own code. 
'on-page-start would be a good place to put that kind of filter.

it can grab the image from a url

I want to use an image for a signature

so I need to get it from a password protected part of the website

I see. So basically, you just have to check for the correct credentials 
in HTTP headers, else you just need to send back a 401 status code 
+ auth header IIRC.

Yes, Acrobat has no way of authenticating against a web server :)

I was thinking about a PDF-related restriction, just wanted to be 
sure. :-)

I've found a way to merge the signature image with the pdf on the 
server ... but the pdf still needs to be accessed by acrobat

there is a thing called an xfdf file ... when acrobat reads such 
a file, it goes to fetch the pdf in the href spec in that xfdf file.

Hello everybody!

I''m new with Rebol, I hav a small server (VIA M-EPIA) and 512Mb 
of RAM and linux;
Is better Apache or Cheyen? 

I need only PHP, MySQL and linux script (image magick and ffmpeg), 
what are your opinions?

I noticed that www.cheyenne.com goes to CA's website.  This looks 
like a marketing stradegy but does that mean the same Cheyenne as 
Doc's awesome product here?

Thanks for the link Paul, I'll check that site next time I need a 
name! :-)

Re MaxV: If you plan to use *only* PHP and MySQL, I think that Apache 
is a more logical choice. Cheyenne is built mainly for web application 
programming in REBOL. Support for PHP is here only to avoid installing 
another web server if you already use Cheyenne (for REBOL apps).

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.

Two ways.  If it is small enough, it is saved in the session, otherwise 
it is saved to a temp file which is accessed by the session variable.

so if request/posted is binary, then it's what was posted, but if 
it's a string, it points to a temporary file.

The uploaded file is written on disk if it's size exceed 100'000 
bytes. You can change this default threshold value by using the 'post-mem-limit 
 keyword in virtual host configuration options (in %httpd.cfg).


Cheyenne can handle file uploads up to 2GB size with no noticeable 
impact on memory usage.


The temporary file is stored in an %incoming/ folder at Cheyenne's 
root. The file is deleted once the response is sent to the client, 
so in order to keep it, you have to rename it or copy it elsewhere.


You can use the %show.rsp sample script as target of a POST action 
to test it.

If you want to access a web app from Rebol

page: open login-url ; a rsp session is sent to you
page/locals/headers/set-cookie contains the cookie

page: read/custom login-url compose/deep [ POST (auth) [ cookie: 
(cookie)]] ; where auth is your authentication string eg. "login=user&pass=mypassword"
you are now authenticated
and if you now what to access a page in the web app

page: read/custom web-app-url compose/deep [ GET "" [ cookie: (cookie)]]


where you need to use my modified http protocol that allows you to 
send cookies with read/custom

I'm on a time limit for now so I'll increase the post mem limit by 
10x, but I need to get this fixed eventually so I'll track the error 
down.

It works fine. I only use IE for testing and Qtask - everything else 
I use Chrome. I know how to make a Windows machine stable :)

I'm posting a 150k file.

It took a while - might it be a timeout?

I've tried a .r, .csv, .exe, .zip. The only thing that affects things 
is whether the file size is larger than the post-mem-limit.

did you try a rebol client?

This was after restarting Cheyenne after a crash. I gotta review 
the source some time :(

Back to the old expect-arg issue after the reboot. Upping the post-mem-limit 
to way beyond the expected size of the posted files solved the issue, 
for now. This is not going to be a high-volume site, so that's no 
problem.

is there anyone using cheyenne as a service on win xp home edition?

is there anyone using cheyenne as a service on win xp home edition?

I have a Cheyenne (enpro version) session running for a few months 
now on a Windows XP Pro.

well, I tried several times to run as a service on my xp home, it 
failed everytime

but today after when I send this message it works as a service. stand-alone 
mode was always worked well.

Did you changed anything related to user rights? Maybe logged as 
Admin user now? Installing a service requires admin privileges.

and if you put a plugin to your www folder

is there a workaround? without removing .r extension from cheyenne's 
config file?

DEBUG: I'm I right that the newest version doesn't send a Rebol error 
to the client anymore? How can I re-enable this "feature" for non-web-app 
pages?

Web-Apps Login: Is the login page always presented as first page 
if a user isn't yet logged in and tried to access an other page directly?

Web-Apps Login: Is basic authentication supported? I have a situation 
where form-and-cookie authentication is awkward.

DEBUG: you're right. You can re-enable that by adding a DEBUG keyword 
in httpd.cfg in domain or webapp config block..

DEBUG: Can I enable it via a RSP API call or a flag for just a specific 
RSP file?

DELETE: not out of the box. If you want to add support for new HTTP 
methods, you need to build a custom module for Cheyenne that would 
take precedence over mod-static/method-support handler. If you need 
it as RSP level only, you can just edit that handler and add whatever 
method you need. I may add a config option to be able to extend allowed 
methods in a cleaner way.

I went with a web app for the database connection management and 
authentication, but now I find out I need to support stateless clients. 
So, no persistent cookies. Help?

18th March "No builtin support for basic auth. You need to provide 
your own code. 'on-page-start would be a good place to put that kind 
of filter."

Darn. I'll figure it out tomorrow then. Any problems with creating 
a throw-away session every five minutes?

Brian: It shouldn't be a problem. Sessions block is hashed, so session 
access time is constant and the only impact is on memory usage.

Graham: I suspected a hidden message ;-).

ummm.... see the magnifying glass top right?  It's called a search 
tool :)