World: r3wp

and mercury is not poisonous to my system

no security issues I hope

not that i know of, it's the usual if you keep it running, but you 
don't need to have the server running at all to use it.

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

ie. just use email

pdf downloaded ... bed time reading it is then.

My users are even less technical than I am ... need something really 
easy :)

I should try and find my old replication script I wrote for uniserve

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

Kaj, looks interesting. Thanks. I'll check it out.

well, for your users i'd let the app itself download the updates 
and so on.

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.

Robert, Paul Graham is an investor in Disqus

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)

Did anyone try using sqlite.r from Dobeash in free rebol code 2.7.6 
on linux. (debian). I get "feature not available in this REBOL" but 
it works on windows.

uh.. I wanted to write the last in the sqlite group

( just for reference , as Doc figured out and can be seen in SQLite 
group I was having problems because I was using too old version of 
libsqlite3.so)

Can the compression of RSP output be disable in the new cheyenne?

I was looking at settings and didn't see anything like that but I 
saw no-compress in new RSP docs

so I guess I could put that in on-page-start if I would want to disable 
it for the whole app..

Untested, but that should work.

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

Unless your server CPU is heavily loaded or you're serving only very 
small files, having compression on usually improves performances. 
You should benchmark it first before turning it off.


Btw, currently, compression in Cheyenne only applies to RSP scripts 
output, it's not yet available for static files.

is there an existing mechanism for basic authentication?

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.

ok

Why do you need BA in this case instead of usual login form?

Just curious.

PDF has an image field

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

so I need to authenticate inside the url

I can't place the signature image in public

same for accessing fax services

need to authenticate in the same url that sending the fax

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

Is that an adequate reason ? :)

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

Graham, I think using the image link rather than embedding the image 
does not really protect the image, and requiring an extra web access 
to get the signature image is more prone to failure,

as well as being an alternative way of picking up the image (intercepting 
the web traffic is easy).

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

(What needs to be accessed by Acrobat?) Sorry, I'm not quite clear 
what the scenario is.

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.

Oh, I think I understand:

Before:
	Acrobat opens xfdf -> pdf -> image
Now:
	Acrobat opens xfdf -> pdf [image]


So before, the client Acrobat opens the xfdf file, which links to 
the pdf on your website, which links to the signature image on your 
website.

Because of the signature image, authentication is required when linking 
to the image, and Acroforms used in the PDF limits this to Basic 
Authentication.


Now that you've figured out how to embed the image in the pdf, the 
client Acrobat opens the xfdf file, which links to the pdf on your 
website, which has the signature image embedded already. Because 
of the signature image, authentication is required, but because the 
image is embedded in the pdf container, authentication is required 
when linking to pdf. (And I presume still limited to BA?)

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?

Both are very good, but Cheyenne may be much easier for you.

Anton, yes :)