Message-ID: <356315564.3576.1485853736370.JavaMail.confluence@ip-10-127-227-164> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_3575_2005772977.1485853736370" ------=_Part_3575_2005772977.1485853736370 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
The eZ Publish 5 API supports multiple binary file handling mech=
anisms by means of an IOHandler
interface.
The system comes with three handlers: Legacy, InMemory and Filesystem. O= nly Legacy is supported in eZ Publish 5.1. It uses the Legacy Kernel, that = supports the DFS file handler, in order to provide clustering features for = scalability and safety. This handler provides multi-server storage by means= of a database + a network share.
No eZ Publish 5 level steps are required at the time of 5.1. See the leg= acy documentation page that explains how to setup a DFS clus= ter.
No configuration is required on the new stack. The handler will reuse wh= atever configuration is defined in your eZ Publish Legacy instance. By defa= ult, Legacy will be configured to use the FS cluster handler, meaning files= will be stored on the filesystem. No further configuration will be require= d.
The Legacy documentation explains how to enable clustering: http://doc.ez.no/eZ-Publish/Technic= al-manual/5.x/Features/Clustering.
Note that the only two supported options are now FS and DFS. The DB clus= ter is deprecated, and doesn't exist in eZ Publish 5.1.
As for legacy, rewrite rules are required in order to serve files stored= in a DFS cluster. The virtualhost setup documentation provides the required rules.