Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!sdd.hp.com!spool.mu.edu!olivea!mintaka!ogicse!rogere
From: rogere@ogicse.ogi.edu (Roger Ellingson)
Newsgroups: comp.sys.isis
Subject: Re: printing ISIS 2.1 man pages
Message-ID: <22820@ogicse.ogi.edu>
Date: 13 Jun 91 20:30:15 GMT
References: <214@conan.UUCP> <1991Jun13.130855.3543@cs.cornell.edu>
Organization: Oregon Graduate Institute (formerly OGC), Beaverton, OR
Lines: 39

In article <1991Jun13.130855.3543@cs.cornell.edu> ken@CS.Cornell.EDU (Ken Birman) writes:
>Now, as to whether ISIS is easy to use: the feedback we get on this
>is basically very positive...
>On the other hand, reasonably sophisticated, experienced programmers
>seem to find ISIS very straightforward and quite powerful.  It certainly
>works effectively on the very hard aspect of this sort of distributed
>computing, and this is no other approach that comes close.........

Speaking from a research ISIS installation viewpoint:
(no commercial ISIS experience)

Agreed! We have just completed a graduate level distributed systems course here
at OGI.  Using ISIS for class project programming support has been
a real boon for student implementation of distributed algorithms.
(Comment: Until one tries to implement their own ordered communication support, 
they might not appreciate how much benefit ISIS is!)

We have ISIS running on three different `sites', Sun, uVax, and Sequent,
and have found it to be robust, well documented and simple to install and
maintain.  When and if trivial bugs have been discovered, the ISIS group at Cornell
has been extremely prompt in explanation, suggested fixes, pointers, etc.

The ISIS group has contributed and maintains a cohesive online set of
related research papers which IMHO is unsurpassed in accommodating understanding
both theory and implementation of key distributed programming 
abstractions---ordered multicast and corresponding communication groups.

>I would be happy to see more debate in this newsgroup, for example about
>how abcast should work when groups overlay (should multicasts to different
>groups be ordered in the overlap region, or is this unecessary)...

Still chomping on this one.  

>new tools (Levy's proposal on lightweight process groups, for example).

Sorry, but is there a reference for the above proposal?

Anyway, just one poor man's living testimonial,
Roger Ellingson, rogere@cse.ogi.edu