Add means to indicate static/dynamic status of TD

[mmccool]

In order to support caching and other non-local distribution mechanisms, the scripting API should have a way to indicate that a TD is likely to be updated or not. The scripting API should not get into details of the mechanism, just provide a way to mark a TD as static (say, a lock() method) or dynamic and liable to change (unlock()).

Whether or not TDs are considered to be static or not has other implications, eg. with how transient resources (eg. URLs for monitoring subscriptions) are handled (and whether or not such "transient" resources belong in the TD at all).

NOTE: Details, use cases, etc. to follow. This is placeholder for future discussion.

[mmccool]

Based on discussion in the meeting Jan 15, perhaps we don't want lock/unlock. Instead we need to provide sufficient metadata so that the delivery mechanism for TDs can do a good job delivering any updates to the TD. I think there are probably three mechanisms: HTTP (along with HTTP caching in the network), a directory service, and publish/subscribe (perhaps with "latching" to store the state of published topics). In all these cases a very common thing to want to know is the time to live. This is a value, provided by the server, how long it expects the data provided to be static. When the TTL expires, in the case of HTTP, it actually uses a HEAD message to check if it needs to fetch an update (it may not). A directory also needs to do something similar; as does latched pub/sub.

At any rate, the API should have some way of attaching options to TD exposure, and TTL is one of the most important ones, common to many distribution mechanisms. We probably also need some specific mechanism to proactively "push" out updates. Both of these can be abstractions at the level of the scripting API and do not have to refer to specific mechanisms like HTTP caches (TTL is a generic concept).

[zolkis]

Addressed by #86. Caching implementations need to subscribe to TD change notifications.