Satellites provide a way to associate arbitrary textual information such as names and expressions with Chipndale instances. This document describes all users need to know about satellites in order to use them.

A satellite is an instance of Chipndale text that has been associated explicitly with another (non-text) Chipndale instance called the satellite's master; a master along with its satellites is called a satellite group. A satellite group exists in a world, which is a list of Chipndale instances that is either the contents of some Chipndale cell or of the top level of the design.

A useful model of satellites is that they are visible properties attached to the master. However, there are three key differences between satellites and ordinary properties: First, satellites are always visible while a user must do something explicit to display properties. Second, the user has complete control over the looks and placement of satellites, while properties are displayed in a fixed way. Finally, satellites are simply text strings; this is in contrast with properties, which have type information associated with them.

The association between a master and its satellites is made via a special groupIdProp property attached to each. The value of this property is an integer that is unique (within the design) to the satellite group in question. This method of associating group members is convenient for interactive purposes, but unfortunately it is not sufficient for a reasonable programming interface. The problem is that in order to find an instance's satellites we need to know the world in which these satellites exist. For many applications carrying around the world is inconvenient, so it behooves us to provide a way to find an instance's satellites given just the instance. This more convenient way is provided by putting a satellitesProp property on the master, which has as its value the list of text instances that are the master's satellites. (If you're wondering why just having the list of text instances alone does not suffice see Appendix A.)

Satellites satisfy a number of invariants which may be taken as a definition for satellites:

The programming interface provides procedures to add, remove, and retrieve satellites from a given master. A final procedure allows clients to guarantee that the defining invariants are preserved after manipulation.

To run CDSatellites you need to do the following:

The current version of satellites has gone through a number of redesigns and reimplementations as deficiencies were discovered and fixed, and several people have contributed their ideas and time. The initial implementation was by Louis Monier. A complete redesign was done by Bertrand Serlet and Pradeep Sindhu, followed by several iterations over this design. It took one more complete redesign and reimplmentation (by Pradeep Sindhu) to get to the current version.

There are two problems with just having a list of instances that records a master's satellites: the first takes a small matter of programming to fix, while the second is basic. The SMOP problem is that properties that have Cedar LIST's as values cannot be written out to Chipndale files. The basic problem is that Chipndale instances are not permanent entities—they can disappear and be replaced by an identical instance at any time (well, not any time, but you get the idea). Therefore we cannot cache REF's to instances.