Xref: utzoo comp.sys.mac.hypercard:4180 comp.sys.mac.programmer:16729
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!snorkelwacker!apple!bc
From: bc@Apple.COM (bill coderre)
Newsgroups: comp.sys.mac.hypercard,comp.sys.mac.programmer
Subject: Re: Multi-User HC Programmer Wanted
Message-ID: <43950@apple.Apple.COM>
Date: 14 Aug 90 17:59:57 GMT
References: <53221602MR@MSU> <11743@ingr.com>
Organization: Consultant at Apple
Lines: 40

In article <11743@ingr.com> lowersbp@ingr.com (Ben P Lowers) writes:
|The best way that I've found "quasi-multiuserNESS" to work is by creating an
|"empty" (void of dynamic data) front-end-type stack and putting it on each 
|node on the net, and by putting TEXT files containing the pertinent dynamic
|data and putting THEM on the fileserver.  Everybody's stack reads and writes
|to/from THOSE TEXT files instead of a HyperCard stack.  Problems come up
|with collisions and daty staleness, but that's a big philosophical discussion.

You may wish, if your data is anything but the simplest, to use some
form of database system. They specifically deal with collisions and
access issues, but do add expense and complexity.

Or, you might write your own half-a-database code to handle the issues
you need (semaphores and version counts, for one approach) and put
that in each local front end. 

This approach, in general, is good for applications like, well,
databases, where 500 ticket agents are selling plane flight
reservations, etc. Big common data pool, not much communication
between agents.

Another radically different approach is to use HyperAppleTalk or
HyperTCP to send your own custom messages back and forth across the
wire. It's actually much simpler than one might think, since the
packages are quite easy-to-use. (I have done "instant" consulting jobs
using the technology, and even I was surprised just how quick it was
to get connected.) This may not handle all the eventualities, but
would be ideal for a collaborative application, something like
"MultiMacDraw" or "NetNetHack" where people are communicating small
messages often.

Or you could just do both. There are currently enough canned
connectivity add-ins for Mac applications (database servers for both
local and remote db's, custom messaging packages) that it wouldn't be
very tough.

just my nickel's worth of free advice

bill coderre
consultant and fine cook