NAME

       Jifty::CAS - Jifty's Content-Addressable Storage facility

SYNOPSIS

         my $key = Jifty::CAS->publish('js' => 'all', $content,
                             { hash_with => $content, # default behaviour
                               content_type => 'application/x-javascript',
                             });

         $ie_key = Jifty::CAS->publish('js' => 'ie-only', $ie_content,
                             { hash_with => $ie_content,
                               content_type => 'application/x-javascript',
                             });

         $key = Jifty::CAS->key('js', 'ie-only');
         my $blob = Jifty::CAS->retrieve('js', $key);

DESCRIPTION

       Provides an in-memory "md5"-addressed content store.  Content is stored under a "domain",
       and can be addressed using wither the "key", which is an "md5" sum, or the "name", which
       simply stores the most recent key provided with that name.

BACKENDS

       The default data store is an per-process, in-memory store.  A memcached backed store is
       also available and has the benefits of sharing the cache across all instances of a Jifty
       app using Jifty::CAS.  The memcached store is limited to objects less than 1MB in size,
       however.

METHODS

   publish DOMAIN NAME CONTENT METADATA
       Publishes the given "CONTENT" at the address "DOMAIN" and "NAME".  "METADATA" is an
       arbitrary hash; see Jifty::CAS::Blob for more.  Returns the key on success, or undef on
       failure.

   key DOMAIN NAME
       Returns the most recent key for the given pair of "DOMAIN" and "NAME", or undef if none
       such exists.

   retrieve DOMAIN KEY
       Returns a Jifty::CAS::Blob for the given pair of "DOMAIN" and "KEY", or undef if none such
       exists.

   serve_by_name DOMAIN NAME REQUESTED_KEY
       Intelligently serves up the content of the object at NAME (not REQUESTED_KEY) in DOMAIN.
       REQUESTED_KEY is currently used only to check if the content at NAME equals the content
       requested.  If so, this method responds with an HTTP 304 status, indicating the content
       hasn't changed.  This use case assumes that content is served to clients from the CAS with
       the CAS key (an MD5 sum) as the filename or part of it.

       The "content_type" key in the requested object's metadata is expected to be set and is
       used for the HTTP response.

       This method is usually called from a dispatcher rule.  Returns the HTTP status code set by
       this method (possibly for your use in the dispatcher).