winborne@physics.unc.edu (George Winborne) (05/16/91)
Help! I am confused by the sea of CAP versions and CAP patches. We were running CAP 5.0 ( or maybe it was 6.0) till last fall some time when I switched over to RU-CAP V2 from Rutgers because of Ethertalk support & lwsrv -X option to require LaserWriter users to be logged in to aufs. I have been anxiously hoping for Phase 2 support & now see that it is projected to be out soon in CAP 6.0 with patches & then CAP 6.1 "from munnari.OZ.AU and (soon) rutgers.edu." I think I must have missed something. Have RU-CAP and CAP-CAP --) been merged or were they always the same or what? I just want the least chaos when I try to go Phase 2 and be able to keep what has been gained (printing authorization, etc.) I don't think I am only one confused by this, if so my apologies for the wasted bandwidth. George Winborne Dept. of Physics & Astronomy University Of North Carolina - Chapel Hill Chapel Hill, NC 27599-3255
djh@cs.mu.oz.au (David Hornsby) (05/18/91)
winborne@physics.unc.edu (George Winborne) writes: > I am confused by the sea of CAP versions and CAP patches. * The CAP family tree ... ru-cap -> ru-cap2 / \ / / \ / ... 3.0 -> 4.0 -> 5.0 --------> 6.0 --------------> 6.1 ---> ... | \ / | ptchs 1-15 | Berkeley | +new features | | -- patches -- CAP 6.0 started life as the 5.0 distribution, over the summer break it had all of the 5.0 patches I could find stuffed in, followed by all the new features from the Rutgers distribution and the (local) Berkeley distribution, UAB (UNIX AppleTalk Bridge) & finally, some Melbourne additions. Since being released in March, there have been a number of patches fixing assorted bugs, there are a bunch more to come late May/early June that introduce some new features, Phase 2 support on SUNs and (?) ULTRIX 4.0 being the one perhaps of most interest. After a little time to make sure it's stable, a 6.1 tar file with all the mods included will be available (so if you apply all the patches to 6.0, you won't need to do another installation!!) [NB: at present, it is likely that the cap60/patches directory will be discarded in 6.1 as excess baggage] After that (this time more than 6 months I HOPE), 6.2 with the same easy upgrade path. There are lots of things that need to be done to CAP (like, shudder, lint) and heaps of people with specific areas of interest to keep it up to date (EG: System 7.0, LaserWriter ProcSets, AUFS N.0 ...). I'm happy to coordinate updates for CAP 6, we use it to support a large ugrad teaching load and at various places on campus, so the time can be justified (actually, I'm just using the rest of the Internet to maintain CAP for us :-) I hope this helps ... - David. * Potted answer for FAQ CAP stands for the Columbia AppleTalk Package, it was written by Charlie Kim and Bill Schilit, with contributions from hordes of other people and institutions. CAP provides a set of libraries to implement the AppleTalk protocol stack on UNIX hosts. There are also Application programs to act as an AppleShare Server (aufs) and LaserWriter Spooler (lwsrv). CAP will run on most UNIX boxes that run BSD'ish network code using IPTalk (Apple Talk Packets inside IP/UDP packets) for which you need an external gate- way for IPTalk<->EtherTalk<->LocalTalk translation. On SUN workstations and ULTRIX hosts, you can also produce Phase 1 EtherTalk packets (soon also Phase 2). CAP comes with a bunch of useful utilities. You can get CAP 6.0 via anonymous (binary) FTP from the following sites rutgers.EDU src/cap60.tar.Z src/cap60.patches munnari.OZ.AU mac/cap60.tar.Z mac/cap.patches lth.SE Mac/Unix/Cap/cap60.tar.Z uunet.UU.NET networking/cap/cap60.tar.Z mcsun.EU.NET network/appletalk/cap60.tar.Z If you don't have FTP access, or have new code to add to CAP, send email to cap@munnari.OZ.AU, the best place to ask CAP-related questions is the newsgroup comp.protocols.appletalk.
hedrick@athos.rutgers.edu (Charles Hedrick) (05/19/91)
The family tree could suggests that Rutgers is still maintaining a separate CAP. Although I have qualms about Melbourne's abandonment of the shared memory that I used in RU-CAP2 (because atis has no way to update routing info used by other processes), we are currently cooperating on Melbourne's 6.x, not doing our own version. The purpose of having 6.x at Rutgers is so you can get it from a U.S. site, and save the trans-Pacific link. It's not so much that there are multiple sources for CAP, but rather than the "best" version moves around depending upon who has time. I believe the torch has now passed to Melbourne.