Editing EPrints4 Roadmap (section)

==Core==

* Revisit Apache request Handler aka Apache::Rewrite (lots of hard-coded paths, many obsolete paths) - URL handling should be done by Controllers called/prioritised via a trigger. <TESTED OK>

* Remove EPrints::Session from anywhere in favour of EPrints::Repository

* Test using memcached (http://code.google.com/p/memcached/) - Cache::Memcached::Fast to cache data objects, perhaps could work to cache XML fragments too. <TESTED OK>

* Use Multipart rather than Compound - Compound creates 1 table per subfield whilst Multipart creates 1 column per subfield. <TESTED OK>

* Finer grain permissions (using User, Groups, perhaps ACL concepts) - also security should be handled at the core level not at the UI level

* Core should be able to run without IR extensions nor UI elements (might require to extend the SWORD layer for interactions with the core) <TESTED OK>

* Built-in locking mechanisms for objects (improved edit_lock)

* No hard-coded exceptions for IR extensions (e.g. eprint_status hard-coded in places) <TESTED OK>

* Generalise concept of "files" to allow the storage of arbitrary files against any data objects (e.g. a profile picture for a User) <TESTED OK>

* (coding-style) don't use objects via hash-value directly e.g. my $repo = $object->{repository} - use method instead: my $repo = $object->repository.

* Metafield/DataObj::set_value should re-enforce the database type - i.e. $object->set_value( 'int_field', 'abc' )should fail at the Application layer - not silently at the DB layer as it currently happens. Same goes with any field type (e.g. ->set_value( 'set_field', 'invalid_set_value' ) should fail). <TESTED OK>

* Extra dataset properties to allow global, consistent behaviour. Considered: "states", "revision" (TESTED OK), "lastmod" (TESTED OK), "read-only" (TESTED OK), "cache" (i.e. use memcached), "history" (keep revision history, implies revision=true), "datestamp", "acl"