Difference between revisions of "EPrints4 Roadmap"

From EPrints Documentation
Jump to: navigation, search
(Main Objectives)
m (Change category Developer to Contribute)
 
(16 intermediate revisions by 2 users not shown)
Line 1: Line 1:
Some general ideas for the development of the next major release of EPrints.
+
[[Category:Eprints4]]
 +
[[Category:Contribute]]
 +
Some general ideas for the development of the next major release of EPrints.  
 +
 
 +
Also read [[EPrints4_Status]]
  
 
==Main Objectives==
 
==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.
+
* 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)
 
* Remove the spaghetti code (esp (1) rendering methods (2) Dataobj-Metafield relations)
Line 9: Line 13:
 
* 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 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
+
* Drop support for Windows?
  
* 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). 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)
+
* 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:
 
* code normalisation:
Line 21: Line 25:
  
 
* 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.
 +
 +
* It might be worth separating the code into 3 packages to ease the development: eprints4-core, eprints4-ir and eprints4-ir-ui.
  
 
==Core==
 
==Core==
  
* Revisit Apache request Handler (lots of hard-coded paths, many obsolete paths)
+
* 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
 
* Remove EPrints::Session from anywhere in favour of EPrints::Repository
  
* Test using memcached (http://code.google.com/p/memcached/) - Cache::Memcached::Fast to cache data objects, perhaps could work to cache XML fragments too.
+
* Test using memcached (http://code.google.com/p/memcached/) - Cache::Memcached::Fast to cache data objects, perhaps could work to cache XML fragments too. <TESTED OK>
  
* Use Multipart rather than Compound - Compound creates 1 table per subfield whilst Multipart creates 1 column per subfield.
+
* 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)
+
* 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)
+
* 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)
 
* Built-in locking mechanisms for objects (improved edit_lock)
  
* No hard-coded exceptions for IR extensions (e.g. eprint_status hard-coded in places)
+
* 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)
+
* 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==
 
==Extensions for IR-type of Repositories==
Line 59: Line 70:
  
 
* CSS3 Responsive design to support small screens (mobile, tablets etc) - http://alistapart.com/article/responsive-web-design
 
* CSS3 Responsive design to support small screens (mobile, tablets etc) - http://alistapart.com/article/responsive-web-design
 +
 +
* Consider http://getbootstrap.com/javascript/ -  http://getbootstrap.com/components/
 +
 +
==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)
 +
** Must find a way to generate API pages from the code/POD

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.

Core

  • 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

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)
    • Must find a way to generate API pages from the code/POD