EPrints4 Roadmap

Some general ideas for the development of the next major release of EPrints.

Main Objectives

• Separation of the Core API and UI (/rendering) components - that mainly means that core objects (Repository, MetaField*, DataObj*) won't have any render_* method. this could also imply that the core or the UI could be upgraded separately. It would also make re-use of the eprints core easy for other purposes (e.g. data repository, OER etc.)

• 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)

• Implement object state at the core level (at the moment EPrint object might be in one of 4 states: inbox, buffer, archive, deletion via the field eprint_status)

• 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.

• It might be worth separating the code into 3 packages to ease the development: eprints4-core, eprints4-ir and eprints4-ir-ui.

Core

• Revisit Apache request Handler aka Apache::Rewrite (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

• CSS3 Responsive design to support small screens (mobile, tablets etc) - http://alistapart.com/article/responsive-web-design

Misc

• an internal messaging system would be nice (similar to the current Message data object but with more options) - this would help system/user and user/user interactions. A logged-in user could then see messages and act accordingly. For instance: publication just went live, items have been imported from remote sources, user commented on a resource etc.