Why a content repository for Collaborilla?
- Apache Jackrabbit for Java
- No outside connections to other systems
- WebDAV can be (or is?) implemented in Jackrabbit as well
- Versioning is native
- Access control
- Full text searching
- Event monitoring
- Compact deployment
- No LDAP server, no patching
- No additional DB (Apache Derby can be used as backend)
- No dependencies
- No network traffic between Collaborilla service and repository: faster data access
- LDAP alone is not sufficient
- difficult (impossible?) to index
- hard to adapt to new features (discussions, ...)
- Jackrabbit's JAAS (Java Authentication and Authorization Service) can be combined with Shibboleth
- Which backend should we use?
- JDBC, Derby, XML, ...
- Is the size of blobs limited?
- Do big data blobs impact the performance?
- Does it make sense to publish directly into the content repository?
- Should we switch to RMI?
Implementation - What Jackrabbit can be used for
- Content repository for Collaborilla
- RDF-information and the dependencies
- Publishing of containers directly to the repository
- Conzilla to Jackrabbit or
- Conzilla to Collaborilla to Jackrabbit
- Usage of native Jackrabbit WebDAV
- Is there an implementation?
- How good is the implementation?