World: r3wp

you can still just publish zip files, or patches, or work with other 
in many different ways. or, you simply do not work with others. ;)

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

and with some configuration for the auth part, you can also use the 
CGI for write access.

needs a web server?

or is that embedded inside Hg?

both are supported.

you can use the embedded web server, or use the CGI with an existing 
web server

http://hgbook.red-bean.com/

(i really suggest reading that)

git is faster and has more features (hg has been closing the gap 
on the features but not the speed), but windows people tend to hate 
it.

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