<?xml version="1.0" encoding="utf-8"?>
<html>
Summary
NOTE: This proposal has been superseded by Limited _ Invalidation.
Standard HTTP caching is well suited for specifying a retention policy over static data. Dynamic or user modified data as is found in a typical opensocial application forces a difficult tradeoff between update interval and cache retention. It is often the case that longer cache lifetimes appear buggy to the user because of inconsistent data or frozen updates after edits.
...
Invalidation is implemented at the HTTP level and can be applied to any resource retreived by a container.
Terminology
...
...
- Resource - the result of resolving a URL, and typically a unit of caching
...
- Key - A set identifier for a resource; resource can have many keys and keys may apply to many resources
...
- Invalidation - An instruction to expire all resources associated with a key
...
- Expire - A cached document that is no longer fresh (by HTTP or because of a key invalidation)
...
- Container - the OpenSocial container that acts as the principal or proxy for requests to the developer machine
...
- Cache - proxy and storage for resource retreival and endpoint for receiving invalidation
...
- Endpoint - URL for invalidating key sets
...
- Origin - developer owned machine containing the resources
Resource States
...
- UNCACHED - a resource is not present in the cache and it will be retreived the next time it's requested. The cache may decided to drop files at any time.
...
- UNEXPIRED - a resource is in cache and known not to be expired, it will be returned from the cache next time it is requested.
...
- EXPIRED - a resource is in cache, but is thought to be expired. On the next request, the cache will revalidate or retreive from the origin.
Origin States
...
...
- NONE - there's no known origin, there should be no resources from this origin in cache
...
- ACTIVE - an identifier for the origin is known and it's still within the ttl
...
- EXPIRED - an identifier for a object is known, but it is outside the ttl. All resource from this origin are considered EXPIRED.
...
- TERMINATED - the origin is known to changed identifiers, all keys associated with this origin are INVALID and all resources are EXPIRED.
Key States
...
...
- VALID - the key is known to be valid.
...
- INVALID - the key is known to be invalid and all resources associated with the key are EXPIRED.
Scope
- Discovering an invalidation endpoint
- Establishing subscriptions
- Assigning keys to resources
- Invalidating keys
- Garbage collecting subscriptions
Reference
A cache relationship is negotiated through HTTP headers sent with each request and returned with each response. The origin is then required to notify the cache which keys are invalid and by extension which documents are invalid.
Invalidate-Endpoint request header
The Invalidate-Endpoint header is sent when the cache supports invalidation-based expiration for the requested resource. When this header is not sent, standard HTTP cache negotiation applies.
...
| Code Block |
|---|
Invalidate-Endpoint: http://apps.yahooapis.com/invalidate/77f8s8- |
Invalidate response header
A resource that can be cached will contain one of more Invalidate response header.
...
The cache always assigns the following keys to a resource:
uriPath - <tt>/opensocial/view.php?opensocial_ownerid=myspace.com:55566827</tt>55566827
| Panel |
|---|
from the request line HTTP message |
host - <tt>stickerappstickerapp.com</tt>com
| Panel |
|---|
from the Host HTTP header |
invalidate endpoint - <tt>
...
http://myspaceapis.com/invalidate/62663
...
</tt>
| Panel |
|---|
from the Invalidate-Endpoint HTTP header |
An OpenSocial request includes the additional keys:
gadgetUrl - <tt>
...
</tt>
| Panel |
|---|
applied to all resources that are not user-specific but are referenced from the gadget file: message bundles, template libraries. The expected use of this key is to support publishing resource changes. |
opensocial id - <tt>googlegoogle.com:gga8880ah</tt>gga8880ah
| Panel |
|---|
The opensocial id used to make an authenticated request. Supports a simple case which will invalidate all views associated with a particular user. |
Invalidation Request
Keys are invalidated by HTTP POST to the invalidate endpoint. The post entity MUST be content type text/plain and contain a whitespace delimited set of keys that are now invalid.
...
POSTs to the invalidation endpoint MUST require a two-legged OAuth signature.</html>