EPrints4 Roadmap - Revision history

Kgoetz: Change category Developer to Contribute

2018-09-11T23:53:39Z

Change category Developer to Contribute

Kgoetz: adding categories

2018-08-30T06:36:00Z

adding categories

Sf03r@ecs.soton.ac.uk at 15:23, 21 May 2014

2014-05-21T15:23:17Z

Sf03r@ecs.soton.ac.uk at 16:53, 24 March 2014

2014-03-24T16:53:29Z

Sf03r@ecs.soton.ac.uk: /* Main Objectives */

2014-03-24T16:52:32Z

‎Main Objectives

Sf03r@ecs.soton.ac.uk at 16:51, 24 March 2014

2014-03-24T16:51:08Z

Sf03r@ecs.soton.ac.uk: /* UI elements */

2013-11-18T16:37:44Z

‎UI elements

Sf03r@ecs.soton.ac.uk: /* Core */

2013-11-18T16:15:31Z

‎Core

Sf03r@ecs.soton.ac.uk: /* Core */

2013-11-13T17:14:34Z

‎Core

Sf03r@ecs.soton.ac.uk: /* Core */

2013-11-06T14:15:24Z

‎Core

@@ Line 1: / Line 1: @@
 [[Category:Eprints4]]
-[[Category:Developer]]
+[[Category:Contribute]]
 Some general ideas for the development of the next major release of EPrints.

← Older revision		Revision as of 06:36, 30 August 2018
Line 1:		Line 1:
		+	[[Category:Eprints4]]
		+	[[Category:Developer]]
	Some general ideas for the development of the next major release of EPrints.		Some general ideas for the development of the next major release of EPrints.

← Older revision		Revision as of 15:23, 21 May 2014
Line 74:		Line 74:

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

← Older revision		Revision as of 16:53, 24 March 2014
Line 1:		Line 1:
−	Some general ideas for the development of the next major release of EPrints.	+	Some general ideas for the development of the next major release of EPrints.
		+
		+	Also read [[EPrints4_Status]]

	==Main Objectives==		==Main Objectives==

@@ Line 11: / Line 11: @@
 * 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:

@@ Line 40: / Line 40: @@
 * 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.

@@ Line 67: / Line 67: @@
 * CSS3 Responsive design to support small screens (mobile, tablets etc) - http://alistapart.com/article/responsive-web-design
 ==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.

← Older revision		Revision as of 16:15, 18 November 2013
Line 45:		Line 45:

	* (coding-style) don't use objects via hash-value directly e.g. my $repo = $object->{repository} - use method instead: my $repo = $object->repository.		* (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 26: / Line 26: @@
 ==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.
+* 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
-* 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) - 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)

← Older revision		Revision as of 14:15, 6 November 2013
Line 43:		Line 43:

	* 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)
		+
		+	* (coding-style) don't use objects via hash-value directly e.g. my $repo = $object->{repository} - use method instead: my $repo = $object->repository.

	==Extensions for IR-type of Repositories==		==Extensions for IR-type of Repositories==