ESciDoc Cache

Purpose

 * Efficient delivery of list of resources user is authorized to see

Present use cases
Lists are at present used together with a filter definition (translates to a query expression) with following methods: As a result a list of resources (consisting of only items or only containers) is delivered. There are possibilities to page this list or to limit the desired number of results to be delivered with the list (offset, limit). For each list derived in such a manner, total number of results in the list is known.
 * retrieveItems
 * retrieveContainers

Basic list requirements

 * list contains full escidoc-xml representation of resources (i.e. mixture or separate item/container accordingly to item.xsd, container.xsd)
 * list contains only authorized resources i.e. the resources the user who requests the list is able to see
 * total number of list entries must be known

Other requirements

 * a list should deliver only last versions of resources? (this is at present the case)
 * a list should be able to deliver exact versions of resources (if requested)?
 * a list should deliver versions of resources user has privilege to see?

Key-Value: Berkeley DB

 * high performance
 * high availability
 * embedded into the application process (server-less)
 * java api
 * http://www.oracle.com/database/berkeley-db/index.html
 * open source for open source projects


 * check integration with Lucene for administrative searches additionally
 * key-value pairs only
 * is it indeed applicable? check jointcursors limitations

Lucene

 * separate index for all latest versions (instead of DBCache) (feasible)?
 * for items: an item contain all attributes needed to cross-check the authorization
 * instead of appending SQL to filter, would it be possible to append query to the user query that deals with auth data?
 * is the problem how to actually derive this query?
 * is this also valid for containers? (i.e. an item may be a member of several containers, but i think this has nothing to do)

If this would be possible, no additional cache would be needed?