Editing EPrints4 Roadmap (section)

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