Each function wishing to access a contig on a long term basis needs to register itself before accessing the data. For example, the template display and contig editors should register, but show relationships produces a report taken from a single snap shot of the data and so does not need to register.
The idea of registering is to allow communication between views of the same (or derived) data, this insuring that they can be automatically kept up to date when modifications are made, and can provide mechanisms to prevent multiple, incompatible, edits of the same data. An example can be seen in the template display. Suppose we have the display showing contig 4. A join contig operation links this to contig 7 and produces a new contig -- number 10. Other contig numbers may have shuffled too: if we had 9 contigs then contig 9 may well be renumbered to contig 4.
Therefore we need to notify any functions displaying contig 9 of a contig number change. We also need to notify displays of contig 4 that the number is now 10, and both this and contig 7 that the contents and length has changed.
Central to the scheme is the result manager. This displays a list of which data is registered and provides a further method for the user to interrogate specific results.
Notifications may also be for requesting data as well as informing changes. All registered items must respond to certain notifications, such as for determining the name of the function, so that it can be listed in the results manager.