Difference between revisions of "EPrints4 Roadmap"

From EPrints Documentation
Jump to: navigation, search
m (Change category Developer to Contribute)
(One intermediate revision by the same user not shown)
Line 1: Line 1:
Some general ideas for the development of the next major release of EPrints.  
Some general ideas for the development of the next major release of EPrints.  

Latest revision as of 23:53, 11 September 2018

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

Also read EPrints4_Status

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). Actually this is done via: DB Transactions, ETag and If-None-Match headers. The current (3.2/3.3) object locking is a UI feature not a core one.
  • 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) <DONE>
  • 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.


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

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


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

Current Dev tasks (stuff in progress)

  • Complex UI elements such as forms with validations - Currently using a mix of Mustache (server-side templates) and AngularJS (client-side) - btw some cool stuff here: http://angular-ui.github.io/bootstrap/
  • (Deep) integration of Xapian into the core:
    • but keeping it generic enough to allow other implementation of other search engines
    • must find a way to (1) conduct a user search via Xapian and (2) merge the results with a DB-bound search to restrict to items that the user can effectively search (think ACL here)
    • Must find a way to generate API pages from the code/POD