Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!yale!ox.com!sendai!rich From: rich@sendai.sendai.ann-arbor.mi.us (K. Richard Magill) Newsgroups: comp.sys.isis Subject: Re: detecting client failures Message-ID: Date: 24 Mar 90 07:45:37 GMT References: <38995@cornell.UUCP> Sender: rich@sendai.UUCP Reply-To: rich@sendai.ann-arbor.mi.us Distribution: comp Organization: Digital Works, Ltd. - Ann Arbor, MI Lines: 28 In-reply-to: ken@gvax.cs.cornell.edu's message of 23 Mar 90 17:49:38 GMT In article <38995@cornell.UUCP> ken@gvax.cs.cornell.edu (Ken Birman) writes: > From: rich@sendai.ann-arbor.mi.us (K. Richard Magill) (via email) > From: ken@gvax.cs.cornell.edu (Ken Birman) > Newsgroups: comp.sys.isis > Date: 22 Mar 90 15:50:46 GMT > Reply-To: ken@gvax.cs.cornell.edu (Ken Birman) > Robert Cooper has an idea for a very fancy mechanism that would let > a client (any client) drop "offline" for a while and then come back... >I know precisely the problem here and I'd be sorely dissappointed to >see you spend the time to solve it within isis rather than with isis. I don't know; seems like it would be more in the spirit of a toolkit to provide the servers with a cleaner warning that the client wants to do this and way to spool data conveniently. But, you might be right. After all, your company would be a typical user of this sort of facility, so if you don't see it as a necessary add-on... Hmm.. I suspect that no matter how you implement such a facility, it would only be useful to me for a short while. In any case, I might be tempted to use it. What I meant was that this is functionality that can be provided at the user/above-isis level. I'd rather see the isis project apply their resources to the items already on their wishlist. :-). For instance, I think the scaling issue would be of use to more potential users.