Daisy publishing setup scenarios

Below a number of publishing/usage scenarios for Daisy are mentioned, and how each of them can scale to larger usage loads. Note that these are theoretical options, currently not implemented. At the time of this writing, there is only the Daisy Wiki (without caching).

• Daisy Wiki
• scalability options:
• introduce cache for guest-user access
• dispatch guest user requests to (read-only) replicas of the repository server
• publish-only:
• with online usage of repository server (for full text search, faceted browsing)
• could be scaled by having (read-only) replicas of the repository server
• without online usage of repository server, but some dynamic behaviour:
• the data from the repository server is exported, the publication frontend does all its work based on this export and does not need a live copy of the repository server.
• the export is gradually updated by a process that listens to the repository server for change events
• there can be as many instances of this publication frontend as you want, each one works independently from the other
• completely static: for large sites & frequent updates, generating a new static snapshot of the entire site will not always be feasible. Doing incremental updates in this case is hard (updates to navigation trees can cause many/all documents to be invalidated).