World: r3wp

Is there any way the app-init could be placed inside the httpd.cfg?

As a design principle, I don't want to have code inside the config 
file. Why would you need that?

Anyway, you could use request/config in 'on-* events if needed to 
remove static paths.

So I won;t forget about the app-init.r file :)

I'm now using Cheyenne as reverse proxy with lighttpd. Works great. 
All RSP requests are forwarded to Cheyenne.

I run several domains as virtual domains in lighttpd. And I have 
one document root for Cheyenne. The idea is to be able to add the 
same RSP page (like a shopping cart) to severl domains without having 
to duplicate the RSP code pages.

Is this possible? Does Cheyenne know anything about the domains document 
root?

My directory layout is like this:
cheyenne (containing all RSP pages)
domains
	domain1
	domain2
	domain3
	...

If a request to an RSP page via domain2 comes in, I would like to 
be able to reference directories inside the domain2 directory.

Why there is used 'launch for encaped version and 'call for the rest?

in uni-engine.r is used:
launch*: func [cmd [string!]][
	call join form to-local-file system/options/boot [" -s " cmd]
]
There must be -sq not just -s

'launch stopped working in 2.7.6 I think

You're sure? Don't remember reading that in the 2.7.6 changelog?

without the -q it's impossible to run the server as a background.

Launch is what Cheyenne needs. But it doesn't work in Core (but works 
ok in /Pro which is the minimal base for the encap versions), that's 
why I use the CALL workaround to make sure it will work on all REBOL 
flavours.

I hope that LAUNCH would be fully enabled in REBOL v2.7.7, I don't 
see the point in keeping such limitations.

Yes, I reporteed issues with 'launch.   Gabriele said to use 'call 
instead.

I see I reported other issues with launch

http://www.rebol.net/cgi-bin/rambo.r?id=4205&
That one is makred TBD

Just testing with 2.7.6, looks like LAUNCH is only working with Encap. 
"Feature not available..." for all reb* binaries.

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

Is launch/quit working at all??  It wasn't working for 2.7.5

Maybe it was for 2.7.5 and it got fixed for 2.7.6.  I know at one 
stage I had to replace all instances of launch in my encapped code, 
and use 'call instead.

Doing a search .. looks like I was having that conversation with 
Gabriele about the linux SdK and launch in 2006.

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.

I have one page of my hylafax application that calls imagemagick 
to convert a tiff to png so it can be viewed in the browser ...

Ok.. then we should write a wraper for imagick, because that's what 
I want to use as well.

Thinking about web-app appliances. Not sure if this idea alreaday 
exists but IMO a good thing to think about.


If I have a RSP based web-app (for example my super-cool-all-you-need-shooping-cart 
system) that I would like to sell it would be nice to bundle cheyenne 
and all the RSP stuff into one package. The user just installs it, 
sets up a simple reverse-proxy and has everything up & running.

IMO this would be a killer feature for Cheyenne.

We can't expect people to change their existing web-server. We can't 
expect them to install Rebol interpreter, create new CGI setup etc.


But we can expect people to install something on their system, add 
a little config stuff to the existing setup and have a cool web-app 
up& running.

Most web-apps or modules are just to all-or-nothing. I just want 
a simple thing but get a bunch of stuff I don't want to use but I'm 
forced to.

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

If Cheyenne as a whole could work this way, I might consider using 
it. Other than that, I can't easily replace Apache at hosting location 
....

Deploying the RSP stuff in an "encapped" way would be nice too. So 
just one file including cheyenne and all RSP stuff.

The main problem I have with a lot of the available tools is, that 
integrating several of them into one solution is far from easy. There 
is no loose coupling possible.


You need PHP version XYZ with module ABC and libc version IJK etc. 
getting all this to work togehter is horrible. It's fragile and hence 
a nightmare to scale or operate.

Being able to install web-appliances with a smart and simple integration-interface 
would be very cool.


I'm going to try this with the shopping cart stuff. We will see how 
it will work. Adding a simple deploying mechanism shouldn't be that 
hard than.

Robert, what your explaining is one of the main goal of Cheyenne. 
:-) Simple, lightweight, all-in-one file web applications deployement. 
Still some work to be able to achieve that, the main missing feature 
is a good and lightweight virtual file system for RSP scripts (so 
you can run them in source form or encapped with Cheyenne without 
changing anything).

Pekr: nowadays, you can have your own private server for less than 
10€/month...

well if you don't have reason to hide the sources one exe + one folder 
for rsp/html/image files (so user can also tweak them) doesn't seem 
any worse and already works

yes, vps-s are very accesible now

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.

Tweaking: I'm all for it but via a simple dialect driven way. Keep 
it simple. I don't want to hack several CSS, HTML, pre- post-processor 
files etc.

I am not shooting down your idea.. I am just trying to say that cheyenne 
with just simgle -- exe + folder + config file -- already provides 
very deployable webapp solution, compared to for example installling 
apache + php + apache + pear.. and django / ruby (with just development 
server) also wasn't anywhere near as simple to install last time 
I tried

Janko, I agree. It's, let's say, already 80%. I just want to push 
for the 100% :-)

and I can also think of situations where prepackaged app in a single 
exe would be preferred, so I agree back :)

Dockimbel - I can have my private hosting for something like 10€/month, 
but surely not server. At least not here. And - it is not proper 
answer - sometimes you just want to deploy, not enter into new agreement 
with new server hosting house. That is upon client, not mine decision, 
etc.

Pekr: I made a deal to get a smaller VPS in slovenia for my local 
projects. I pay 12EUR and I am currently running one cheyenne webapp, 
2 apache solr engines with multiple 1000 records (search engine / 
indexer),  and a multitude of bots for search engine.. without any 
problems . All VPS-s in slovenia start at 36EUR and are bigger (more 
HD more RAM) , but I started asking various providers if they can 
get me smaller package for smaller fee and I got one :) . If you 
are looking international you have good and cheap VPS-s at Linode 
, I also used miniVDS which is only 5EUR I think (and intend to again 
in future)

I have one question... after working in various other languages + 
mysql/sqlite I am using normal files with rebol structures and LOAD 
for my first projects here. Now I have a little more serrious project 
up so I started thinking if by using just files I can corrupt data 
somehow. I am not that good on low level details, but I imagine that 
I don't have to worry too much. Because cheyenne is single process 
I imagine only single write to file can happen to some file at any 
given time. Am I correct or wrong?

Imo you are wrong.

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

If Cheyenne would be able to share handlers between apps, you could 
write small queue handler for db request and use small sqlite DB.