EPrints3 Roadmap

2016 Community Roadmap

Goals

• Create a more comprehensive set of Unit tests for EPrints so community contributions can be accepted more easily
• Deprecate old subs from repository into BackCompatibility with a warning saying what version they will abort and what function should be used as an alternative (make_element, make_text, render_data_element, etc,etc)
• Remove references to these deprecated subs within the core code
• Start moving render functions for objects into the XHTML class in order to get all the rendering in one place (see section below)
• Start removing references to repository from objects where they should not occur.
• Create and maintain a comprehensive list of desired features/functionality for EPrints

EPrints API implementation

Removing render functions

Many objects in eprints have render functions. For example $list->render_description and $dataset->render_description. This breaks the single responsibility principle for these objects. For example $list has to know about how to cache and retrieve lists of dataobjs and union and intersect with other lists but also has to know about how it is expected to appear in and XHTML page. This responsibility for $xhtml. Example $xhtml->list($list). These kind of changes would mean that many objects would no longer need a reference to $repository. List is currently instantiated with a reference to $repository. It uses this reference to get access to $database (which it actually needs), get access to $xhtml functions so it can render its description (should not be its responsibility) and $plugin_factory to instantiate a plugin from a string for export (probably the plugin should be passed in rather than the plugin_id).

Following this change to its logical conclusion means no objects in the EPrints core will have render methods. Once all XHTML is generated in one class it will become easier to make changes to aspects of rendering such as amalgamating citations, phrases and templates into one coherent language.

The proposed changes to list would allow us to remove its internal reference to repository but still expand the $list section of the core api from:

list

 $n = $list->count;
 $list->map( sub {
     my ( $repository, $dataset, $dataobj, $ctx ) = @_;
     # do something to the dataobj here
 }, $ctx );
 $dataobj = $list->item( $offset );
 @all_dataobjs = $list->slice 
 @dataobjs = $list->slice( $offset, $length ); 
 \@ids = $list->ids;

extended to:

list

 $n = $list->count;
 $list->map( sub {
     my ( $repository, $dataset, $dataobj, $ctx ) = @_;
     # do something to the dataobj here
 }, $ctx );
 $dataobj = $list->item( $offset );
 @all_dataobjs = $list->slice 
 @dataobjs = $list->slice( $offset, $length ); 
 \@ids = $list->ids;
 $list->export($plugin) # rather than plugin id 
 $list->description # string description of the list. This might not get added because im not actually convinced it is used...

XHTML

If rendering the description of list is important XHTML would gain

 $xhtml->list($list)

Open Repositories Conference 2016 UG Notes

Source code management

• Bazaar contributors also deposit the plugin source code to GitHub

Development strategies & technology

• Integration of jQuery and Bootstrap (already listed on the Roadmap on the Wiki)
• Support full responsive design

Features to add to the core (or 3.4 ‘zero’?)

• highlight snippets of text from each search result , for example: https://www.elastic.co/guide/en/elasticsearch/guide/current/highlighting-intro.html
• review use of MySQL utf8 (probably should be using utf8mb4)
• ORCID
• UKETD_DC export update (e.g. mapping ORCIDs)
• OAI-PMH access logger (to check you’re getting harvested)

Strategies for EPrints community

• Creation of "Best Practices" section in the Wiki (e.g.: recommended format of documentation in the EPrints source code, variable naming conventions, recommended classes/methods, deprecated or unsupported classes/methods, using session or repository?)
• Development of funding to allow for the creation of a community manager role
• Development of user interface in EPrints documentation and special interest events.