A deterministic operation is one that, given the same input, always produces the same output (for more info, see Wikipedia on function and the Prevayler page on deterministic).

With HTTP's Expires header, I am thinking that one can indicate that, for a window of time, a URL request / response (input / output) is deterministic in a time-local sense.

In the iCite net, I am thinking about cachability and deterministic operations. If the systems knows that a specific input will always produce the same output, it has an optimization opportunity to cache (and distribute) the output. In particular, I am thinking about queries that might work this way (specifically, caching results of queries against "permanent" content).

The guidelines for HTTP Expires say that resources that "never expire" should be indicated by a date approximately one year after the request. Unfortunately, this would be ambiguous in the case of a resource that actually was meant to expire in one year.

Based on this (and other protocol independent ideals), I am thinking that the iCite net definition of expires should not be directly tied to HTTP headers, and should be indicated in another manner that can include a distinct "never expires" value.

But, I think REST introduces an interesting concept of a time-local deterministic operation that I might incorporate: that is, the deterministic and expires indicators are combined. A resource that always expires is always non-deterministic, a resource that never expires is deterministic, and a resource that expires at some time is locally deterministic between now and that time.

After the time of an expired resource, the operation may produce the same result or may not. In HTTP terms, a cached resource that has expired hasn't necessarily changed, but rather that the original resource should be polled to see if it has changed (e.g., by checking the Last-Modified header).

However, this all suggests another state that might be good to account for, which is "may expire at some unknown time". Because the iCite net interactions can be peer-to-peer, a server can notify a client when a resource expires.

So, I think this all represents a good model:

• I probably will change, and I can tell you when I do
• I definitely will change
• I definitely will be the same until time X, and will most likely change after that
• I will never change

To suggest some more context, I am thinking about what bloggers call permalinked content. At a certain point at least, that content becomes fixed. And, at least ideally, that content remains always accessible in that fixed state.

So, queries that, for example, extract all the links from a bunch of permalinked blog entries into a result set, can, at least at a certain point, cache and distribute that result set without polling or refreshing the query.