Difference between revisions of "EPrints4 Roadmap"

From EPrints Documentation
Jump to: navigation, search
(UI elements)
(Main Objectives)
Line 12: Line 12:
  
 
* Implement object locking at the core level (for any objects, perhaps without using database fields at all)
 
* 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:
 
* code normalisation:
Line 19: Line 21:
  
 
* 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.
 
* 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.
 
  
 
==Core==
 
==Core==

Revision as of 18:44, 25 October 2013

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

Main Objectives

  • Separation of the Core API and UI (/rendering) components
  • 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.

Core

  • Revisit Apache request Handler (lots of hard-coded paths, many obsolete paths)
  • 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.
  • 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