=========
SCAM TODO
=========
1. Several SCAM-applications within the same JBoss
- command-chain is defined in web.xml, default is "command-chain.xml"
- CommandChainConfiguration, ViewBean, etc. non-static
-> application-scope bean
=> Changes in the build process: move configuration values from scam.properties
to relevant configuration files (web.xml, discriptors, etc)
Problem:
Applications are forced to share data
- Seach ALL manifests
- list manifests
- unknown RDF.type:s
Solution:
Different Repository-instances read their own config-params from
deployment descriptors instead of scam.properties (used as "fallback").
2. Garbage-collection of RDB (Jena 2 migration may solve this issue)
3. "Fail-safe" chains
- Create default-Item, abort SHAME -> empty Resource
- A better value for "n/a" (language dependent)
4. taglibs must be able to handle "wrong" metadata, e.g. bNode is missing.
- Alt 1: abort -> wrong presentation?
- Alt 2: continue -> traverse branch, use default-values.
5. Performance/scalability measurements (Repository)
6. Admin-interface
- Add/remove/update users/manifests, backup/restore
New EJB: UserAdminBean
- add/remove users
- user editable by SHAME; getUser(String name) -> Model
- different implementations for different LoginModule:s
7. Locking of Resources; recursive locks?
8. System without ACLs with everything readable by "guest"?
9. SSO HTTP
10. Requirements specification of SCAM?
11. Replace scamEditor with SHAME.
- JSP implementation of the UI?