Difference between revisions of "EPrints4 Roadmap"
(Created page with 'Some general ideas for the development of the next major release of EPrints. ==Main Objectives== * Separation of the Core API and UI (/rendering) components * Remove the spagh…') |
|||
| Line 29: | Line 29: | ||
* Use Multipart rather than Compound - Compound creates 1 table per subfield whilst Multipart creates 1 column per subfield. | * Use Multipart rather than Compound - Compound creates 1 table per subfield whilst Multipart creates 1 column per subfield. | ||
| + | |||
| + | * Finer grain permissions (using User, Groups, perhaps ACL concepts) | ||
| + | |||
| + | * Core should be able to run without IR extensions nor UI elements (might require to extend the SWORD layer for interactions with the core) | ||
| + | |||
| + | * Built-in locking mechanisms for objects (improved edit_lock) | ||
| + | |||
| + | * No hard-coded exceptions for IR extensions (e.g. eprint_status hard-coded in places) | ||
| + | |||
| + | * Generalise concept of "files" to allow the storage of arbitrary files against any data objects (e.g. a profile picture for a User) | ||
| + | |||
| + | |||
| + | ==Extensions for IR-type of Repositories== | ||
| + | |||
| + | * Authors/names stored in a separate dataset - should help integrate with various UID systems like OrcID. | ||
| + | |||
| + | * Extra metadata to describe a User - cf. MePrints. | ||
| + | |||
| + | ==UI elements== | ||
| + | |||
| + | * jQuery over Prototype | ||
| + | |||
| + | * jQueryUI widgets used to render fields | ||
| + | |||
| + | * Javascript/Ajax concepts built-in | ||
Revision as of 17:16, 25 October 2013
Some general ideas for the development of the next major release of EPrints.
Main Objectives
- Separation of the Core API and UI (/rendering) components
- Remove the spaghetti code (esp (1) rendering methods (2) Dataobj-Metafield relations)
- Drop support for internal search in favour of specialist tools such as Xapian or Solr - we might however need to keep some aspects of the internal search (cf List/data retrieval) for exact matching - perhaps that's more a (SQL) "QueryBuilder" than a (user) search.
- Drop support for Windows
- Implement object locking at the core level (for any objects, perhaps without using database fields at all)
- code normalisation:
- use new class name (e.g. EPrints::Session => EPrints::Repository)
- use "new way" of doing things (e.g. EPrints::Dataobj::X->new(12) => repo->dataset( 'x' )->dataobj(12))
- remove v2.x features deprecated in v3+ (cf. EPrints::BackCompatibility)
- define clear API for core functions (e.g. Database, object handling) and for UI purposes. The API must present a unique way of doing something.
Core
- Revisit Apache request Handler (lots of hard-coded paths, many obsolete paths)
- 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.
- Use Multipart rather than Compound - Compound creates 1 table per subfield whilst Multipart creates 1 column per subfield.
- Finer grain permissions (using User, Groups, perhaps ACL concepts)
- Core should be able to run without IR extensions nor UI elements (might require to extend the SWORD layer for interactions with the core)
- Built-in locking mechanisms for objects (improved edit_lock)
- No hard-coded exceptions for IR extensions (e.g. eprint_status hard-coded in places)
- Generalise concept of "files" to allow the storage of arbitrary files against any data objects (e.g. a profile picture for a User)
Extensions for IR-type of Repositories
- Authors/names stored in a separate dataset - should help integrate with various UID systems like OrcID.
- Extra metadata to describe a User - cf. MePrints.
UI elements
- jQuery over Prototype
- jQueryUI widgets used to render fields
- Javascript/Ajax concepts built-in
