gjb@cs.brown.edu (Greg Brail) (01/12/90)
One of the things Sun's NFS distributed file serving protocol has going for it is "hard mounting." This means that if a UNIX process is talking to a file server and it loses the connection to that server, the process will wait forever (i.e. until the file server connection is restored or the machine rebooted) before it tries to do anything else. Although this can be a pain when debugging flaky networks, it saves lots of data on networks that work properly. Why can't AppleShare have something like this? Currently, if the AppleShare connection is lost because the network is unplugged or the server crashes, a dialog box appears saying you lost the connection to the server, the server is disconnected and your program crashes. If AppleShare instead put up a dialog box saying "The server has been disconnected" and then waited until it could reconnect, no one would lose their work. The client software could even ask the user to type their password again to ensure security when the server comes back. I have seen countless people lose work because the network was accidentally unplugged (I know--I should use PhoneNet). If AppleShare had a protocol similar to the NFS protocol, this could all be avoided. For all I know, this could be completely impossible to implement in AppleShare. But wouldn't it be nice if it were? How about it, Apple? -greg +----------------------------------------------------+ Greg Brail Internet: gjb@cs.brown.edu BITNET: gjb@browncs.bitnet UUCP: ..uunet!brunix!gjb Home: (401)863-6284
MacUserLabs@cup.portal.com (Stephan - Somogyi) (01/13/90)
gjb@cs.brown.edu (Greg Brail) writes: >Currently, if the AppleShare connection is lost because the network >is unplugged or the server crashes, a dialog box appears saying you >lost the connection to the server, the server is disconnected and >your program crashes. If AppleShare instead put up a dialog box >saying "The server has been disconnected" and then waited until it >could reconnect, no one would lose their work. You have *got* to be kidding. You mean that if my network connection goes down (for whatever reason) while I have a server mounted, you *want* the Mac to lock up? You would deem this a feature?! No, you must be kidding. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Stephan Somogyi Berlin ist 1 Reise wert NetWorkShop Manager MacUser Any opinions expressed above are mine.
roy@phri.nyu.edu (Roy Smith) (01/13/90)
In <25862@cup.portal.com> MacUserLabs@cup.portal.com (Stephan - Somogyi): > if my network connection goes down [...] while I have a server mounted, > you *want* the Mac to lock up? You would deem this a feature?! What's the big deal? Just put a button in the dialog box to abort the connection, if you prefer not to wait. Make the hitting the abort button issue a "are you sure you want to do this?" alert dialog warning the user that aborting the connection might cause work to get lost. -- Roy Smith, Public Health Research Institute 455 First Avenue, New York, NY 10016 roy@alanine.phri.nyu.edu -OR- {att,philabs,cmcl2,rutgers,hombre}!phri!roy "My karma ran over my dogma"
dce@smsc.sony.com (David Elliott) (01/14/90)
In article <1990Jan13.151947.15612@phri.nyu.edu> roy@phri.nyu.edu (Roy Smith) writes: >In <25862@cup.portal.com> MacUserLabs@cup.portal.com (Stephan - Somogyi): >> if my network connection goes down [...] while I have a server mounted, >> you *want* the Mac to lock up? You would deem this a feature?! > > What's the big deal? Just put a button in the dialog box to abort >the connection, if you prefer not to wait. This would need to be a modeless dialog box. I shouldn't have to choose between keeping the connection and using other applications under MultiFinder. It's probably useful to have a "system" alert that tells you the connection is lost, but also the ability to have each application be sent a message so that it can decide whether it needs to do something special. -- David Elliott dce@smsc.sony.com | ...!{uunet,mips}!sonyusa!dce (408)944-4073 "Baziotes! Baziotes! Getcha red hot Baziotes here!"
gjb@cs.brown.edu (Greg Brail) (01/14/90)
In article <25862@cup.portal.com> MacUserLabs@cup.portal.com (Stephan - Somogyi) writes: >You have *got* to be kidding. You mean that if my network connection >goes down (for whatever reason) while I have a server mounted, you >*want* the Mac to lock up? You would deem this a feature?! > >No, you must be kidding. No, I am certainly not kidding. Let's say, for example, that you're working on a project on your Mac using a copy of Word on the fileserver. Someone accidentally kicks an AppleTalk connector apart between you and the fileserver -- or the server crashes. The way AppleShare works now, your Mac will crash and you'll lose the work you're doing on your project. If the Mac locked up until it could reach the server again, you wouldn't lose any work. Don't feel like waiting? Hit the interrupt key, or, as someone else suggested, put an "Abort" button in the dialog. It all makes sense to me. When making suggestions for a 45,000-reader newsgroup, I don't kid. -greg +----------------------------------------------------+ Greg Brail Internet: gjb@cs.brown.edu BITNET: gjb@browncs.bitnet UUCP: ..uunet!brunix!gjb Home: (401)863-6284
MacUserLabs@cup.portal.com (Stephan - Somogyi) (01/15/90)
roy@phri.nyu.edu (Roy Smith) writes: >Just put a button in the dialog box to abort the connection, if you >prefer not to wait. Make the hitting the abort button issue a "are >you sure you want to do this?" alert dialog warning the user that >aborting the connection might cause work to get lost. The problem is: what are you going to do with novice users? There are going to be plenty of people who aren't going to have the foggiest idea what to do with that message."The server is disconnected" might not mean much to some people, but it will at least let them continue using their Mac. The next time they save their doc, their app should give them a Save As dialog (since the original volume is now gone) and let them save to a local volume. Sure, this still isn't perfect, but IMHO much better for the non-techie user than stopping them in their tracks if something outside of their Mac has gone awry. Stephan Somogyi NetWorkShop Manager MacUser
MacUserLabs@cup.portal.com (Stephan - Somogyi) (01/15/90)
gjb@cs.brown.edu (Greg Brail) writes: >Let's say, for example, that you're working on a project on your Mac >using a copy of Word on the fileserver. Someone accidentally kicks an >AppleTalk connector apart between you and the fileserver -- or the >server crashes. The way AppleShare works now, your Mac will crash and >you'll lose the work you're doing on your project. If you kick out the LocalTalk connector on your Mac, you lose network services, but your Mac *should not* crash. At least, the AShare client software shouldn't cause that crash, it should be giving you the "the server disappeared" dialog. There probably is network software out there that will crash if suddenly disconnected from the net, but that's not AShare's fault. >If the Mac locked up until it could reach the server again, you >wouldn't lose any work. Don't feel like waiting? Hit the interrupt >key, or, as someone else suggested, put an "Abort" button in the >dialog. I don't feel this is transparent enough for the novice. If the server's gone, it's gone. You don't want to have to make the net admin guy run around to all the secretaries saying "hit the 'Don't Wait' button, the server's down" just after his server's croaked. There is also the instance of the unattended Mac with a server volume mounted that is doing something. Just because the server goes down for some reason or other (something as innocuous as maintenance or backup at 2am would do it) shouldn't mean that a Mac stops dead. Outside influences should never impact a Mac such that it stops doing what it was doing for its user. I agree that the current scheme is not the best, but I think your solution makes more problems than it would solve. Stephan Somogyi NetWorkShop Manager MacUser
mithomas@bsu-cs.bsu.edu (Michael Thomas Niehaus) (01/15/90)
Stephan Somogyi writes: > The problem is: what are you going to do with novice users? There are > going to be plenty of people who aren't going to have the foggiest > idea what to do with that message."The server is disconnected" might > not mean much to some people, but it will at least let them continue > using their Mac. I think you miss the point here. If the application that you are using is on the server, it will crash the next time it tries to do a LoadSeg. Not many people would realize that this "The server is disconnected" message means that their machine will soon crash. Maybe you haven't experienced this. (I have. In fact, someone pulled the LocalTalk connector out of the back of one of our file servers once and all 15 of the machines that were in use crashed within 30 seconds. Try explaining that to users.) > The next time they save their doc, their app should give them a Save > As dialog (since the original volume is now gone) and let them save to > a local volume. This is only true if you only use the file server for data files. Most places use file servers for storage of common, shared applications (especially in the educational environment that is prevalent around here). If you are using an application that resides (or resided) on the file server, and if this save requires the OS to load another segment (which is more than likely in this day of 500-1000K programs), you will see an instant system error. > Sure, this still isn't perfect, but IMHO much better for the > non-techie user than stopping them in their tracks if something > outside of their Mac has gone awry. If something outside of their Mac has gone awry, something that could have such a serious affect on their work, I would hope that they would stop in their tracks to find out what that dialog box meant. Maybe a new dialog would only be necessary if the AppleShare client detects that the connection went down while an application that resides on the server was running. The ability to attempt to reconnect is crucial if the user is to have any hope of getting those two hours of work (or whatever) onto some disk without the machine crashing. > Stephan Somogyi > NetWorkShop Manager > MacUser Network shop, huh? Well, try this out then. Put an application (something like PageMaker) on an AppleShare file server. Run this application on a workstation. Pull the AppleTalk cable out of the back of your workstation. Keep using your application (after you acknowledge the message about the disconnection) and just see how long you do anything. Ideally, I believe that you should see a dialog like this: Your file server connection has been lost. Attempt to Reconnect OK Then if the user chooses to attempt to regain a connection, present another dialog: Trying to reestablish connection... Give Up Get the picture? -Michael -- Michael Niehaus UUCP: <backbones>!{iuvax,pur-ee}!bsu-cs!mithomas Apple Student Rep ARPA: mithomas@bsu-cs.bsu.edu Ball State University AppleLink: ST0374 (from UUCP: st0374@applelink.apple.com)
roy@phri.nyu.edu (Roy Smith) (01/16/90)
> I don't feel this is transparent enough for the novice. If the > server's gone, it's gone. You don't want to have to make the net admin > guy run around to all the secretaries saying "hit the 'Don't Wait' > button, the server's down" just after his server's croaked. I don't know how much this would complicate the protocol, but how about if, when you mount a remote disk, the server sends to the client a little bit of text, which could be set on a per-server or per-disk basis by the system administrator. When you get the "Server has gone down" dialog box, it could include this piece of text. A typical piece of text might be "if you don't understand what this means, call Roy Smith at x822 and ask for help". -- Roy Smith, Public Health Research Institute 455 First Avenue, New York, NY 10016 roy@alanine.phri.nyu.edu -OR- {att,philabs,cmcl2,rutgers,hombre}!phri!roy "My karma ran over my dogma"
ken@i-core.UUCP (Ken MacLeod) (01/16/90)
In article <25862@cup.portal.com>, MacUserLabs@cup.portal.com (Stephan - Somogyi) writes: >gjb@cs.brown.edu (Greg Brail) writes: > >>Currently, if the AppleShare connection is lost because the network >>is unplugged or the server crashes, a dialog box appears saying you >>lost the connection to the server, the server is disconnected and >>your program crashes. If AppleShare instead put up a dialog box >>saying "The server has been disconnected" and then waited until it >>could reconnect, no one would lose their work. > >You have *got* to be kidding. You mean that if my network connection >goes down (for whatever reason) while I have a server mounted, you >*want* the Mac to lock up? You would deem this a feature?! No, I wan't it to let me know that if I press "Disconnect" I might lose something. Given the chance, I (or someone who knows about the network) can try to fix the problem before being forced to disconnect. Also, an app should have a non-purgable pre-loaded code that can dump the document data to a recovery file when a disconnect-cannot reconnect error is received. With more and more networks coming in, how 'bout a "Recovery Manager" that an app registers it's data with. In the case of not being able to function any longer (no access to the rest of the app or data due to carrier loss, unplugging, dogs chewing on the cord, power-loss, etc.) the app receives the error and as gracefully as possible dies through the recovery manager. On system startup: "A copy of your document 'Foo' was saved when the system/application 'Bar' lost power/crashed, it has been saved in the 'Crash' folder." The program will have a module that will reconnect it's document when everything is running again and the 'CRSH' file-type document is opened. Crashing and/or losing data is not intuitive and is sure annoying. With this, virtual memory and hopefully process protection coming in, a little sense of reliability would go a long way. (Read: SALES! Hint, hint; do us both a favor :-) -- Ken MacLeod, Barkeep Bitsko's Bar & Grill BBS, +1 801 269-0670 ken@i-core.uucp
dawyd@gargoyle.uchicago.edu (David Walton) (01/16/90)
AppleShare could really use better facilities for keeping track of and
communicating with users. To wit:
* The ability to send messages to any or all users at any time,
instead of only when the server is about to shut down.
* Some form of accounting, by which I mean basic information about
when users log on and for how long.
AppleShare seems to have been written under the assumption that all
users would be in the same physical office, and that communicating
with users, if necessary, could always be done face-to-face. The
basic feedback mechanism was word of mouth. For those installations
that enable anonymous ('guest') login or which allow access across
multiple zones (where users are very likely in different buildings),
such communication isn't possible. The administrator can't really
gather the information he or she needs to assess how the server is
being used. Yet in a very primitive form, the basic functions for
getting that information--recording logins and logouts and
communicating with users--are already provided in AppleShare. The
information about who is logged in is displayed on-screen; and one can
broadcast a message to all users that the server is shutting down. I
could be wrong, of course ;-), but I can't imagine that Apple's
software engineers would have that much difficulty expanding those
functions just a bit.
Apple need not turn AppleShare into a large-scale package for managing
hundreds of accounts or providing access to users across the country,
but I do think that they should provide a few basic tools for using
their software and machines more effectively.--
David Walton Internet: dwal@tank.UChicago.EDU
University of Chicago { Any opinions herein are my own, not }
Computing Organizations { those of my employers (or anybody else). }jeff@eniac.seas.upenn.edu (Jeffrey M White) (01/17/90)
In article <581@gargoyle.uchicago.edu> dawyd@gargoyle.uchicago.edu.UUCP (David Walton) writes: >AppleShare could really use better facilities for keeping track of and >communicating with users. To wit: > >* The ability to send messages to any or all users at any time, > instead of only when the server is about to shut down. You can use the Broadcast rdev to do this. It allows you to send a message to one or all users on a network. It's public domain/shareware. Jeff White University of Pennsylvania jeff@eniac.seas.upenn.edu
jalden@eleazar.dartmouth.edu (Joshua M. Alden) (01/17/90)
In article <19068@netnews.upenn.edu> jeff@eniac.seas.upenn.edu.UUCP (Jeffrey M White) writes: >In article <581@gargoyle.uchicago.edu> dawyd@gargoyle.uchicago.edu.UUCP (David Walton) writes: >>AppleShare could really use better facilities for keeping track of and >>communicating with users. To wit: >> >>* The ability to send messages to any or all users at any time, >> instead of only when the server is about to shut down. > > You can use the Broadcast rdev to do this. It allows you to send a message >to one or all users on a network. It's public domain/shareware. > > Jeff White > University of Pennsylvania > jeff@eniac.seas.upenn.edu Hm... One problem that I see with using Broadcast in this capacity is that in order to receive the messages, each user must have it in the System Folder. Broadcast has a bad reputation among those of us who work at User Services here at Dartmouth. A Broadcast message that pops up at a bad time can produce crashes that are much worse than what I've seen from a networking loss. Also, if alot of people start using it (like our freshmen this year), the net slows measurably. My own personal gripe about Broadcast is that it is highly invasive. It pops up a dialog that must be acknowledged and dealt with before anything else can happen. Often to the detriment of whatever you're doing at the time, like saving a document, or running some sort of interactive program that requires quick responses (like games and some communications packages). So, in summary, I wouldn't recommend Broadcast for much of anything, let alone as an aid to network administration. -Josh. -- /--------------------------------------------------+-------------------------\ |Josh Alden, Consultant, Kiewit Computation Center | HB 48, Dartmouth College| | Private mail: Joshua.Alden@dartmouth.edu | Hanover, NH 03755 | | Virus mail: Virus.Info@dartmouth.edu | (603) 640-5734 |
dawyd@gargoyle.uchicago.edu (David Walton) (01/17/90)
In a previous article, I complained about AppleShare's lack of tools for
either accounting (tracking users' activities) and communicating with
said users over the network. Several folks recommended Broadcast. While
I like Broadcast and use it on my machine, it doesn't address the basic
question, which is:
How do you communicate with clients (users) when they are either
anonymous (logged in as guest) or off in buildings which are miles
away? It's a pain to make sure everybody has broadcast installed
if you've got users spread all over the place, and it's impossible
if those users are anonymous. Moreover, if some of your users are
logged in anonymously, by definition it's impossible to tell who
they are so that you may send them messages.
In short, while Broadcast is a partial solution (at least to one of
my complaints), it doesn't address what I see as the root of
the problem: AppleShare itself doesn't provide such tools, and it
should. I just don't see that adding these functions to AppleShare
would be that difficult.
(And we are after all saying what we think the future AppleShare
should have...)
--
David Walton Internet: dwal@tank.UChicago.EDU
University of Chicago { Any opinions herein are my own, not }
Computing Organizations { those of my employers (or anybody else). }MacUserLabs@cup.portal.com (Stephan - Somogyi) (01/17/90)
mithomas@bsu-cs.bsu.edu (Michael Thomas Niehaus) writes about applications being stored on the AppleShare server. I had not considered this. My error. To the best of my recollection, AppleShare was designed for sharing data, not apps. Yes, you can do it, yes, you can set the shared bit on an app, but that doesn't mean that it's a good idea or even that Apple recommends it. Everyone I know recommends agaainst it most strongly. Just because lots of people do it, doesn't necessarily mean it's right. Of course, lots of people do launch apps from servers, regardless, and so the whole concept of a spec becomes a bit moot. AShare was designed for roughly 10 people/server sharing data. AFP gives you all the byte-range locking stuff you need to run multi-user apps. That's it. There should be a way of saving a current file even is you have an app launched from a server. But, this would require some major hacking on the part of the Apple folks. >> Stephan Somogyi >> NetWorkShop Manager >> MacUser > >Network shop, huh? Well, try this out then. Yeah. That's my title and the NetWorkShop's where I work. >Put an application (something like PageMaker) on an AppleShare file >server. Run this application on a workstation. Pull the AppleTalk >cable out of the back of your workstation. Keep using your >application (after you acknowledge the message about the >disconnection) and just see how long you do anything. Not very long, I know. >Ideally, I believe that you should see a dialog like this: > > Your file server connection has been lost. > > Attempt to Reconnect OK > >Then if the user chooses to attempt to regain a connection, present >another dialog: > > Trying to reestablish connection... > > Give Up > >Get the picture? Sure. But if you give up, you're still hosed. There needs to be a way of recovering your data. That's the point I'm making. No amount of dialogs and options like this are going to fix this problem. Someone at Apple needs to think about this and deal with it. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Stephan Somogyi Berlin ist 1 Reise wert NetWorkShop Manager MacUser Any opinions expressed above are mine.
mithomas@bsu-cs.bsu.edu (Michael Thomas Niehaus) (01/17/90)
I don't see that it is necessary to add Broadcast-type features to
AppleShare, since the ability to do such work is not dependent on the
existence of AppleShare. Using normal AppleTalk calls, you can develop
a decent system. What advantages would AppleShare add to this
setup? (Or to use a cliche, what does AppleShare bring to the party?)
Someone should write an APPLICATION somewhat like Backgrounder that just
sits and waits for incoming messages. When a message does come, the
Notification Manager should be used to notify the user that a message
is waiting. They should then have to switch to that application to
read the message (or to send a message). This prevents "rude interruptions"
of the current foreground application.
Any other opinions?
-Michael
--
Michael Niehaus UUCP: <backbones>!{iuvax,pur-ee}!bsu-cs!mithomas
Apple Student Rep ARPA: mithomas@bsu-cs.bsu.edu
Ball State University AppleLink: ST0374 (from UUCP: st0374@applelink.apple.com)mithomas@bsu-cs.bsu.edu (Michael Thomas Niehaus) (01/17/90)
Stephan Somogyi writes: > To the best of my recollection, AppleShare was designed for sharing > data, not apps. Yes, you can do it, yes, you can set the shared bit on > an app, but that doesn't mean that it's a good idea or even that Apple > recommends it. Everyone I know recommends agaainst it most strongly. > Just because lots of people do it, doesn't necessarily mean it's > right. I believe AppleShare was created for sharing files. With a good file sharing system, differentiation between data and applications shouldn't be needed. Sharing applications at educational institutions is very common, since many colleges find it difficult to justify the expense of adding a hard drive to every machine (and they like to boast that they are using file servers). Sharing applications is very painful and slow, but in some situations it is needed to keep some functionality. > AShare was designed for roughly 10 people/server sharing data. AFP > gives you all the byte-range locking stuff you need to run multi-user > apps. That's it. That may be a good rough estimate for a file server running over LocalTalk. For EtherTalk, that number would be increased. There is no limitation in the software. You just have to ask yourself how long you (or the other users) are willing to sit and wait. > Stephan Somogyi > NetWorkShop Manager > MacUser > > Yeah. That's my title and the NetWorkShop's where I work. Well, there is an ad in MacWeek this week that was placed by MacUser. They are looking for a Product and Network lab manager. For those who are interested, qualifications include 5 or more years of experience as a project/ technical manager, poreferably for a publication; a BS degree in EE, Physics, CS, or journalism is also desired. The interesting thing about the advertisement: It doesn't say where to write or who to contact. I guess they expect you to figure this out yourself. > There needs to be a way of recovering your data. That's the point I'm > making. No amount of dialogs and options like this are going to fix > this problem. Someone at Apple needs to think about this and deal with > it. Agreed. But if Apple doesn't do it, how much pain would it be to write an application that does full journaling (like DEC's VMS editors)? Or you could switch to WordPerfect for the Mac, which will backup your work every minute (or less frequent). -Michael -- Michael Niehaus UUCP: <backbones>!{iuvax,pur-ee}!bsu-cs!mithomas Apple Student Rep ARPA: mithomas@bsu-cs.bsu.edu Ball State University AppleLink: ST0374 (from UUCP: st0374@applelink.apple.com)
captkidd@athena.mit.edu (Ivan Cavero Belaunde) (01/18/90)
In article <10584@bsu-cs.bsu.edu> mithomas@bsu-cs.UUCP (Michael Thomas Niehaus) writes: >Someone should write an APPLICATION somewhat like Backgrounder that just >sits and waits for incoming messages. When a message does come, the >Notification Manager should be used to notify the user that a message >is waiting. They should then have to switch to that application to >read the message (or to send a message). This prevents "rude interruptions" >of the current foreground application. >Any other opinions? >-Michael Well, I believe the problems in BroadCast are caused by bugs in the software, and are not inherent to the practice of "rude interruptions." Just as an example, another program that interrupts whatever you're doing when it deems necessary is Vaccine (and Gatekeeper as well). They have *never* crashed on me. It should be possible, then, to modify Broadcast so that it uses a similar mechanism to these programs when putting up the dialog box with the message. I don't think a separate program is needed. This forces you to use MultiFinder/System7 (when it comes out). That's not a reasonable alternative for a lot of people with 1Meg macs - not everyone has 2M+... Of course, a separate program using an identical communications protocol should be available for the ones who are using MultiFinder/Sys7, and work as Mike described. But MF/Sys7 shouldn't be a prerequisite for message sending ability over AppleTalk - it should be able to be implemented bug-free. Just my $.02 -Ivan Cavero Belaunde "If Cerebus had a navel, would you drink Apricot brandy out of it?" Internet: captkidd@ATHENA.MIT.EDU
MacUserLabs@cup.portal.com (Stephan - Somogyi) (01/18/90)
mithomas@bsu-cs.bsu.edu (Michael Thomas Niehaus) writes: >I don't see that it is necessary to add Broadcast-type features to >AppleShare, since the ability to do such work is not dependent on the >existence of AppleShare. Using normal AppleTalk calls, you can >develop a decent system. What advantages would AppleShare add to >this setup? It's not so much that you want Broadcast's capabilities, but that you want the server admin to be able to send messages to people who are logged on. NetWare lets you do this and it's quite useful, most especially if some users are outside of shouting distance. >Someone should write an APPLICATION somewhat like Backgrounder that >just sits and waits for incoming messages. When a message does come, >the Notification Manager should be used to notify the user that a >message is waiting. They should then have to switch to that >application to read the message (or to send a message). This >prevents "rude interruptions" of the current foreground application. What about all those machines which can't run MF due to lack of RAM? Can the Notification Mgr be called from an INIT (and without MF) in such a way as to bring up a message without 'being rude'? That story from Dartmouth makes it painfully clear that whatever does the messaging needs to be as nice and friendly as possible. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Stephan Somogyi Berlin ist 1 Reise wert NetWorkShop Manager MacUser Any opinions expressed above are mine.
dent@unocss..unl.edu (Local Submission) (01/18/90)
mithomas@bsu-cs.bsu.edu (Michael Thomas Niehaus) writes: >I don't see that it is necessary to add Broadcast-type features to >AppleShare, since the ability to do such work is not dependent on the >existence of AppleShare. Using normal AppleTalk calls, you can develop >a decent system. What advantages would AppleShare add to this >setup? (Or to use a cliche, what does AppleShare bring to the party?) >Someone should write an APPLICATION somewhat like Backgrounder that just >sits and waits for incoming messages. When a message does come, the >Notification Manager should be used to notify the user that a message >is waiting. They should then have to switch to that application to >read the message (or to send a message). This prevents "rude interruptions" >of the current foreground application. Well, I agree that user-to-user electronic communication has nothing to do with AppleShare. But! Administrator-to-user communication really is something that's needed, for the same reason that it is /already/ in AppleShare in the form of "Shutdown Notices". Let me give you an example. We have public user rooms here, with Macs all connected to an SE/30 AppleShare / PrintShare server. The server (and the LaserWriter for the lab) lives in the "Consultant Office", which is on the other side of the room from the Macs. Not an ideal situation, I realize.. but anyway.. If the LaserWriter suddenly bursts into flames, or there is a tornado about to decimate the building, it would be nice to be able to send a message to the users logged onto the server (all of which use the Guest account, BTW) to inform them of these types of things. They don't need to be able to send back a message (in fact I'd rather that they couldn't), but the ability to send a broadcast to all (or even some?) users would be VERY helpful. "But what about Broadcast?" I'm not sure what Broadcast does, but it consistently crashes Macs here, and we finally gave up and removed it from all of the public Macs. This is unfortunate, because it's really a pretty neat little program. So here's the big question: *WHAT* is Broadcast doing that the Mac doesn't like? Or are some appications not following rules for memory allocation, and then freaking out when Broadcast comes in? I realize that Microsoft has a long standing reputation for not exactly following the guidelines :-), but I've never seen one of those applications crash because of a "Shutdown Notice" that AppleShare has sent them... -/ Dave Caplinger /--------------------------------------------------------- Microcomputer Specialist, Campus Computing, Univ. of Nebraska at Omaha mspecial@zeus.unl.edu ...!uunet!unocss!dent MSPECIAL@UNOMA1
MacUserLabs@cup.portal.com (Stephan - Somogyi) (01/19/90)
mithomas@bsu-cs.bsu.edu (Michael Thomas Niehaus) writes: >I believe AppleShare was created for sharing files. With a good file >sharing system, differentiation between data and applications >shouldn't be needed. You're absolutely right. But the MacOS works the way it does, and that includes the pseudo-vmem scheme used by the resource mgr. Unless an app preloads all its code and any other bits it needs, it'll encounter problems when a server disconnects abruptly. Saying that AShare is for sharing files is all well and good, but not realistic. I write: > AShare was designed for roughly 10 people/server sharing data. Michael writes: >That may be a good rough estimate for a file server running over >LocalTalk. For EtherTalk, that number would be increased. There is >no limitation in the software. You just have to ask yourself how >long you (or the other users) are willing to sit and wait. The operative word is *designed*. The current iteration of AppleShare was developed with LocalTalk in mind. There is a limitation in the software. 25 nodes or so max per server. Once you reach that limit you get a message saying 'Too many users logged on.' Also, we've found here that giving an AShare server more than 2MB RAM is a waste; it all becomes RAM cache. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Stephan Somogyi Berlin ist 1 Reise wert NetWorkShop Manager MacUser Any opinions expressed above are mine.
mystone@mondo.engin.umich.edu (Dean Yu) (01/20/90)
In article <26091@cup.portal.com> MacUserLabs@cup.portal.com (Stephan - Somogyi) writes: >There is a limitation in the software. 25 nodes or so max per server. >Once you reach that limit you get a message saying 'Too many users >logged on.' Actually, it's dependent on the number of DDP sockets that can be opened to the server. So you can get up to 50 users on a Mac II based server. (Fewer if you have other network applications that use DDP sockets running on the server.) >Also, we've found here that giving an AShare server more than 2MB RAM >is a waste; it all becomes RAM cache. The RAM cache can increase the performance of the server dramatically... Just picking nits while I'm waiting for my ride to lunch... :) _______________________________________________________________________________ Dean Yu | E-mail: mystone@caen.engin.umich.edu Mac Support & | Real-mail: Dean Yu Self declared License Czar | Rm 145 Chrysler Building University of Michigan | 2121 Bonnisteel Computer Aided Engineering Network | Ann Arbor, MI 48109 INCLUDE 'Disclaimers.a' | Phone: (313) 763-3070 -------------------------------------------------------------------------------
siegel@endor.harvard.edu (Rich Siegel) (01/20/90)
In article <1581@unocss..unl.edu> dent@unocss..unl.edu (Local Submission) writes: >Well, I agree that user-to-user electronic communication has nothing to do >with AppleShare. But! Administrator-to-user communication really is something >that's needed, for the same reason that it is /already/ in AppleShare in the >form of "Shutdown Notices". Let me give you an example. I agree with this, and an additional necessity is "remote-admin-to- server" commuication. I'm the administrator of the office server, and it's a real pain to have to run to the back room to do things like create a new group, or add users, or delete users, or perform AppleShare Print Server administration. A Remote Administrator would be *real nice*. R. ~~~~~~~~~~~~~~~ Rich Siegel Staff Software Developer Symantec Corporation, Language Products Group Internet: siegel@endor.harvard.edu UUCP: ..harvard!endor!siegel "When someone who makes four hundred and fifty dollars an hour wants to tell you something for free, it's a good idea to listen." ~~~~~~~~~~~~~~~
xdaa374@ut-emx.UUCP (William T. Douglass) (01/22/90)
In article <1323@husc6.harvard.edu> siegel@endor.UUCP (Rich Siegel) writes: >In article <1581@unocss..unl.edu> dent@unocss..unl.edu (Local Submission) writ: > >>But! Administrator-to-user communication really is something >>that's needed, for the same reason that it is /already/ in AppleShare in the >>form of "Shutdown Notices". 2 comments: 1) Does anyone else feel that the 1 group/folder restriction in AppleShare is too restricting? I'd like like to be able to create folders where some groups had r/o access, & some had r/w access. God knows the abilty to dynamically change groups would be nice too. 2) Can anyone compare some of the limitations of Ashare to other Macintosh AFP servers available today, such as Novell NetWare/Mac, and IPT's Personal Server Net Thx. -- Bill Douglass, TCADA "I dreamed I was to take a test, in a Dairy Queen, on another planet." L. Anderson
landman@hanami.Sun.COM (Howard A. Landman x61391) (01/23/90)
>gjb@cs.brown.edu (Greg Brail) writes: >>Currently, if the AppleShare connection is lost because the network >>is unplugged or the server crashes, a dialog box appears saying you >>lost the connection to the server, the server is disconnected and >>your program crashes. If AppleShare instead put up a dialog box >>saying "The server has been disconnected" and then waited until it >>could reconnect, no one would lose their work. In article <25862@cup.portal.com> MacUserLabs@cup.portal.com (Stephan - Somogyi) writes: >You have *got* to be kidding. You mean that if my network connection >goes down (for whatever reason) while I have a server mounted, you >*want* the Mac to lock up? You would deem this a feature?! > >No, you must be kidding. If you weren't so used to stupid modal dialogs that lock up the machine, you might see that there is an alternative. Of course, it would help to have real multitasking. Howard A. Landman landman@eng.sun.com -or- sun!landman