21602MR@MSU.BITNET (Mark Rosenberg) (08/09/90)
I am working on a management system for a research project in Teacher Education at Michigan State and would like to create this system in Hypercard running on an appletalk server over an appletalk network. The biggest problem I'm facing is multi-userNESS.... I don't need complete multi-userness, that is to say I only need multi-userness at the typing userlevel. If there is someone out there who has developed astrategy or set of xcmds/xfcns to deal with this our project woudl be able to contract with you as a technical consultant to implement the system. For more information please email or phone Mark Rosenberg <21602MR@MSU.BITNET> MATH Project, Teacher Education Michigan State University (517) 353-0628 or 347-4108
lowersbp@ingr.com (Ben P Lowers) (08/13/90)
In article <53221602MR@MSU>, 21602MR@MSU.BITNET (Mark Rosenberg) writes: > I am working on a management system for a research project in Teacher Edu. > at Michigan State and would like to create this system in Hypercard running on > an appletalk server over an appletalk network. The biggest problem I'm facing > is multi-userNESS.... I don't need complete multi-userness, that is to say I > only need multi-userness at the typing userlevel. > > If there is someone out there who has developed astrategy or set of xcmds > to deal with this our project woudl be able to contract with you as a > consultant to implement the system. For more information please email or phone > > Mark Rosenberg <21602MR@MSU.BITNET> > MATH Project, Teacher Education > Michigan State University > (517) 353-0628 or 347-4108 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. Do you get the idea? Get back with me for follow-up info... -- Ben Lowers lowersbp@ingr.com or ..!uunet!ingr!lowersbp
bc@Apple.COM (bill coderre) (08/15/90)
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