Interface that must be defined for every object being cached. readResource and writeResource are implemented by default as read-write to files with its key as filename serialize and deserialize are specified just to allow these defaults. If you define your own persistence, then serialize and deserialize are not needed. The package Workflow need them anyway.

minimal definition: keyResource, serialize, deserialize

While serialize and deserialize are agnostic about the way of converison to strings, either binary or textual, treadp and tshowp use the monad defined in the RefSerialize package. Both ways of serialization are alternative. one is defined by default in terms of the other. the RefSerialize monad has been introduced to permit IResource objects to be serialized as part of larger structures that embody them. This is necessary for the Workdlow package.

The keyResource string must be a unique since this is used to index it in the hash table. when accessing a resource, the user must provide a partial object for wich the key can be obtained. for example:

data Person= Person{name, surname:: String, account :: Int ....)

keyResource Person n s ...= n++s

the data being accesed must have the fields used by keyResource filled. For example

  readResource Person {name=John, surname= Adams}

leaving the rest of the fields undefined

IResource has defaults definitions for all the methods except keyResource Either one or other serializer must be defiened for default witeResource, readResource and delResource

Key datatype can be used to read any object trough the Dynamic interface.

 data Key =  Key TypeRep String deriving Typeable

Example

  mst <- getDResource $ Key type keyofDesiredObject
             case mst of
               Nothing -> error $ "not found "++ key
               Just (idyn) ->  fromIDyn idyn :: DesiredDatatype}

this is the main function for the *Resource calls. All the rest derive from it. The results are kept in the STM monad so it can be part of a larger STM transaction involving other TVars The Resources register returned by the user-defined function is interpreted as such:

toAdd: additional resources not read in the first parameter of withSTMResources are created/updated with toAdd

toDelete: from the cache and from permanent storage

toReturn: will be returned by withSTMResources