another multi-user "solution"?

[MisterX]

Hi guys,

here's what I can share about "multi"-user solutions... Sorry for the
complexity but it should cover a maximum of cases and situations in a simple
way...

I work in a multi-user - multi-server - multi-domain - multi-network
evironment, an enterprise.

The multi-domain part is a Moft Active Directory where user's are delimited
by their security credentials which can be cascaded down to the "field"
level in some applications... 

It's a different IDE level but someone at microsoft managed to script it and
it's amazing the layering, the guis, the drivers, the whole bit top to
bottom is finally consistent (if not a bit over-complex)... There's
clustering, dfs, and scripting at dos, vbs, wsh, odbc, asp, etc levels... A
small enterprise... You can use python, runrev, perl, anything you want to
manage it... 

How do we transmit data?

We got mainframes, unix, nts by the hundreds and maybe one or 2 macs. Dozens
of mac fans that dont relenquish their desktop origins and have "desktops"
instead of thin clients have their cool desktops... 

Files: 
unix to NT: use ftp or samba (EMC does...) 
Mainframe to NT: use ftp
NT to outworld over secured IP: use ftp...

Outlook: send an email from your shared drive
Lotus Notes: send via a shared drive without notes

Share a file format:
Unix to NT: text, html, xml
NT to Unix: text, html, xml

business: sql+ I wont say but it's big and fast... sql - too many front ends
to mention except for java... as usual

But in the end one thing prevails... xml... sql and text files... 

im sure some of you might remember record or file-locking in some programs
(Filemaker for example)... the cool thing is that if anyone can read text
files, it's best if a central process updates them. The reader reads and
closes the file, goodbie... Can be in-effective in long file treatments but
that's up to the app to eat what it can digest efficiently.

So the next step in this is for the client to write... 

The solution is quite simple. We can't write and hope others to read the
file simultaneously. More than one file update may happen too... But more
than one simultaneous ecord change is unlikely. The changes are also usually
a small percentage. So instead of updating the whole file we can queue up
small changes to update the "main file". 

Your server application updates the main file as it validates and processes
queued changes... One or many at a time... Depending on the work load...

Hope what i explained is not too obscure...

It's quite simple though... Processes to update with time or sererity
priority can also be adapted. Security should be a definite concern in these
applications from the beginning. 

cheers
Xavier
http://monsieurx.com - TAOO, try HyperRAD style...


> -----Original Message-----
> From: use-revolution-bounces at lists.runrev.com 
> [mailto:use-revolution-bounces at lists.runrev.com] On Behalf Of 
> Dan Shafer
> Sent: Monday, April 25, 2005 20:24
> To: jacque at hyperactivesw.com; How to use Revolution
> Subject: Re: another multi-user "solution"?
> 
> Two comments.
> 
> First, check the total number of "records" you need. I think 
> that there are (at least used to be) upper limits on the 
> total number of files in a directory in some OSes. (That may 
> have only applied to Mac Classic, but it's worth being sure 
> about up front.)
> 
> Second, using the semaphore file approach that Jacque 
> suggested is eminently doable and quite simple to implement. 
> It would be pretty easy, e.g., to have a single file that 
> just contained a list of all the card numbers currently open 
> for editing and checking it before allowing a user to edit a 
> card's contents. Equally easy and perhaps a little better 
> from a robustness perspective would be to create a text file 
> called, e.g., card.lok, where card is the name or ID of the 
> card, for a card when it's opened for editing and then 
> deleting that file when the user's done. In either case, a 
> pretty simple command could check to ensure the card the user 
> asks to edit isn't already being edited and take some 
> appropriate action.
> 
> 
> On Apr 24, 2005, at 12:56 PM, J. Landman Gay wrote:
> 
> > On 4/24/05 10:39 AM, Rob Cozens wrote:
> >
> >> I concluded that, since Transcript reserves write 
> capability for the 
> >> first person to open a stack until she closes it, any scheme that 
> >> requires concurrent update by more than one user meant opening and 
> >> closing the data stack with each read or write--which I considered 
> >> unacceptable overhead.  But note that all read-only stacks can be 
> >> shared by multiple users now.
> >
> > Actually, while HyperCard works that way, Revolution lets multiple 
> > users open a stack and write to it. If two people have the 
> stack open 
> > at the same time, either one can overwrite the other's 
> changes. Record 
> > locking has to be scripted; often accomplished by writing a 
> small text 
> > file to disk that tracks usage.
> >
> >
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Dan Shafer, Co-Chair
> RevConWest '05
> June 17-18, 2005, Monterey, California
> http://www.altuit.com/webs/altuit/RevConWest
> 
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> http://lists.runrev.com/mailman/listinfo/use-revolution
>