run Rev app on two networked computers?

[Andre Garzia]

On Jul 6, 2004, at 11:50 PM, Chipp Walters wrote:

> Kurt,
>
> It helps if you can better understand how RunRev manages memory. In 
> fact, each computer would open up the copy of the stack and load it 
> completely in memory. At this point, cards can be added, fields filled 
> out, etc,-- but this only happens in memory....not the stack. Once a 
> 'save stack xyz' is issued, then the disk file for the stack is 
> replaced with the current contents in memory. So, unless you have a 
> way to 'check in/out stacks' it's difficult to 'share' a stack, as it 
> is being completely overwritten each time a different 'user' saves it.
>
> I believe Andre is probably going to talk about using a stack CGI as 
> webserver, which would obviate this problem by only loading a stack 
> when changes are made, then saving it. By locking the stack and not 
> allowing another access to it while it's being modified, a 'shared 
> stack' concept can be created-- though IMO, it's probably simpler to 
> do this in MySQL or other multi-user database which already has record 
> locking tools in place.
>
> I hope this helps.
>

Chipp and Kurt,

auhhuahua I am getting predictable! I am just a big fan of multi-tier 
approach, and I think that if I could stuff a HTTP server in my bicicle 
odometer, I would. Let's try a solution without a webserver...

he can load the stack with no problem in both scenario, the problem is 
the saving part. I think he can use a file as a semaphore to check 
in/out. Before any save stack procedure, the stack would look for a 
file, maybe called "stack.locked" if this is present, don't save and 
wait, till this disapear. When saving a stack, before saving it, he 
must check if the current copy of the stack available on the filesystem 
is equal the one he has in memory (the other instance might have added 
something), if it is not, he should reload the stack and apply his 
changes on the current copy. I think this would work... (did I miss 
something?)

If you opt to the webserver approach, then it's easy, you can implement 
a little server, and a client that call the server functions... that's 
easy and work on both the local instances and across networks, but 
that's the approach I like, there are many others. Using MySQL or some 
other multi-user rdbms is pretty easy too, and also work across 
networks

let's summarize:

Solution #1) use files as semaphore to tag the locked status of the 
stack, keep sure that stack in memory equals stack in the filesys. 
PROS: your app is self contained. CONS: don't know, didn't think of 
any...

Solution #2) use a webserver stack to store your data, client use data 
from server which is always right. PROS: you can make a general stack 
storage and reuse this webserver app for many projects, and also, this 
approach is nice and works. CONS: you must to build two stacks, a 
client and a server. The server must be running and accessible.

Solution #3) use a RDBMS as storage, client loads and write data to the 
database. PROS: You build only one stack and this approach also works. 
CONS: you must be able to install and mantain a MySQL system (or 
something like it)

Now, you choose! :D

> -Chipp
-- 
Andre Alves Garzia ð 2004
Soap Dog Studios - BRAZIL
http://studio.soapdog.org