Alex Tweedly alex at
Mon Mar 7 19:02:31 EST 2005

Richard Miller wrote:

> Looking for suggestions on how to best handle the following scenario.
> Imagine a number of computers spread out across the country (some 
> PC's, some Mac's) running a custom Rev application. On each computer, 
> the application continually (every 30-60 seconds) sends a small file 
> (just a few characters) into a central server. This file contains 
> information about the availability of the user (available now, within 
> 10 minutes, not available). Let's say there are 100 of these computers 
> and applications running at any given time, all reporting in every 30 
> seconds or so.

What's the relationship between the "user" and the computer ?

i.e. can the same user be on 2 of the machines at the same time ?
if so, what should be reported as the status for that user - the one 
that happened to give the most recent status, or the most available? or 
what ?   Does the status say "User 1 is available now on machine" ?

if not, is there already a scheme to prevent it (or simply an assumption 
that it shouldn't happen) ?
is there a finite set of users ? how big ?

or is "user" equivalent to "computer" ?

> I've also got another 100 computers (all Mac's) running a different 
> Rev application. Each of these computers needs to know the combined 
> status of the first 100 users, continually polling for this data every 
> 30 seconds. So, for example, at any given moment it knows:
> User 1 is available now
> User 2 is not available
> User 3 is not available,
> User 4 will be available in 10 minutes
> etc..
> I've got a dedicated Mac server available, on which I want to place a 
> Rev application to gather and disseminate the required information. 
> The first 100 computers will continually inform that central 
> application of their status, and the other 100 will continually ask 
> this application for the status of the first 100 users.
> Suggestions on how to do this. I've quite a number of ideas, but I'm 
> not sure of the fastest and most stable (and perhaps easiest) way. One 
> concern is with multiple users (the ones supplying data) trying to 
> check in at the same time.

Best way : (esp. if your user base might grow over time) - central app 
using a database.

But for the current problem description this is probably overkill.
Depending on your answers to the above questions, you could probably do ....

Simplest way: 
(NB Only if users are unique and not too numerous)
create a status file per user.
on the user client:   
    put myStatus into URL ("" & 

on the server:
   run a Rev script that every 10 seconds (or whatever level of currency 
is required) does the equivalent of
cd /httpdocs/statuses
cat * > ../newstatus
cd ..
mv newstatus allstatus
   (or just stick that shell script into a cron job)

on the other clients:
   put URL "" into allStatus

No programming (or almost no programming) to do, very simple, easy to 
monitor (just look at files and dates).
Interlocks are handed by the file system - the rename is an atomic 
operation, so safe (on Unix - I'm assuming OS X operates the same way) 
from read/write clashes.

Alex Tweedly

No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.6.0 - Release Date: 02/03/2005

More information about the Use-livecode mailing list