Contents

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

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>

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>

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.

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)