World: r3wp

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.

hi Pekr.. no I am not using sqlite .. I am using normal files with 
rebol blocks via LOAD

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

Server rental is OT.

I was just trying to say, that even with SQLite (which solves some 
file access sharing problems), you are accessing one file from multiple 
processes.

Is Cheyenne REST ready?

I am not sure if cheyenne starts new process for each request , I 
suspect it uses async sockets and serves request at a time

ok, that is true .. if some company has a website and wants some 
additional app there it's not good option to say relocate it all 
to vps..

Janko - Cheyenne uses Uniserve multiplexing server IIRC. And AFAIK, 
Uniserve uses two aproaches - if the request can be served quickly, 
you can use one process, but if your request could last longer, you 
define handler or something like that, which spawns new process ...

Janko, if you can ensure that only one request accesses one file 
than you are safe. If not, the last writer will win. But no data-corruption 
will happen.

yes, that is another problem and I am aware of it (basically that 
is not a problem here).. the last writer wins... I am just worried 
if any data corruption can somehow happen

I think that Robert is very brave with his statement :-) I would 
not bet if data can or can't be opened. If file is not locked, and 
you use write on it, and another process too, you can corrupt data, 
no?

that is the same if you have a simpler mysql based webapp.. one person 
starts editing text, another person starts editing , first saves, 
second saves.. first person looses the changes.. that is basically 
problem on application level and is the same here as if using RDBMS

I suspect on the system level at the time one write is in action 
file is locked for all other writes

and if server is uniprocess that can't happen anyway

(if - I am not sure I know exactly how cheyenne works)

Petr, the filesystem will ensure that this won't happen. The thing 
is, that for the time you write to the file, you get a file-lock. 
But this is immediatly released after you finished. So, if you try 
to write to a file with a lock, you get an error.

A DB handles this by having one file lock for the database file all 
the time, taking several request at the same time and doinga  DB 
locking scheme on-top of the filesystem locking.

Robert - I can understand, but you access one DB file from separate 
processes, hence separate DB engines.

Is here any DB related group?

DB Chat?

Robert - thanks for explanation.. I should of known these things 
but I have been in mysql world too long :)

Pekr a little help for the problem when a existing apache/lamp website 
needs additonal web-app that you would want to write using cheyene 
would be to use Apache's mod_proxy to map just some path to cheyenne 
 > ProxyPass > ProxyPassReverse  -- http://httpd.apache.org/docs/2.0/mod/mod_proxy.html

Cheyenne serves static resources from the main process (UniServe 
process), but CGI and RSP are executed by pre-forked worker processes. 
So yes, writing to the same file from RSP script can be an issue 
if you don't have a mean to ensure that write accesses are serialized. 
I had that issue recently for RSP log/debug file, I had to build 
a small logger service in the main process to be able to serialize 
 write access (after stress testing different file locking solutions 
from REBOL, no one seemed reliable enough to me). 


I thought about adding a synchronization service in Cheyenne that 
could be used to (but not only) address the write file sync issue. 
That could work for low sync needs (like writing to a file once every 
few seconds), but for massive sync needs (dozens or hundreds of sync 
req/s), I'm afraid that the TCP port overhead would be too costly...(maybe 
a separate sync server process with persistent TCP connections could 
be good enough even for heavy uses?)

aha, so rsps work on multiple worker processes, interesting.. well 
I think to me it's not a problem as each user has it's own data files 
so it's hard to imagine multiple writes could happen at the same 
time for the same file. And if I would need something reall y heavy 
duty I would make a server serving files and caching them in ram 
for speed etc, which would also take care for sync. or something 
off the shelf

If you have a page with 2 (or more) frames, each pointing to RSP 
scripts that may all write to user's data file...that could be a 
problem. Same issue if your user opens 2 browser windows, or several 
users using the same account...the risks are not very high, but such 
cases can happen.

since processing of requwest seems to take just 1ms I think chances 
per user are slim. What would happen in it collides? would one of 
processes "get file access error" or something worse can happen by 
your exp? (I was asking about the fear of file getting corrup / half 
written before)

uh I a sleppy already it seems "happen in it collides" = "happen 
if it collides"

Hard to say, but I guess that the second.

There are some wrappers for imagemagick on windows ... but I'm not 
aware of anyone having done that in Linux.  Maybe the qtask guys 
have done that as they use imagemagick ...

It should work with .so as well... I can check it when I will be 
under linux. If you need just the conversion, it's easy.

Let me know how it works :)

You can get file access errors and corrupted data in file (last write 
wins probably). A simple RSP page may be rendered very fast, but 
there's situations where it can take much more time. Imagine a complex 
query on database or using CALL to a third-party command-line tool.


With RSP pages rendering in a few ms, the risk for collision is very 
low, but it's not zero.

but in this case will be cheyenne slow or the database itself ?

There are two things to distinguish:

1. You need a locking strategy on OS/Filesystem level. On Windows 
take a look at the LockFileEx for example, to see how it is handled.

2. Depending on your app, you get/have an application specific locking 
concept. That's what SQLite for example does. This concept than is 
implemented using the different OS calls.

Because different OS use/support different functions, it's a platform 
specific implementation. Smartphone for example most likely don't 
have any locking support at all. So, the app has to fake it completely.

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

Oh, and if you really think that's it about it. Wait: If your files 
is on a Samba network share you have to deal with the Samba way of 
locking, not the OS where the file is stored on. And Samba locking 
can be problematic as well.