No abstract available.

Article High-latency, low-bandwidth windowing in the Jupiter collaboration system Share on Authors: David A. Nichols Xerox PARC, 3333 Coyote Hill Rd., Palo Alto, CA Xerox PARC, 3333 Coyote Hill Rd., Palo Alto, CAView Profile , Pavel Curtis Xerox PARC, 3333 Coyote Hill Rd., Palo Alto, CA Xerox PARC, 3333 Coyote Hill Rd., Palo Alto, CAView Profile , Michael Dixon Xerox PARC, 3333 Coyote Hill Rd., Palo Alto, CA Xerox PARC, 3333 Coyote Hill Rd., Palo Alto, CAView Profile , John Lamping Xerox PARC, 3333 Coyote Hill Rd., Palo Alto, CA Xerox PARC, 3333 Coyote Hill Rd., Palo Alto, CAView Profile Authors Info & Claims UIST '95: Proceedings of the 8th annual ACM symposium on User interface and software technologyDecember 1995 Pages 111–120https://doi.org/10.1145/215585.215706Online:01 December 1995Publication History 99citation2,591DownloadsMetricsTotal Citations99Total Downloads2,591Last 12 Months44Last 6 weeks3 Get Citation AlertsNew Citation Alert added!This alert has been successfully added and will be sent to:You will be notified whenever a record that you have chosen has been cited.To manage your alert preferences, click on the button below.Manage my AlertsNew Citation Alert!Please log in to your account Save to BinderSave to BinderCreate a New BinderNameCancelCreateExport CitationPublisher SiteGet Access

Access control programs (ACPs), which permit controlled delegation of access rights to untrusted computer hosts, are discussed. Existing delegation protocols for distributed systems provide a way for a client to transfer its access rights to an intermediary, but provide only limited facilities for restricting the rights granted to the intermediary. ACPs are small programs that encode arbitrary specifications of delegated access rights. They are created and digitally signed by a client and passed to a server through an intermediary. When processing a request from the intermediary, the server executes the access control program to decide whether or not to grant the intermediary's request. Examples of ACPs used in a variety of applications are presented. A sample implementation of ACPs in the Andrew File System is described.>

In a database to which data is continually added, users may wish to issue a permanent query and be notified whenever data matches the query. If such continuous queries examine only single records, this can be implemented by examining each record as it arrives. This is very efficient because only the incoming record needs to be scanned. This simple approach does not work for queries involving joins or time. The Tapestry system allows users to issue such queries over a database of mail and bulletin board messages. The user issues a static query, such as “show me all messages that have been replied to by Jones,” as though the database were fixed and unchanging. Tapestry converts the query into an incremental query that efficiently finds new matches to the original query as new messages are added to the database. This paper describes the techniques used in Tapestry, which do not depend on triggers and thus be implemented on any commercial database that supports SQL. Although Tapestry is designed for filtering mail and news messages, its techniques are applicable to any append-only database.

The Andrew File System is a location-transparent distributed tile system that will eventually span more than 5000 workstations at Carnegie Mellon University. Large scale affects performance and complicates system operation. In this paper we present observations of a prototype implementation, motivate changes in the areas of cache validation, server process structure, name translation, and low-level storage representation, and quantitatively demonstrate Andrews ability to scale gracefully. We establish the importance of whole-file transfer and caching in Andrew by comparing its performance with that of Sun Microsystems NFS tile system. We also show how the aggregation of files into volumes improves the operability of the system.

Andrew is a distributed computing environment being developed in a joint project by Carnegie Mellon University and IBM. One of the major components of Andrew is a distributed file system which constitutes underlying mechanism for sharing information. The goals of the Andrew file system are to support growth up to at least 7000 workstations (one for each student, faculty member, and staff at Carnegie Mellon) while providing users, application programs, and system administrators with the amenities of a shared file system.

The Butler system is a set of programs running on Andrew workstations at CMU that give users access to idle workstations. Current Andrew users use the system over 300 times per day. This paper describes the implementation of the Butler system and tells of our experience in using it. In addition, it describes an application of the system known as gypsy servers, which allow network server programs to be run on idle workstations instead of using dedicated server machines.