EPrints Documentation - User contributions [en-gb]

Main Page

2014-06-17T15:16:26Z

Sf03r@ecs.soton.ac.uk:

[[Category:Rubbish]]
__NOTOC__

'''Welcome to the EPrints Wiki'''

This wiki contains technical and user-contributed documentation for the [[Introduction|EPrints software]].

[http://demoprints3.eprints.org/ Demoprints] is our live, online server that allows anyone to try EPrints without having to install it first.

For more information on the EPrints project and related activities visit http://eprints.org/.

== Download EPrints ==

{{Download}}

==Installation==

* [[:Category:Installation|Installing]] EPrints on various platforms

==Getting Started==

* [[EPrints Manual|EPrints 3 Documentation]]
* [http://www.eprints.org/software/training/ Training materials] provided by EPrints Services.
* [[Frequently Asked Questions]]
* [[:Category:Howto|How to...]]
* [[IRStats2 API]]

==Getting Support==

* [http://www.eprints.org/services/ EPrints Services] - premium support, training and hosting from EPrints experts
* [[Contact]] - mailing lists, bug reports etc.

==Add-ons, patches and translations==

* The [http://files.eprints.org/ EPrints Files Repository] contains add-on and 3rd party scripts, patches and translations. This also provides an archive of all previous EPrints releases (3.0 onwards).
* [[:Category:Plugins|Plugins]]: Some Wiki pages about scripts and patches.

{{Register}}

==Contributing to EPrints==

* [[Usability|EPrints usability]]
* [[:Category:Releases|New features in EPrints]] - released and proposed
* [[How to contribute|How to contribute to EPrints development]]
* [http://trac.eprints.org/ EPrints Trac] - access nightly builds, tickets and changes (requires free registration to view source code)

== Content management ==

* [[Digital preservation]]: managing content for longer-term access and use

Installing EPrints on Debian/Ubuntu

2014-06-06T10:50:13Z

Sf03r@ecs.soton.ac.uk:

[[Category:Debian and Ubuntu]]
[[Category:Installation]]

David Tarrant has built a Debian/Ubuntu package for Eprints.

=APT Mirrors=

<b>Add one of the following mirrors (2 lines) to your /etc/apt/sources.list file as the root user. Please ensure that there is only one set in the file or you may not experience the correct behaviour.</b>

==EPrints Latest==

To install the testing build add *one* the following to /etc/apt/sources.list:

===Stable Builds===

deb http://deb.eprints.org/ stable/
deb-src http://deb.eprints.org/ source/

===Testing Builds===

deb http://deb.eprints.org/ unstable/
deb-src http://deb.eprints.org/ source/

===Nightly Build===

Rather than the above add the following to /etc/apt/sources.list (note that this code is in developement and will not neccessarily compile):

deb http://deb.eprints.org/ nightly/
deb-src http://deb.eprints.org/ source/

==EPrints 3.X (Specific Version Locking)==
===Stable Release===

Add the following to /etc/apt/sources.list:

deb http://deb.eprints.org/3.X/ stable/
deb-src http://deb.eprints.org/3.X/ source/

===Unstable Release===

To install the latest '''unstable''' release add the following to /etc/apt/sources.list:

deb http://deb.eprints.org/3.X/ unstable/
deb-src http://deb.eprints.org/3.X/ source/

===Nightly Build===

To install the nightly build add the following to /etc/apt/sources.list:

deb http://deb.eprints.org/3.X/ nightly/
deb-src http://deb.eprints.org/3.X/ source/

=Installing Eprints via apt-get=

To install Eprints and all its dependencies execute the following (as root):

apt-get update
apt-get install eprints

=Setting up a Repository=
You should now have a working installation of eprints in /usr/share/eprints3/. Please follow the on-screen instructions to set up an eprints repository. You probably want to start with (as root):

'''For more information about setting up an EPrints repository take a look at [[Getting Started with EPrints 3]]'''

<b>Read First: Known issues with the Debian/Ubuntu package can be found at [[Debian Known Issues]].</b>

su eprints
cd
./bin/epadmin create
logout
a2ensite eprints3
apache2ctl restart

If you have any problems getting set up you can get free help and support from the EP-Tech mailing list. {{EPrintsTech}}

=Getting and Compiling from Source (not required)=

To install dependencies and retrieve the Eprints source execute the following:

apt-get update
apt-get build-dep eprints
apt-get source eprints

The source will be saved to a tarball in the current directory.

=Issues with Ubuntu 13/14 (Apache 2.3/2.4)=

Apache 2.3+ and PERL v5.16+ introduce a few changes which break EPrints.

Current patches on github are:

* See last comment on https://github.com/eprints/eprints/issues/214 [ use of remote_ip ]
* https://github.com/eprints/eprints/issues/237 [ NameVirtualHost deprecated ]
* https://github.com/eprints/eprints/issues/236 [ Order allow,deny deprecated ]
* https://github.com/eprints/eprints/commit/157db0d27d423d38f9c0fc31ce47e519cd861d45 [ utf8::decode and URI parameters ]

Kieker

2014-06-02T16:00:15Z

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

This page describes what Kieker is and how to integrate it with EPrints (tested on v3.3). The Kieker framework is developed and maintained at the University of Kiel in Germany and it is a neat tool for analysing a system whether in development or in production.

==What is Kieker==

Concretely Kieker allows you to profile and to monitor all the internal module calls (to EPrints). Any functions called will be trapped and sent to a queue for further processing.

Kieker comes with many post-processing graphs and diagrams to see, for instance, all the calls made, the execution times, etc. This then allows you to have a global picture of the EPrints' internals in order to e.g. optimise certain parts of the system, find coupled modules, detect un-wanted loops (between modules) etc.

Read more about it here: http://kieker-monitoring.net/

==How does it work?==

For EPrints, Kieker uses a PERL module called Sub::WrapPackages which basically allows user to define global wrappers for internal calls. It is possible to restrict which modules are wrapped: for instance, you may want to only profile the database layer, in which case you probably want to wrap EPrints::Database and EPrints::Database::MySQL. The EPrints/Kieker extensions (https://github.com/eprints/epkieker) make it easy to set this up.

When Kieker is enabled it will trap any selected internal calls and will send some information to a queueing system. The data sent will contain a high-precision timestamp, the name of the module, of the function etc. Traditionally Kieker uses JMS as a queueing system but we integrated it with memcached which is a popular, easy-to-install server-wide caching system.

Once you're happy with the profiling, you can disable kieker and retrieve the data from the queue. Then you may use Kieker's built-in tools to generate all sorts of graphs.

==Installation==

===Kieker===

We used Kieker v1.9 during our tests. You may get it from: http://kieker-monitoring.net/download/

Note that Kieker requires Java (but this can easily be installed under Ubuntu).

===Required modules===

If you're using Ubuntu, you can install the modules as follow:

sudo apt-get install libclass-accessor-perl libnet-stomp-perl libdevel-caller-ignorenamespaces-perl libsub-install-perl libparams-util-perl libdata-optlist-perl libsub-exporter-perl libsub-prototype-perl libsub-wrappackages-perl

If you'd rather install them via CPAN, the above packages' name are:

* Class::Accessor
* Net::Stomp
* Devel::Caller::IgnoreNamespaces
* Sub::Install
* Params::Util
* Data::OptList
* Sub::Exporter
* Sub::Prototype
* Sub::WrapPackages

You must also install memcached, if not already present on your server:

sudo apt-get install memcached libcache-memcached-fast-perl

===EPrints/Kieker extensions===

You need to copy a few modules from https://github.com/eprints/epkieker to finalise the installation of Kieker, to run with EPrints.

If EPrints is install under its default path /opt/eprints3 (otherwise adjust the paths):

cp -rf perl_lib/Kieker* /opt/eprints3/perl_lib
cp perl_lib/EPrints/Apache/KiekerHandler.pm /opt/eprints3/perl_lib/EPrints/Apache
cp -rf bin/kieker /opt/eprints3/archives/<id>/bin/

And you're done.

===Configuration===

There are only a few options you need to edit to configure Kieker, which are in /opt/eprints3/perl_lib/EPrints/Apache/KiekerHandler.pm.

Any time you make a configuration change, you must restart Apache.

====Monitored URI====

This option allows you to restrict the URI which will capture profiling data. For instance, if you have a problem with searching, you may want to set this to "/cgi/search". To do the same with the browse views, use "/view/".

Some examples:

my $MONIT_URI = "/"; # monitors "/" ie. /index.html
my $MONIT_URI = /cgi/search"; # monitors the search
my $MONIT_URI = "/view/year/"; # monitors the browse view "by year"
my $MONIT_URI = "/cgi/users/home"; # monitors the user (logged-in) area

====Monitored IP====

It can be dangerous to allow monitoring for any clients using your repository (if using Kieker on a production server). This will slow down the system for everyone, as well as generating lots of useless data.

This option is there to restrict which IP address enables monitoring. At the moment it can only be a single IP address, you cannot specify network blocks. If you want to monitor EPrints then this should probably be set to your IP (v4) address.

Example:

my $MONIT_URI = "124.3.45.7";

====Monitored Packages====

Remember I told you that, with PERL, Kieker wraps any modules? Well this last option allows you to specify which modules will be wrapped hence which modules will be monitored. Anything outside of the selected scope will not be monitored and will not generate any data.

Some common examples:

my $MONIT_PACKAGES = "EPrints EPrints::*"; # any EPrints call
my $MONIT_PACKAGES = "EPrints::Database EPrints::Database::*"; # anything relating to EPrints' Database layer
my $MONIT_PACKAGES = "EPrints::Plugin::Screen::Items;" # the "Manage deposits" page
my $MONIT_PACKAGES = "EPrints::MetaField::* EPrints::XML;" # EPrints' metafield layer, in relation to the XML module

===Enabling/Disabling Kieker===

Typically EPrints tells Apache that it handles *any* web requests for a given virtual host (the URL of your repository).

The line responsible for this delegation is inside /opt/eprints3/cfg/apache/<id>.conf:

PerlTransHandler +EPrints::Apache::Rewrite

We just need to set this to the Kieker handler to enable Kieker:

PerlTransHandler +EPrints::Apache::KiekerPerlHandler

Restart Apache and you are done. To disable Kieker, do the opposite.

==Monitoring cycles==

Say that you notice a slow-down when visiting a certain page on EPrints and you would like to investigate what could be the cause(s) and what could be optimised. Kieker is good at showing undesired coupling between modules and is also very good at showing "slowest paths" (when executing a web request from A to Z you can easily spot which method call(s) is/are the slowest - this could be long DB query, lots of files reads, ETC.).

The standard cycle when using Kieker is to:

* Enable Kieker on the URI you think is problematic, for your IP address only
* Restart Apache
* Go to the URI with your browser: this may be slower than usual, because Kieker is generating lots of data
* Disable Kieker
* Restart Apache
* Dequeue the Kieker monitoring data from memcached
* Use Kieker's shipped-in modules to generate releavant graphs for your analysis.

Once you start using Kieker, you will see that you can get results and graphs very, very quickly.

==Processing Data==

As said earlier, once enabled, Kieker will send its data to memcached. To process the data you will need to dequeue the data from memcached by simply using the supplied script.

mkdir -p ~/kieker/logs/
mkdir -p ~/kieker/logs/out/
cd ~/kieker/logs/
perl /opt/eprints3/archives/<id>/bin/kieker/dequeue_memcached.pl

And that's it! The PERL script will create all necessary files in the current directory. You can then feed the directory to Kieker's built-in tools.

For example:

~/kieker-1.9/bin/trace-analysis.sh -i ~/kieker/logs -o ~/kieker/logs/out/ --plot-Assembly-Component-Dependency-Graph --plot-Aggregated-Deployment-Call-Tree --plot-Container-Dependency-Graph --plot-Assembly-Operation-Dependency-Graph responseTimes responseTimeColoring 20

This will generate four different graphs in the ".dot" format. Kieker can generate other graphs, look at the available options by running ~/kieker-1.9/bin/trace-analysis.sh without any parameters.

".dot" files can be converted to SVG (then PDF), to JPEG etc using the xdot linux library (readily available via apt-get on Ubuntu) for instance:

dot -T jpeg -o assembly-graph.jpg assemblyComponentDependencyGraph.dot

You can turn SVG files into PDF by using the free tool "inkscape" which may be invoked from the command-line.

==Notes==

* In order to avoid LOTS of warnings in the Apache's error logs, we are using a shipped-in module called Sub::WrapEPrints instead of Sub::WrapPackages.
* memcached can be set-up on a remote server - this is actually a standard feature of memcached. You could then monitor one server and store the monitoring data on another machine.

Kieker

2014-06-02T15:58:49Z

Sf03r@ecs.soton.ac.uk:

Kieker

2014-06-02T15:55:23Z

Sf03r@ecs.soton.ac.uk: /* Processing Data */

Kieker

2014-06-02T15:38:28Z

Sf03r@ecs.soton.ac.uk:

Kieker

2014-06-02T15:23:17Z

Sf03r@ecs.soton.ac.uk: Created page with ' This page describes what Kieker is and how to integrate it with EPrints (tested on v3.3). The Kieker framework is developed and maintained at the University of Kiel in Germany a…'

EPrints4 CORE

2014-05-23T16:33:47Z

Sf03r@ecs.soton.ac.uk:

Packages that are considered CORE in EPrints4 - this will form the "CORE API" that other extensions can build upon.

Note that this is not an official document and any information on this page should not be taken as the law.

* Core - core
** ACL.pm
** Apache.pm
** Apache/Auth.pm
** Apache/Conf.pm
** Apache/Handler.pm
** CLIProcessor.pm
** Config.pm
** Const.pm
** Database.pm
** Database/*
** DataObj.pm
** DataObj/*
** DataSet.pm
** Email.pm
** Index.pm
** Index/*
** Language.pm
** List.pm
** MetaField.pm
** MetaField/*
** NamedSet.pm
** Plugin.pm
** PluginFactory.pm
** RepositoryConfig.pm
** Repository.pm
** Storage.pm
** System.pm
** System/*
** SystemSettings.pm
** Test.pm
** Test/*
** Time.pm
** URL.pm
** Xapian.pm
** Xapian/*
** XML.pm
** XML/*

* Core - plugins
** Controller.pm
** Controller/*
** Convert.pm
** Event.pm
** Event/*
** Export.pm
** Export/*
** Import.pm
** Import/*
** Screen.pm
** Screen/*
** Storage.pm
** Storage/*

* Uncertain future

Not quite decided what will happen to the following former core modules. Note that plenty of modules have been removed already.

** Page.pm
** Page/*
** Probity.pm
** ScreenProcessor.pm
** Script.pm
** Script/*
** Search.pm
** Search/*
** Sword/*
** Update/*
** Utils.pm
** XHTML.pm

EPrints4 CORE

2014-05-23T16:33:30Z

Sf03r@ecs.soton.ac.uk:

Packages that are considered CORE in EPrints4 - this will form the "CORE API" that other extensions can build upon.

Note that this is not an official document and any information on this page should not be taken as the law.

* Core - core

** ACL.pm
** Apache.pm
** Apache/Auth.pm
** Apache/Conf.pm
** Apache/Handler.pm
** CLIProcessor.pm
** Config.pm
** Const.pm
** Database.pm
** Database/*
** DataObj.pm
** DataObj/*
** DataSet.pm
** Email.pm
** Index.pm
** Index/*
** Language.pm
** List.pm
** MetaField.pm
** MetaField/*
** NamedSet.pm
** Plugin.pm
** PluginFactory.pm
** RepositoryConfig.pm
** Repository.pm
** Storage.pm
** System.pm
** System/*
** SystemSettings.pm
** Test.pm
** Test/*
** Time.pm
** URL.pm
** Xapian.pm
** Xapian/*
** XML.pm
** XML/*

* Core - plugins

** Controller.pm
** Controller/*
** Convert.pm
** Event.pm
** Event/*
** Export.pm
** Export/*
** Import.pm
** Import/*
** Screen.pm
** Screen/*
** Storage.pm
** Storage/*

* Uncertain future

Not quite decided what will happen to the following former core modules. Note that plenty of modules have been removed already.

** Page.pm
** Page/*
** Probity.pm
** ScreenProcessor.pm
** Script.pm
** Script/*
** Search.pm
** Search/*
** Sword/*
** Update/*
** Utils.pm
** XHTML.pm

EPrints4 CORE

2014-05-23T14:26:34Z

Sf03r@ecs.soton.ac.uk: Created page with 'Packages that are considered CORE in EPrints4 - this will form the "CORE API" that other extensions can build upon. Note that this is not an official document and any informatio…'

EPrints4 Status

2014-05-23T14:19:31Z

Sf03r@ecs.soton.ac.uk:

Packages that are considered "CORE": [[EPrints4_CORE]]

Things which have been tested / implemented:

=CORE=

==Database==

* Preferred MySQL engine is now InnoDB (over MyISAM)
* Added support for transactions with InnoDB. Partially written data/data-objects may be roll-backed (they are if an error occurs)
* Connects on demand

==Request handlers/routers==

* Every request is now routed via a trigger call (to find out which controller will respond)
* Apache::Rewrite has been refactored to Apache::Handler and is now super-lightweight
* Support for CGI scripts has been removed

==Controllers==

* CRUD
* Storage (delivery of files/thumbnails)
* Counter (like /cgi/counter)
* Ping (for fun, just replies 'pong')
* UI (for, potentially, Screen plug-ins)
* Static pages (XHTML, XPAGES etc that need compilation to HTML or any other static file (js, css...)

==Security==

* Based around actions (e.g. edit, view, search, ...) and optional contexts ('owner', etc.)
* Low-level implementation to avoid objects to leak from one dataset ('inbox') to another ('archive')
* ACL dataset (should maybe be called 'privs') to store extra privs against a user
* finer-grain permission (down to a single dataobj)

==Auth==

* Rewritten auth mechanisms
* Done similarly to Controllers, via a trigger
* When a user is auth'ed a user-session is created (cf. login ticket)
* When a request comes, EPrints attempts to load a user-session - cf. above
* Supports AuthBasic when no UI is available
* Cookies are managed transparently behind the "user-session"

==Storage==

* Added support for generic files. It is now possible to store any file against any object.
* Added support for "thumbnails" (as a separate dataset)

==CRUD==

* CRUD extended to support more methods/URI etc
* Sword2 hacks temporarily removed from CRUD
* Doesn't require its own auth code anymore
* CrudClient available to perform remote operation on a repository (via CrudDataSet, CrudDataObj, CrudList etc) - the API is very similar to the standard CLI syntax to create/edit/etc objects/lists of objects.
* Support for ETag and If-None-Match
* Support for PATCH method
* Support for generic file upload
* Minimal support for searching a dataset (e.g. GET /data/user/) - though will probably have a separate /search/... interface to allow user queries (Xapian and the likes)
* Entry poing /id/... moved to /data/...

==Dataset definition==

* The following properties are now core (meaning that EPrints will automatically add appropriate fields, set/update/remove data when such or such properties are enabled):
** flow: replaces eprint_status and the likes. Allows to specify a flow of states and transitions
** revision: adds a revision number, incremented each time the data obj is modified
** acl (TO RENAME): allows ACL checks on the dataset (should always be ON)
** read-only: make the dataset read-only, no modifications are allowed via the API (whether HTTP, CLI ...)
** web-read-only (TOFIX): make the dataset read-only ONLY for HTTP requests - CLI scripts can still change data
** history (TODO): keeps an historic of changes
** lastmod: keeps a timestamp of when the data-obj was last modified
** datestamp: keeps the date of creation of a data-obj
** loghandler (TODO): keeps download stats for that dataset
** contexts: allows to add custom security contexts (eg. 'owner', 'editor', 'co-author')

==Misc==

* memcached: use of server-wide "memcached" service to memory cache data objects
* contextual debugging: allows to enable/disable only specific themes e.g. "db", "security" etc. and only write status messages to the logs for the enabled themes
* much, much more!

=UI=

* Template using Bootstrap
* Data-binding with JS Framework AngularJS
* Dynamical pages served through light-weight Screen plug-ins (only handles the security aspect - who can see this page - and the "page's actions" via AJAX)

EPrints4 Roadmap

2014-05-21T15:23:17Z

Sf03r@ecs.soton.ac.uk:

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

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

* 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

EPrints4 Status

2014-03-25T14:07:33Z

Sf03r@ecs.soton.ac.uk:

Things which have been tested / implemented:

=CORE=

==Database==

* Preferred MySQL engine is now InnoDB (over MyISAM)
* Added support for transactions with InnoDB. Partially written data/data-objects may be roll-backed (they are if an error occurs)
* Connects on demand

==Request handlers/routers==

* Every request is now routed via a trigger call (to find out which controller will respond)
* Apache::Rewrite has been refactored to Apache::Handler and is now super-lightweight
* Support for CGI scripts has been removed

==Controllers==

* CRUD
* Storage (delivery of files/thumbnails)
* Counter (like /cgi/counter)
* Ping (for fun, just replies 'pong')
* UI (for, potentially, Screen plug-ins)
* Static pages (XHTML, XPAGES etc that need compilation to HTML or any other static file (js, css...)

==Security==

* Based around actions (e.g. edit, view, search, ...) and optional contexts ('owner', etc.)
* Low-level implementation to avoid objects to leak from one dataset ('inbox') to another ('archive')
* ACL dataset (should maybe be called 'privs') to store extra privs against a user
* finer-grain permission (down to a single dataobj)

==Auth==

* Rewritten auth mechanisms
* Done similarly to Controllers, via a trigger
* When a user is auth'ed a user-session is created (cf. login ticket)
* When a request comes, EPrints attempts to load a user-session - cf. above
* Supports AuthBasic when no UI is available
* Cookies are managed transparently behind the "user-session"

==Storage==

* Added support for generic files. It is now possible to store any file against any object.
* Added support for "thumbnails" (as a separate dataset)

==CRUD==

* CRUD extended to support more methods/URI etc
* Sword2 hacks temporarily removed from CRUD
* Doesn't require its own auth code anymore
* CrudClient available to perform remote operation on a repository (via CrudDataSet, CrudDataObj, CrudList etc) - the API is very similar to the standard CLI syntax to create/edit/etc objects/lists of objects.
* Support for ETag and If-None-Match
* Support for PATCH method
* Support for generic file upload
* Minimal support for searching a dataset (e.g. GET /data/user/) - though will probably have a separate /search/... interface to allow user queries (Xapian and the likes)
* Entry poing /id/... moved to /data/...

==Dataset definition==

* The following properties are now core (meaning that EPrints will automatically add appropriate fields, set/update/remove data when such or such properties are enabled):
** flow: replaces eprint_status and the likes. Allows to specify a flow of states and transitions
** revision: adds a revision number, incremented each time the data obj is modified
** acl (TO RENAME): allows ACL checks on the dataset (should always be ON)
** read-only: make the dataset read-only, no modifications are allowed via the API (whether HTTP, CLI ...)
** web-read-only (TOFIX): make the dataset read-only ONLY for HTTP requests - CLI scripts can still change data
** history (TODO): keeps an historic of changes
** lastmod: keeps a timestamp of when the data-obj was last modified
** datestamp: keeps the date of creation of a data-obj
** loghandler (TODO): keeps download stats for that dataset
** contexts: allows to add custom security contexts (eg. 'owner', 'editor', 'co-author')

==Misc==

* memcached: use of server-wide "memcached" service to memory cache data objects
* contextual debugging: allows to enable/disable only specific themes e.g. "db", "security" etc. and only write status messages to the logs for the enabled themes
* much, much more!

=UI=

* Template using Bootstrap
* Data-binding with JS Framework AngularJS
* Dynamical pages served through light-weight Screen plug-ins (only handles the security aspect - who can see this page - and the "page's actions" via AJAX)

EPrints4 Status

2014-03-25T13:39:56Z

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

EPrints4 Status

2014-03-24T17:19:35Z

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

Things which have been tested / implemented:

=CORE=

==Database==

* Preferred MySQL engine is now InnoDB (over MyISAM)
* Added support for transactions with InnoDB. Partially written data/data-objects may be roll-backed (they are if an error occurs)

==Request handlers/routers==

* Every request is now routed via a trigger call (to find out which controller will respond)
* Apache::Rewrite has been refactored to Apache::Handler and is now super-lightweight
* Support for CGI scripts has been removed

==Controllers==

* CRUD
* Storage (delivery of files/thumbnails)
* Counter (like /cgi/counter)
* Ping (for fun, just replies 'pong')
* UI (for, potentially, Screen plug-ins)
* Static pages (XHTML, XPAGES etc that need compilation to HTML or any other static file (js, css...)

==Security==

* Based around actions (e.g. edit, view, search, ...) and optional contexts ('owner', etc.)
* Low-level implementation to avoid objects to leak from one dataset ('inbox') to another ('archive')
* ACL dataset (should maybe be called 'privs') to store extra privs against a user
* finer-grain permission (down to a single dataobj)

==Auth==

* Rewritten auth mechanisms
* Done similarly to Controllers, via a trigger
* When a user is auth'ed a user-session is created (cf. login ticket)
* When a request comes, EPrints attempts to load a user-session - cf. above
* Supports AuthBasic when no UI is available
* Cookies are managed transparently behind the "user-session"

==Storage==

* Added support for generic files. It is now possible to store any file against any object.
* Added support for "thumbnails" (as a separate dataset)

==CRUD==

* CRUD extended to support more methods/URI etc
* Sword2 hacks temporarily removed from CRUD
* Doesn't require its own auth code anymore
* CrudClient available to perform remote operation on a repository (via CrudDataSet, CrudDataObj, CrudList etc) - the API is very similar to the standard CLI syntax to create/edit/etc objects/lists of objects.
* Support for ETag and If-None-Match
* Support for PATCH method
* Support for generic file upload
* Minimal support for searching a dataset (e.g. GET /data/user/) - though will probably have a separate /search/... interface to allow user queries (Xapian and the likes)
* Entry poing /id/... moved to /data/...

==Dataset definition==

* The following properties are now core (meaning that EPrints will automatically add appropriate fields, set/update/remove data when such or such properties are enabled):
** flow: replaces eprint_status and the likes. Allows to specify a flow of states and transitions
** revision: adds a revision number, incremented each time the data obj is modified
** acl (TO RENAME): allows ACL checks on the dataset (should always be ON)
** read-only: make the dataset read-only, no modifications are allowed via the API (whether HTTP, CLI ...)
** web-read-only (TOFIX): make the dataset read-only ONLY for HTTP requests - CLI scripts can still change data
** history (TODO): keeps an historic of changes
** lastmod: keeps a timestamp of when the data-obj was last modified
** datestamp: keeps the date of creation of a data-obj
** loghandler (TODO): keeps download stats for that dataset
** contexts: allows to add custom security contexts (eg. 'owner', 'editor', 'co-author')

==Misc==

* memcached: use of server-wide "memcached" service to memory cache data objects
* contextual debugging: allows to enable/disable only specific themes e.g. "db", "security" etc. and only write status messages to the logs for the enabled themes
* much, much more!

EPrints4 Status

2014-03-24T17:18:33Z

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

Things which have been tested / implemented:

=CORE=

==Database==

* Preferred MySQL engine is now InnoDB (over MyISAM)
* Added support for transactions with InnoDB. Partially written data/data-objects may be roll-backed (they are if an error occurs)

==Request handlers/routers==

* Every request is now routed via a trigger call (to find out which controller will respond)
* Apache::Rewrite has been refactored to Apache::Handler and is now super-lightweight
* Support for CGI scripts has been removed

==Controllers==

* CRUD
* Storage (delivery of files/thumbnails)
* Counter (like /cgi/counter)
* Ping (for fun, just replies 'pong')
* UI (for, potentially, Screen plug-ins)
* Static pages (XHTML, XPAGES etc that need compilation to HTML or any other static file (js, css...)

==Security==

* Based around actions (e.g. edit, view, search, ...) and optional contexts ('owner', etc.)
* Low-level implementation to avoid objects to leak from one dataset ('inbox') to another ('archive')
* ACL dataset (should maybe be called 'privs') to store extra privs against a user
* finer-grain permission (down to a single dataobj)

==Auth==

* Rewritten auth mechanisms
* Done similarly to Controllers, via a trigger
* When a user is auth'ed a user-session is created (cf. login ticket)
* When a request comes, EPrints attempts to load a user-session - cf. above
* Supports AuthBasic when no UI is available
* Cookies are managed transparently behind the "user-session"

==Storage==

* Added support for generic files. It is now possible to store any file against any object.
* Added support for "thumbnails" (as a separate dataset)

==CRUD==

* CRUD extended to support more methods/URI etc
* Sword2 hacks temporarily removed from CRUD
* Doesn't require its own auth code anymore
* CrudClient available to perform remote operation on a repository (via CrudDataSet, CrudDataObj, CrudList etc) - the API is very similar to the standard CLI syntax to create/edit/etc objects/lists of objects.
* Support for ETag and If-None-Match
* Support for PATCH method
* Support for generic file upload
* Minimal support for searching a dataset (e.g. GET /data/user/) - though will probably have a separate /search/... interface to allow user queries (Xapian and the likes)
* Entry poing /id/... moved to /data/...

==Dataset definition==

* The following properties are now core (meaning that EPrints will automatically add appropriate fields, set/update/remove data when such or such properties are enabled):
** flow: replaces eprint_status and the likes. Allows to specify a flow of states and transitions
** revision: adds a revision number, incremented each time the data obj is modified
** acl (TO RENAME): allows ACL checks on the dataset (should always be ON)
** read-only: make the dataset read-only, no modifications are allowed via the API (whether HTTP, CLI ...)
** web-read-only (TOFIX): make the dataset read-only ONLY for HTTP requests - CLI scripts can still change data
** history (TODO): keeps an historic of changes
** lastmod: keeps a timestamp of when the data-obj was last modified
** datestamp: keeps the date of creation of a data-obj
** loghandler (TODO): keeps download stats for that dataset
** contexts: allows to add custom security contexts (eg. 'owner', 'editor', 'co-author')

==Nisc==

* memcached: use of server-wide "memcached" service to memory cache data objects
* contextual debugging: allows to enable/disable only specific themes e.g. "db", "security" etc. and only write status messages to the logs for the enabled themes
* much, much more!

EPrints4 Status

2014-03-24T17:18:10Z

Sf03r@ecs.soton.ac.uk: Created page with 'Things which have been tested / implemented: =CORE= ==Database== * Preferred MySQL engine is now InnoDB (over MyISAM) * Added support for transactions with InnoDB. Partially c…'

Things which have been tested / implemented:

=CORE=

==Database==

* Preferred MySQL engine is now InnoDB (over MyISAM)
* Added support for transactions with InnoDB. Partially committed data/data-objects may be roll-backed (they are if an error occurs)

==Request handlers/routers==

* Every request is now routed via a trigger call (to find out which controller will respond)
* Apache::Rewrite has been refactored to Apache::Handler and is now super-lightweight
* Support for CGI scripts has been removed

==Controllers==

* CRUD
* Storage (delivery of files/thumbnails)
* Counter (like /cgi/counter)
* Ping (for fun, just replies 'pong')
* UI (for, potentially, Screen plug-ins)
* Static pages (XHTML, XPAGES etc that need compilation to HTML or any other static file (js, css...)

==Security==

* Based around actions (e.g. edit, view, search, ...) and optional contexts ('owner', etc.)
* Low-level implementation to avoid objects to leak from one dataset ('inbox') to another ('archive')
* ACL dataset (should maybe be called 'privs') to store extra privs against a user
* finer-grain permission (down to a single dataobj)

==Auth==

* Rewritten auth mechanisms
* Done similarly to Controllers, via a trigger
* When a user is auth'ed a user-session is created (cf. login ticket)
* When a request comes, EPrints attempts to load a user-session - cf. above
* Supports AuthBasic when no UI is available
* Cookies are managed transparently behind the "user-session"

==Storage==

* Added support for generic files. It is now possible to store any file against any object.
* Added support for "thumbnails" (as a separate dataset)

==CRUD==

* CRUD extended to support more methods/URI etc
* Sword2 hacks temporarily removed from CRUD
* Doesn't require its own auth code anymore
* CrudClient available to perform remote operation on a repository (via CrudDataSet, CrudDataObj, CrudList etc) - the API is very similar to the standard CLI syntax to create/edit/etc objects/lists of objects.
* Support for ETag and If-None-Match
* Support for PATCH method
* Support for generic file upload
* Minimal support for searching a dataset (e.g. GET /data/user/) - though will probably have a separate /search/... interface to allow user queries (Xapian and the likes)
* Entry poing /id/... moved to /data/...

==Dataset definition==

* The following properties are now core (meaning that EPrints will automatically add appropriate fields, set/update/remove data when such or such properties are enabled):
** flow: replaces eprint_status and the likes. Allows to specify a flow of states and transitions
** revision: adds a revision number, incremented each time the data obj is modified
** acl (TO RENAME): allows ACL checks on the dataset (should always be ON)
** read-only: make the dataset read-only, no modifications are allowed via the API (whether HTTP, CLI ...)
** web-read-only (TOFIX): make the dataset read-only ONLY for HTTP requests - CLI scripts can still change data
** history (TODO): keeps an historic of changes
** lastmod: keeps a timestamp of when the data-obj was last modified
** datestamp: keeps the date of creation of a data-obj
** loghandler (TODO): keeps download stats for that dataset
** contexts: allows to add custom security contexts (eg. 'owner', 'editor', 'co-author')

==Nisc==

* memcached: use of server-wide "memcached" service to memory cache data objects
* contextual debugging: allows to enable/disable only specific themes e.g. "db", "security" etc. and only write status messages to the logs for the enabled themes
* much, much more!

EPrints4 Roadmap

2014-03-24T16:53:29Z

Sf03r@ecs.soton.ac.uk:

EPrints4 Roadmap

2014-03-24T16:52:32Z

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

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

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

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

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

EPrints4 Roadmap

2014-03-24T16:51:08Z

Sf03r@ecs.soton.ac.uk:

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

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

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

* 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

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

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

MePrints

2014-03-12T13:05:31Z

Sf03r@ecs.soton.ac.uk:

[[Category:MePrints]]
All About MEPrints is a JISC rapid innovations project to build a user profile system for EPrints. The aim is that every repository user will have a page which promotes their work and identity within the repository and beyond. It is hoped this will improve user-to-repository relations and also provide useful information for user-to-user interactions.

The extension we have developed is called MePrints. This page gives an overview of the features of the MePrints extension.

For technical instructions on how to install MePrints, see [[MePrintsInstall]].

=Introduction=

MePrints is a plugin for EPrints 3.1+ that extends the user aspect of EPrints with user profiles and homepages. Profile pages are public-facing pages providing, admin-customisable, information ''about'' the user. Homepages replace the current EPrints "Profile" page and provide, admin and user-customisable, information from the repository so that the user can get a quick overview of anything that is relevant to them.

The hope is that MePrints functionality will find it's way into the EPrints 3.2 trunk so that it is available to use with a new install of EPrints.

=Features=

MePrints brings a number of additional features to EPrints to improve your user experience with EPrints.

==Profile Pages==
[[Image:MePrints User Profile Thumb.png|frame|right|||An example MePrints User Profile||This image shows an example MePrints User Profile.]]

Public user profile pages provide a static view of data that describes you as a repository user. The information that is displayed on these pages is configurable by the repository administrator. If you do not want your profile page to be accessible to the outside world then you can set your profile to be hidden so that it is not visible to anyone. Profiles also have a search engine friendly URL assigned to them as well in the form <nowiki>http://repository.org/profile/username</nowiki>. This allows you to easily share their EPrints profile with other people.

Profile pages include the following information;
* Name
* Expertise
* Qualifications
* Divisions
* Biography
* User Image

<div style="clear: both;"></div>

==Homepages==
[[Image:MePrints Homepage Thumb.png|frame|right|||An example MePrints User Homepage||This image shows a screenshot of an example MePrints User Homepage.]]

This replaces the initial "Manage Deposits" view that you see when they first login. The "Manage Deposits" view is still available although it is now accessible through the link at the top of the page.

This page is highly customisable for both the repository administrator and you. A repository administrator can create [[#Widgets|widgets]], which are a special type of plugin that provide information from the repository that is relevant to you. Also the administrator can create different layouts for the homepage so that [[#Widgets|widgets]] on the page will be laid out in different ways. You can then choose the layout that you prefer from a number of available layouts if your repository administrator has made several available for use.

You can further customise your homepage by changing the positions of the widgets and adding or removing [[#Widgets|widgets]] that the repository administrator has installed.

<div style="clear: both;"></div>

==Widgets==
Widgets appear both on your profile and your homepage. The widgets that appear on your profile are managed by the repository administrator while on your homepage you have a degree of control over what widgets appear, from the collection of available widgets, and where on the page they appear.

Widgets available by default with MePrints include;
* User Details - Shows the username, biography, expertise and other core data fields.
* User Picture - Allows the user to upload an image of themselves for their profile.
* User Actions - Adds a box containing all of the possible user actions.
* Recently Published Items - Shows items that the user has recently published in the repository.
* Item Issues - Shows any issues with items, owned by the user, that have been discovered by an issues audit.
* Quick Upload - Allows the user to upload a file and attach it to a new record in their inbox, ready for publication on the repository later.
* Most Popular Items - Looks at the number of times a users items have been accessed and displays a rundown of the most popular.
* IRStats Mini Dashboard - If the repository has IRStats installed this widget can display data from it and allow the user to look at a number of different statistics regarding their publications.

This list may differ for you if your repository administrator has disabled or added any widgets.

==Searching For Users==
MePrints makes it possible for you to search through all of the users who have made their profiles public. If you make your profile private and don't allow anyone to see it then it will not be included in any search results as well as not allowing anyone to view it.

===Browsing For Users By Expertise===
A new browse view has been added with MePrints that allows you to browse for users by expertise.

===User Search Page===
There is a new user search provided by MePrints, cgi/search_users, which allows you to search through users in the EPrints repository.

=Installation=
MePrints can be installed on EPrints 3.3 from the Bazaar with a one-click install.

For older versions of MePrints/EPrints see: Installation of MePrints on an existing EPrints 3.1 repository has been designed to be a simple as possible. Full instructions for installation can be found at [[MePrintsInstall]].

[http://creativecommons.org/licenses/by/3.0/ This work is licensed under a Creative Commons Attribution 3.0 Unported License].

=Changelog=

==v1.4.3==

Released on 16th September 2013 by sf2

* Added missing user citation "details"
* Added new user citation "profile" to control the look and feel of the (external) profile page
* Removed calls to deprecated functions (EPrints 3.3+)
* Added missing timestamp file to allow regeneration of profile pages from the Admin UI
* Added missing Admin screen plug-in to allow regen. of profile pages
* Disabled user searches and user browse views by default
* Fixed the user setting their profile visibility to "public" / "private" and is now working
* Added missing CGI script "save" to save the position of the homepage's widgets
* Added possibility to define locally-defined sizes of the profile pictures
* Added missing triggers to allow regen of the profile pages when the user's metadata has changed

MePrintsInstall

2014-03-12T12:52:33Z

Sf03r@ecs.soton.ac.uk:

'''WARNING: THIS PAGE IS OUT-OF-DATE. MePrints is available from the Bazaar as a one-click install'''

<nowiki></nowiki>

[[Category:MePrints]]
This page provides technical instructions for installing the MePrints extension. To find out what MePrints is, and for an overview of MePrints features, see [[MePrintsOverview]].

==Installation (EPrints 3.1.3+)==

Download the latest release to your '''local repository directory''' (eg. /opt/eprints3/archives/ARCHIVEID/).

Extract files:

tar xzvf meprints_xx.tgz

===Install bin scripts===

Edit the bin/generate_meprints file and check the include path on the first line. For example if you have installed EPrints in /var/lib/eprints3 change the line from:

#!/usr/bin/perl -w -I/opt/eprints3/perl_lib

to:

#!/usr/bin/perl -w -I/var/lib/eprints3/perl_lib

===Install cgi scripts===

Link the MePrints cgi scripts into the EPrints cgi directory:

ln -s /opt/eprints3/archives/ARCHIVEID/cgi/meprints/ /opt/eprints3/cgi/
ln -s /opt/eprints3/archives/ARCHIVEID/cgi/users/meprints/ /opt/eprints3/cgi/users/

===Update database===

Add the new MePrints user fields (defined in cfg/cfg.d/z_meprints.pl) to your repository database:

cd /opt/eprints3/
bin/epadmin update_database_structure ARCHIVEID --verbose

===Apply MePrints patches===

Apply the MePrints patch files:

cd /opt/eprints3
patch -R -p0 < archives/ARCHIVE_ID/meprints_1.0.patch

DO NOT APPLY THIS FOLLOWING PATCH ON EPrints 3.2, it is not required;

patch -R -p0 < archives/ARCHIVE_ID/meprints_dataset.patch #YOU DONT NEED THIS ON 3.2 trying it might break your install

These patches change two core EPrints modules:

# Update/Views.pm - allow view pages to be generated for any dataset (MePrints adds views over the public_profile_users dataset)
# DataSet.pm - add a new dataset called public_profile_users which is the set of all users who have opted to make their public profile page visible.

==Getting Started==

To activate MePrints, you will need to make some changes to your repository setup.

===cfg/cfg.d/plugins.pl===
You can skip this step on MePrints 1.3 and later.

Add the following lines to your cfg/cfg.d/plugins.pl configuration file: to use the MePrints homepage instead instead of the default EPrints "Profile" page:

$c->{plugins}->{"Screen::User::View"}->{appears}->{key_tools} = undef;
$c->{plugin_alias_map}->{"Screen::User::View"} = "Screen::User::Homepage";

===cfg/cfg.d/user_fields_automatic.pl===

Add the following lines to your cfg/cfg.d/user_fields_automatic.pl configuration file to update the MePrints public profile page automatically when a user changes his or her profile information,

<pre>
$c->{user_fields_automatic} = sub {

my $user = @_;

...

if( defined $user->{changed} )
{
$user->remove_static();
}

};
</pre>

===cfg/cfg.d/eprint_fields_automatic.pl===

Add the following line to your cfg/cfg.d/eprint_fields_automatic.pl configuration file so that the MePrints public profile page automatically changes when an EPrint they have deposited is updated.

$eprint->get_user->remove_static;

===cfg/cfg.d/urls.pl===

To activate the canonical profile URLs, add "/profile/" to the rewrite_exceptions list in your cfg/cfg.d/urls.pl configuration file:

<pre>
$c->{rewrite_exceptions} = [ '/cgi/', '/archive/', '/profile/' ];
</pre>

===cfg/apachevhost.conf===

Add the following directives to your cfg/apachevhost.conf configuration file to enable canonical profile URLs (for example http://myrepository.com/profile/jsmith):

<pre>
<Location "/profile">
DefaultType 'text/html; charset=UTF-8'
SetHandler perl-script
PerlResponseHandler EPrints::Plugin::MePrints::MePrintsHandler
</Location>

</pre>

On eprints 3.2 and later you will now need to regenerated your apache conf:
<eprints_root>/bin/generate_apacheconf --replace <archiveid>

===cfg/workflows/user/default.xml===

Add the following lines to your cfg/workflows/user/default.xml configuration file:

<stage name="default">
...

<component type="Field::Multi">
<title><epc:phrase ref="user_section_personal" /></title>
...
</component>

<component type="Field::Multi">
<title><epc:phrase ref="user_section_meprints" /></title>
<field ref="profile_visibility" required="yes"/>
<field ref="jobtitle"/>
<field ref="expertise"/>
<field ref="biography"/>
<field ref="qualifications"/>
</component>

===cfg/citations/user/default.xml===

Replace the default EPrints user citation with the MePrints citation (which includes a thumbnail of the user's profile picture) run:

cd /opt/eprints3/archives/ARCHIVEID
cp cfg/citations/user/default_with_thumbnail.xml cfg/citations/user/default.xml

'''Note: if you have already made changes to the default citation, you should examine both files and merge the MePrints changes into default.xml

===Authorship in MePrints===
Meprints 1.1 and later change the definition of ownership in the respository. This means that users who have the same email address as that listed in an items creators field belong to that user once the item enters the archive. This allows users to see statistics about papers they have authored without have to upload their own copy of the paper. You can return this to the eprints default by removing the cfg/cfg.d/authorship_meprints.pl file

===Confirm Permissions===
The last thing to do before using MePrints is to ensure that the permissions are correct on the ''meprints'' directory. To do this run the following commands, there probably will not be any output from running this command;
cd archives/ARCHIVEID
chmod g+wx meprints

If the permissions are not correct then you may encounter errors when using MePrints.

==Testing==

After applying all the changes above, restart Apache to activate MePrints.

===Homepage===

Log into your repository and should see your MePrints Homepage with default widget layout and profile picture.

====Update profile====

Click the Modify Profile button and add some information to the new MePrints fields (Job Title, Expertise, Biography, Qualifications). Set your Profile Visibility to '''Public'''. Click the Save button to return to your Homepage where the information you entered should now be displayed.

====Upload photo====

Click the Profile Picture button, choose a file and click Upload. You will be returned to your Homepage where your picture will now be displayed.

====MePrints Widgets====

By default your homepage displays several widgets (see user_homepage_defaults setting in cfg/cfg.d/z_meprints.pl). Try adding and removing widgets using the widget controls at the bottom of the screen. You can also rearrange widgets by dragging them up/down or between columns. To reset to the default widget layout click the Reset button in the widget control bar.

===Public Profile===

Enter the following URL to view your public profile page:

http://myrepository.com/profile/USERNAME

where USERNAME is your EPrints username. The layout of the MePrints widgets on your profile page is controlled by the user_profile_defaults setting in cfg/cfg.d/z_meprints.pl.

Go back to your MePrints homepage and click Modify Profile. Change some of your profile information (eg. Job Title, Expertise, Biography, Qualifications) and click Save. Return to your public profile page and check that your profile information has been updated.

===MePrints Views===

Run:

bin/generate_views ARCHIVEID --generate menus

Check http://myrepository.com/view/ - you should see 2 new views (you may want to link these into your site template).

Explore the view pages and check that you are listed. Make sure that you can click through from the browse listing to your public profile page.

===MePrints search===

Go to: http://myrepository.com/cgi/meprints/search

Check that you can find your profile using keywords from your user profile information (eg. expertise, qualifications).

Make sure that you can click through from the search result list to your public profile page.

===MePrints Embeddable===

If you want to use the default minimal style supplied for MePrints Embeddable then add the following code to the ''<head>'' section of your page:
<link rel="stylesheet" type="text/css" href="http://myrepository.com/style/meprints_embed.css"/>

====MePrints Embeddable Widgets====
It is possible to embed individual widgets that are viewable on your public profile on your own page. If you go to the public profile page you will see an embed links on the widgets that can be embedded. Click the link and instructions will appear telling you how to embed the widget on your page.

====MePrints Embeddable Profile====
Edit an HTML page and add the following code to the ''<head>'' section of the page:

<script type="text/javascript" src="http://myrepository.com/cgi/meprints/embed_js?username=USERNAME"></script>

Where ''USERNAME'' is your username on the repository.

Then inside the ''<body>'' section of the page you need to add the following code:

<div id="meprints_profile"></div>

This will be the location where your embeddable profile will go on your page.

===MePrints for admins===

Using an administrator account go to the Admin screen and choose '''Search users'''. Enter a username or other criteria to find at least one user account (not the account you are logged in with).

Make sure that you can click through from the results list to the user's homepage.

You should be able to modify the user's profile information by clicking Administer Account.

The widget layout should reflect the user's own preference, and you should not be able to make changes to their widget layout.

====Hide Profile====

Change the user's profile visibility to '''private'''.

Log out, and make sure that:

# the profile is no longer visible at /profile/USERNAME
# the profile no longer appears in search results
# the profile no longer appears in view pages
# the embeddable widget no longer displays the profile

You can also change the default visibility of MePrints profiles in cfg/cfg.d/z_meprints.pl
by default profiles are public unless a user specifically makes there profile private. change
$c->{default_profile_behavior} = 1;
to
$c->{default_profile_behavior} = 0;
to make the default private profiles

==Troubleshooting==

===Database errors===

When dragging and dropping Widgets around, MePrints shows database errors in the error log:

DBD::mysql::st execute failed: Duplicate entry '1-0' for key 1 at /opt/eprints3/perl_lib/EPrints/Database.pm line 1192.
at /opt/eprints3/perl_lib/EPrints/Database.pm line 1192
EPrints::Database::insert('EPrints::Database::mysql=HASH(0x2b593e11ebd0)', 'user_items_fields', 'ARRAY(0x2b593bd00510)', ...

This is a known problem which does not seem to affect widget layout.

===generate_views errors===

====Warnings====

Use of uninitialized value $id in hash element at /usr/share/eprints3/perl_lib/EPrints/Database.pm line 2979.

See http://trac.eprints.org/trac/ticket/3537

====EPrint citations====

After hiding all previously public profiles, eprint citations were rendered in the view list instead of users'. (need to work out how to reproduce this)

====Empty views====

After hiding all previously public profiles and regenerating views, view pages still show expertise/department values.

[http://creativecommons.org/licenses/by/3.0/ This work is licensed under a Creative Commons Attribution 3.0 Unported License].

MePrintsInstall

2014-03-12T12:52:21Z

Sf03r@ecs.soton.ac.uk:

'''WARNING: THIS PAGE IS OUT-OF-DATE. MePrints is available from the Bazaar as a one-click install'''

<nowiki><div>bla</div></nowiki>

[[Category:MePrints]]
This page provides technical instructions for installing the MePrints extension. To find out what MePrints is, and for an overview of MePrints features, see [[MePrintsOverview]].

==Installation (EPrints 3.1.3+)==

Download the latest release to your '''local repository directory''' (eg. /opt/eprints3/archives/ARCHIVEID/).

Extract files:

tar xzvf meprints_xx.tgz

===Install bin scripts===

Edit the bin/generate_meprints file and check the include path on the first line. For example if you have installed EPrints in /var/lib/eprints3 change the line from:

#!/usr/bin/perl -w -I/opt/eprints3/perl_lib

to:

#!/usr/bin/perl -w -I/var/lib/eprints3/perl_lib

===Install cgi scripts===

Link the MePrints cgi scripts into the EPrints cgi directory:

ln -s /opt/eprints3/archives/ARCHIVEID/cgi/meprints/ /opt/eprints3/cgi/
ln -s /opt/eprints3/archives/ARCHIVEID/cgi/users/meprints/ /opt/eprints3/cgi/users/

===Update database===

Add the new MePrints user fields (defined in cfg/cfg.d/z_meprints.pl) to your repository database:

cd /opt/eprints3/
bin/epadmin update_database_structure ARCHIVEID --verbose

===Apply MePrints patches===

Apply the MePrints patch files:

cd /opt/eprints3
patch -R -p0 < archives/ARCHIVE_ID/meprints_1.0.patch

DO NOT APPLY THIS FOLLOWING PATCH ON EPrints 3.2, it is not required;

patch -R -p0 < archives/ARCHIVE_ID/meprints_dataset.patch #YOU DONT NEED THIS ON 3.2 trying it might break your install

These patches change two core EPrints modules:

# Update/Views.pm - allow view pages to be generated for any dataset (MePrints adds views over the public_profile_users dataset)
# DataSet.pm - add a new dataset called public_profile_users which is the set of all users who have opted to make their public profile page visible.

==Getting Started==

To activate MePrints, you will need to make some changes to your repository setup.

===cfg/cfg.d/plugins.pl===
You can skip this step on MePrints 1.3 and later.

Add the following lines to your cfg/cfg.d/plugins.pl configuration file: to use the MePrints homepage instead instead of the default EPrints "Profile" page:

$c->{plugins}->{"Screen::User::View"}->{appears}->{key_tools} = undef;
$c->{plugin_alias_map}->{"Screen::User::View"} = "Screen::User::Homepage";

===cfg/cfg.d/user_fields_automatic.pl===

Add the following lines to your cfg/cfg.d/user_fields_automatic.pl configuration file to update the MePrints public profile page automatically when a user changes his or her profile information,

<pre>
$c->{user_fields_automatic} = sub {

my $user = @_;

...

if( defined $user->{changed} )
{
$user->remove_static();
}

};
</pre>

===cfg/cfg.d/eprint_fields_automatic.pl===

Add the following line to your cfg/cfg.d/eprint_fields_automatic.pl configuration file so that the MePrints public profile page automatically changes when an EPrint they have deposited is updated.

$eprint->get_user->remove_static;

===cfg/cfg.d/urls.pl===

To activate the canonical profile URLs, add "/profile/" to the rewrite_exceptions list in your cfg/cfg.d/urls.pl configuration file:

<pre>
$c->{rewrite_exceptions} = [ '/cgi/', '/archive/', '/profile/' ];
</pre>

===cfg/apachevhost.conf===

Add the following directives to your cfg/apachevhost.conf configuration file to enable canonical profile URLs (for example http://myrepository.com/profile/jsmith):

<pre>
<Location "/profile">
DefaultType 'text/html; charset=UTF-8'
SetHandler perl-script
PerlResponseHandler EPrints::Plugin::MePrints::MePrintsHandler
</Location>

</pre>

On eprints 3.2 and later you will now need to regenerated your apache conf:
<eprints_root>/bin/generate_apacheconf --replace <archiveid>

===cfg/workflows/user/default.xml===

Add the following lines to your cfg/workflows/user/default.xml configuration file:

<stage name="default">
...

<component type="Field::Multi">
<title><epc:phrase ref="user_section_personal" /></title>
...
</component>

<component type="Field::Multi">
<title><epc:phrase ref="user_section_meprints" /></title>
<field ref="profile_visibility" required="yes"/>
<field ref="jobtitle"/>
<field ref="expertise"/>
<field ref="biography"/>
<field ref="qualifications"/>
</component>

===cfg/citations/user/default.xml===

Replace the default EPrints user citation with the MePrints citation (which includes a thumbnail of the user's profile picture) run:

cd /opt/eprints3/archives/ARCHIVEID
cp cfg/citations/user/default_with_thumbnail.xml cfg/citations/user/default.xml

'''Note: if you have already made changes to the default citation, you should examine both files and merge the MePrints changes into default.xml

===Authorship in MePrints===
Meprints 1.1 and later change the definition of ownership in the respository. This means that users who have the same email address as that listed in an items creators field belong to that user once the item enters the archive. This allows users to see statistics about papers they have authored without have to upload their own copy of the paper. You can return this to the eprints default by removing the cfg/cfg.d/authorship_meprints.pl file

===Confirm Permissions===
The last thing to do before using MePrints is to ensure that the permissions are correct on the ''meprints'' directory. To do this run the following commands, there probably will not be any output from running this command;
cd archives/ARCHIVEID
chmod g+wx meprints

If the permissions are not correct then you may encounter errors when using MePrints.

==Testing==

After applying all the changes above, restart Apache to activate MePrints.

===Homepage===

Log into your repository and should see your MePrints Homepage with default widget layout and profile picture.

====Update profile====

Click the Modify Profile button and add some information to the new MePrints fields (Job Title, Expertise, Biography, Qualifications). Set your Profile Visibility to '''Public'''. Click the Save button to return to your Homepage where the information you entered should now be displayed.

====Upload photo====

Click the Profile Picture button, choose a file and click Upload. You will be returned to your Homepage where your picture will now be displayed.

====MePrints Widgets====

By default your homepage displays several widgets (see user_homepage_defaults setting in cfg/cfg.d/z_meprints.pl). Try adding and removing widgets using the widget controls at the bottom of the screen. You can also rearrange widgets by dragging them up/down or between columns. To reset to the default widget layout click the Reset button in the widget control bar.

===Public Profile===

Enter the following URL to view your public profile page:

http://myrepository.com/profile/USERNAME

where USERNAME is your EPrints username. The layout of the MePrints widgets on your profile page is controlled by the user_profile_defaults setting in cfg/cfg.d/z_meprints.pl.

Go back to your MePrints homepage and click Modify Profile. Change some of your profile information (eg. Job Title, Expertise, Biography, Qualifications) and click Save. Return to your public profile page and check that your profile information has been updated.

===MePrints Views===

Run:

bin/generate_views ARCHIVEID --generate menus

Check http://myrepository.com/view/ - you should see 2 new views (you may want to link these into your site template).

Explore the view pages and check that you are listed. Make sure that you can click through from the browse listing to your public profile page.

===MePrints search===

Go to: http://myrepository.com/cgi/meprints/search

Check that you can find your profile using keywords from your user profile information (eg. expertise, qualifications).

Make sure that you can click through from the search result list to your public profile page.

===MePrints Embeddable===

If you want to use the default minimal style supplied for MePrints Embeddable then add the following code to the ''<head>'' section of your page:
<link rel="stylesheet" type="text/css" href="http://myrepository.com/style/meprints_embed.css"/>

====MePrints Embeddable Widgets====
It is possible to embed individual widgets that are viewable on your public profile on your own page. If you go to the public profile page you will see an embed links on the widgets that can be embedded. Click the link and instructions will appear telling you how to embed the widget on your page.

====MePrints Embeddable Profile====
Edit an HTML page and add the following code to the ''<head>'' section of the page:

<script type="text/javascript" src="http://myrepository.com/cgi/meprints/embed_js?username=USERNAME"></script>

Where ''USERNAME'' is your username on the repository.

Then inside the ''<body>'' section of the page you need to add the following code:

<div id="meprints_profile"></div>

This will be the location where your embeddable profile will go on your page.

===MePrints for admins===

Using an administrator account go to the Admin screen and choose '''Search users'''. Enter a username or other criteria to find at least one user account (not the account you are logged in with).

Make sure that you can click through from the results list to the user's homepage.

You should be able to modify the user's profile information by clicking Administer Account.

The widget layout should reflect the user's own preference, and you should not be able to make changes to their widget layout.

====Hide Profile====

Change the user's profile visibility to '''private'''.

Log out, and make sure that:

# the profile is no longer visible at /profile/USERNAME
# the profile no longer appears in search results
# the profile no longer appears in view pages
# the embeddable widget no longer displays the profile

You can also change the default visibility of MePrints profiles in cfg/cfg.d/z_meprints.pl
by default profiles are public unless a user specifically makes there profile private. change
$c->{default_profile_behavior} = 1;
to
$c->{default_profile_behavior} = 0;
to make the default private profiles

==Troubleshooting==

===Database errors===

When dragging and dropping Widgets around, MePrints shows database errors in the error log:

DBD::mysql::st execute failed: Duplicate entry '1-0' for key 1 at /opt/eprints3/perl_lib/EPrints/Database.pm line 1192.
at /opt/eprints3/perl_lib/EPrints/Database.pm line 1192
EPrints::Database::insert('EPrints::Database::mysql=HASH(0x2b593e11ebd0)', 'user_items_fields', 'ARRAY(0x2b593bd00510)', ...

This is a known problem which does not seem to affect widget layout.

===generate_views errors===

====Warnings====

Use of uninitialized value $id in hash element at /usr/share/eprints3/perl_lib/EPrints/Database.pm line 2979.

See http://trac.eprints.org/trac/ticket/3537

====EPrint citations====

After hiding all previously public profiles, eprint citations were rendered in the view list instead of users'. (need to work out how to reproduce this)

====Empty views====

After hiding all previously public profiles and regenerating views, view pages still show expertise/department values.

[http://creativecommons.org/licenses/by/3.0/ This work is licensed under a Creative Commons Attribution 3.0 Unported License].

MePrintsInstall

2014-03-12T12:51:23Z

Sf03r@ecs.soton.ac.uk:

'''WARNING: THIS PAGE IS OUT-OF-DATE. MePrints is available from the Bazaar as a one-click install'''

[[Category:MePrints]]
This page provides technical instructions for installing the MePrints extension. To find out what MePrints is, and for an overview of MePrints features, see [[MePrintsOverview]].

==Installation (EPrints 3.1.3+)==

Download the latest release to your '''local repository directory''' (eg. /opt/eprints3/archives/ARCHIVEID/).

Extract files:

tar xzvf meprints_xx.tgz

===Install bin scripts===

Edit the bin/generate_meprints file and check the include path on the first line. For example if you have installed EPrints in /var/lib/eprints3 change the line from:

#!/usr/bin/perl -w -I/opt/eprints3/perl_lib

to:

#!/usr/bin/perl -w -I/var/lib/eprints3/perl_lib

===Install cgi scripts===

Link the MePrints cgi scripts into the EPrints cgi directory:

ln -s /opt/eprints3/archives/ARCHIVEID/cgi/meprints/ /opt/eprints3/cgi/
ln -s /opt/eprints3/archives/ARCHIVEID/cgi/users/meprints/ /opt/eprints3/cgi/users/

===Update database===

Add the new MePrints user fields (defined in cfg/cfg.d/z_meprints.pl) to your repository database:

cd /opt/eprints3/
bin/epadmin update_database_structure ARCHIVEID --verbose

===Apply MePrints patches===

Apply the MePrints patch files:

cd /opt/eprints3
patch -R -p0 < archives/ARCHIVE_ID/meprints_1.0.patch

DO NOT APPLY THIS FOLLOWING PATCH ON EPrints 3.2, it is not required;

patch -R -p0 < archives/ARCHIVE_ID/meprints_dataset.patch #YOU DONT NEED THIS ON 3.2 trying it might break your install

These patches change two core EPrints modules:

# Update/Views.pm - allow view pages to be generated for any dataset (MePrints adds views over the public_profile_users dataset)
# DataSet.pm - add a new dataset called public_profile_users which is the set of all users who have opted to make their public profile page visible.

==Getting Started==

To activate MePrints, you will need to make some changes to your repository setup.

===cfg/cfg.d/plugins.pl===
You can skip this step on MePrints 1.3 and later.

Add the following lines to your cfg/cfg.d/plugins.pl configuration file: to use the MePrints homepage instead instead of the default EPrints "Profile" page:

$c->{plugins}->{"Screen::User::View"}->{appears}->{key_tools} = undef;
$c->{plugin_alias_map}->{"Screen::User::View"} = "Screen::User::Homepage";

===cfg/cfg.d/user_fields_automatic.pl===

Add the following lines to your cfg/cfg.d/user_fields_automatic.pl configuration file to update the MePrints public profile page automatically when a user changes his or her profile information,

<pre>
$c->{user_fields_automatic} = sub {

my $user = @_;

...

if( defined $user->{changed} )
{
$user->remove_static();
}

};
</pre>

===cfg/cfg.d/eprint_fields_automatic.pl===

Add the following line to your cfg/cfg.d/eprint_fields_automatic.pl configuration file so that the MePrints public profile page automatically changes when an EPrint they have deposited is updated.

$eprint->get_user->remove_static;

===cfg/cfg.d/urls.pl===

To activate the canonical profile URLs, add "/profile/" to the rewrite_exceptions list in your cfg/cfg.d/urls.pl configuration file:

<pre>
$c->{rewrite_exceptions} = [ '/cgi/', '/archive/', '/profile/' ];
</pre>

===cfg/apachevhost.conf===

Add the following directives to your cfg/apachevhost.conf configuration file to enable canonical profile URLs (for example http://myrepository.com/profile/jsmith):

<pre>
<Location "/profile">
DefaultType 'text/html; charset=UTF-8'
SetHandler perl-script
PerlResponseHandler EPrints::Plugin::MePrints::MePrintsHandler
</Location>

</pre>

On eprints 3.2 and later you will now need to regenerated your apache conf:
<eprints_root>/bin/generate_apacheconf --replace <archiveid>

===cfg/workflows/user/default.xml===

Add the following lines to your cfg/workflows/user/default.xml configuration file:

<stage name="default">
...

<component type="Field::Multi">
<title><epc:phrase ref="user_section_personal" /></title>
...
</component>

<component type="Field::Multi">
<title><epc:phrase ref="user_section_meprints" /></title>
<field ref="profile_visibility" required="yes"/>
<field ref="jobtitle"/>
<field ref="expertise"/>
<field ref="biography"/>
<field ref="qualifications"/>
</component>

===cfg/citations/user/default.xml===

Replace the default EPrints user citation with the MePrints citation (which includes a thumbnail of the user's profile picture) run:

cd /opt/eprints3/archives/ARCHIVEID
cp cfg/citations/user/default_with_thumbnail.xml cfg/citations/user/default.xml

'''Note: if you have already made changes to the default citation, you should examine both files and merge the MePrints changes into default.xml

===Authorship in MePrints===
Meprints 1.1 and later change the definition of ownership in the respository. This means that users who have the same email address as that listed in an items creators field belong to that user once the item enters the archive. This allows users to see statistics about papers they have authored without have to upload their own copy of the paper. You can return this to the eprints default by removing the cfg/cfg.d/authorship_meprints.pl file

===Confirm Permissions===
The last thing to do before using MePrints is to ensure that the permissions are correct on the ''meprints'' directory. To do this run the following commands, there probably will not be any output from running this command;
cd archives/ARCHIVEID
chmod g+wx meprints

If the permissions are not correct then you may encounter errors when using MePrints.

==Testing==

After applying all the changes above, restart Apache to activate MePrints.

===Homepage===

Log into your repository and should see your MePrints Homepage with default widget layout and profile picture.

====Update profile====

Click the Modify Profile button and add some information to the new MePrints fields (Job Title, Expertise, Biography, Qualifications). Set your Profile Visibility to '''Public'''. Click the Save button to return to your Homepage where the information you entered should now be displayed.

====Upload photo====

Click the Profile Picture button, choose a file and click Upload. You will be returned to your Homepage where your picture will now be displayed.

====MePrints Widgets====

By default your homepage displays several widgets (see user_homepage_defaults setting in cfg/cfg.d/z_meprints.pl). Try adding and removing widgets using the widget controls at the bottom of the screen. You can also rearrange widgets by dragging them up/down or between columns. To reset to the default widget layout click the Reset button in the widget control bar.

===Public Profile===

Enter the following URL to view your public profile page:

http://myrepository.com/profile/USERNAME

where USERNAME is your EPrints username. The layout of the MePrints widgets on your profile page is controlled by the user_profile_defaults setting in cfg/cfg.d/z_meprints.pl.

Go back to your MePrints homepage and click Modify Profile. Change some of your profile information (eg. Job Title, Expertise, Biography, Qualifications) and click Save. Return to your public profile page and check that your profile information has been updated.

===MePrints Views===

Run:

bin/generate_views ARCHIVEID --generate menus

Check http://myrepository.com/view/ - you should see 2 new views (you may want to link these into your site template).

Explore the view pages and check that you are listed. Make sure that you can click through from the browse listing to your public profile page.

===MePrints search===

Go to: http://myrepository.com/cgi/meprints/search

Check that you can find your profile using keywords from your user profile information (eg. expertise, qualifications).

Make sure that you can click through from the search result list to your public profile page.

===MePrints Embeddable===

If you want to use the default minimal style supplied for MePrints Embeddable then add the following code to the ''<head>'' section of your page:
<link rel="stylesheet" type="text/css" href="http://myrepository.com/style/meprints_embed.css"/>

====MePrints Embeddable Widgets====
It is possible to embed individual widgets that are viewable on your public profile on your own page. If you go to the public profile page you will see an embed links on the widgets that can be embedded. Click the link and instructions will appear telling you how to embed the widget on your page.

====MePrints Embeddable Profile====
Edit an HTML page and add the following code to the ''<head>'' section of the page:

<script type="text/javascript" src="http://myrepository.com/cgi/meprints/embed_js?username=USERNAME"></script>

Where ''USERNAME'' is your username on the repository.

Then inside the ''<body>'' section of the page you need to add the following code:

<div id="meprints_profile"></div>

This will be the location where your embeddable profile will go on your page.

===MePrints for admins===

Using an administrator account go to the Admin screen and choose '''Search users'''. Enter a username or other criteria to find at least one user account (not the account you are logged in with).

Make sure that you can click through from the results list to the user's homepage.

You should be able to modify the user's profile information by clicking Administer Account.

The widget layout should reflect the user's own preference, and you should not be able to make changes to their widget layout.

====Hide Profile====

Change the user's profile visibility to '''private'''.

Log out, and make sure that:

# the profile is no longer visible at /profile/USERNAME
# the profile no longer appears in search results
# the profile no longer appears in view pages
# the embeddable widget no longer displays the profile

You can also change the default visibility of MePrints profiles in cfg/cfg.d/z_meprints.pl
by default profiles are public unless a user specifically makes there profile private. change
$c->{default_profile_behavior} = 1;
to
$c->{default_profile_behavior} = 0;
to make the default private profiles

==Troubleshooting==

===Database errors===

When dragging and dropping Widgets around, MePrints shows database errors in the error log:

DBD::mysql::st execute failed: Duplicate entry '1-0' for key 1 at /opt/eprints3/perl_lib/EPrints/Database.pm line 1192.
at /opt/eprints3/perl_lib/EPrints/Database.pm line 1192
EPrints::Database::insert('EPrints::Database::mysql=HASH(0x2b593e11ebd0)', 'user_items_fields', 'ARRAY(0x2b593bd00510)', ...

This is a known problem which does not seem to affect widget layout.

===generate_views errors===

====Warnings====

Use of uninitialized value $id in hash element at /usr/share/eprints3/perl_lib/EPrints/Database.pm line 2979.

See http://trac.eprints.org/trac/ticket/3537

====EPrint citations====

After hiding all previously public profiles, eprint citations were rendered in the view list instead of users'. (need to work out how to reproduce this)

====Empty views====

After hiding all previously public profiles and regenerating views, view pages still show expertise/department values.

[http://creativecommons.org/licenses/by/3.0/ This work is licensed under a Creative Commons Attribution 3.0 Unported License].

MePrintsInstall

2014-03-12T12:51:12Z

Sf03r@ecs.soton.ac.uk:

EPrints4 Core Roadmap

2014-02-07T11:12:42Z

Sf03r@ecs.soton.ac.uk: /* Data retrieval and searching */

=EPrints4 Core Development=

Trying to divide the work into smaller tasks (and questions where relevant).

==Request Handler / Page Controllers==

This deals with how HTTP requests are handled by EPrints: when a request is made by a client (curl, browser..) a number of headers/parameters must be processed (e.g. Accept, Content-Type, EPrints' cookies, auth etc). This is the entry point of any web requests to the system. The main module is EPrints::Apache::Handler (formerly known as Apache::Rewrite).

* Basic security aspects
** detect invalid requests/URL paths (e.g. containing a dot '.')

* Low-level filters for processing of:
** Cookies (eprints_session, eprints_lang)
** URL encoding
** specific HTTP headers: Accept, Content-Type, Content-Length, Content-Range, Content-MD5 (?), ETag (?)

* System initialisation:
** Repository object init (with language selection, via cookie/default lang)
** Protocol (HTTP, HTTPS?)

* Low-level redirects or custom actions via Trigger

* Call for Controller(s) to handle the request (e.g. CRUD if /id/..., UI, storage (file delivery) etc.) via Trigger

* clean-up/post-processing if needed (e.g. setting Cache headers etc).

==Security==

Security (authentication and authorisation) must be handled by the Page Controller. They decide if auth is required at all (for instance a GET on an object via CRUD is usually allowed without auth). If auth may be required, the PerlAccessHandler stack must be defined.

It is worth noting that authentication is likely to be common to most Page Controllers. The typical authentication mechanisms are: Basic Auth (via HTTP Header) and Cookie/Session-based Auth. Session-based is mostly handled internally (via LoginTicket) but the way the credentials are retrieved can be customised (CAS, LDAP...).

Authorisation, on the other hand will be defined by the Page Controller. If the request is trying to modify an object, the Controller needs to check that the logged-in user has the appropriate rights/roles.

Filters must be called using Trigger(s) or similar mechanism to avoid having hard-coded modules in the Request handler. It is then easy to select, add, remove filters at run-time.

==Database==

* Must contain any SQL handling. Custom SQL in scripts is bad and shows lacks in the DB API. This must handle the usual operations required by the system such as data retrieval, modification etc and any DB optimisation (commonly known as hacks).

* The default DB engine is likely to be MySQL/InnoDB with support for transactions.

* The DB layer is "very" low-level and doesn't check security concerns (e.g. can the user modifies that object?). This must be handled by the above layer, usually DataObj and MetaField.

TODO: an audit of the current DB code to remove un-needed/deprecated methods, to re-organise the required existing methods.

==Data Representation==

This defines properties for data objects (for example the "name" of a user) and offers a layer between the raw data (handled by Database) and the application/views using the data (e.g. CRUD, "the" UI, Export/Import plug-ins etc).

Important: data objects and metadata fields do not know how to render themselves on a UI. This is one of the main design aspect of EPrints4 as to remove dependencies of the UI on the data model.

===Metadata fields===

* make sure the data is valid, according to the type's constraints. For instance, you cannot store a string into an integer

* maps any higher level type (e.g. URL) to a low-level DB type (e.g. varchar)

* must provide a clean and clear API to easily modify data (set_value, add_value etc)

* the type "file" whilst not being a piece of metadata directly is nonetheless a valid field - it is the only type that links data to a stored file (rather than being purely DB data).

* XML/SAX handlers are likely to be kept at the Meta-Field level (because this makes sense)

* aspects such as indexing, generating order values are more likely to be included in the Search components (so via Xapian for instance)

* review of the existing types is needed (40ish types at the moment) and non-core types must be removed (recaptcha, compound...)

===Data set / Data objects===

* DataSet/Objects are collections of metadata fields and offer an API for easily manipulating objects/data.
* Dataset offers a number of properties to handle common fields/concepts in a consistent manner across different datasets. For instance the "lastmod" property which is an internal field always set to when the object was last modified or "history" which keeps track of the modifications of the object. Considered properties:
** "states": the graph of states for that object. Similar to "eprint_status" for "eprint" objects in EPrints2/3. Automates and generalises state transfer for objects.
** "revision": keep the revision number which is incremented each time that object is modified (default: ON)
** "acl": enables the ACL related fields and permission checking (TODO)
** "cache": enables the use of memcached (default: ON if globally enabled) - if enabled, keep a copy of data objects in memory rather than reading objects from DB.
** "read-only": makes that data-set read only and forbids any modification/deletion (default: OFF)
** "history": keeps an XML diff of the modifications made to that object. (TODO)
** "lastmod": keeps a last modified field
** "datestamp": the date at which the object was created
* EPrints::DataObj now contains all required information so that custom datasets do not need to have their explicit implementation (EPrints::DataObj::Foo package)

Question: EPrints2/3 does not offer a generalised manner to reference a sub-dataset: "archive" is used as a short-cut for "eprint:archive" but because the dataset naming is global you can't re-use "archive" for other datasets. So we need a common way to reference a dataset. eprint:inbox? eprint/inbox? eprint_inbox?

==Data retrieval and searching==

I think there are two slightly different aspects of data retrieval:

* an internal mechanism for retrieving data straight from the database, for instance:
** all data objects belonging to a dataset
** all data objects owned by a user
** generally the retrieval of data objects based on an EXACT constraint or set of constraints.
** possibility to order the data objects by a given meta field (i.e. a DB column).
* a user search optimised for helping users to find content they're interested to. This will likely be done by Xapian. Because this concept can become difficult to implement, it is better to use a specialist tool such as Xapian to do it. Includes the following scenarios:
** retrieval of all data objects belonging to a dataset (via the Xapian indexes which may be out-of-date or incomplete since objects are indexed by the indexer in a asynchronous manner)
** parsing complex user queries using e.g. boolean operators

One question is how to label these two slightly different searching mechanism?

===Internal Data retrieval===

* Only supports EXACT matching or other SQL-derived tests and operators e.g. NOT NULL (aka is_set)
* Tightly linked to the concept of EPrints::List
* May be used on the UI to display lists of items owned by a user ETC but shouldn't be used in real user searches

===User Searches===

* Requires the creation and management of indexes (because it is the indexes which are searched)

==CLI==

* Use of a SYSTEM user for CLI operation/scripts? If not, ACL type of checks must online be done/enabled for Web requests

==Misc==

EPrints4 Core Roadmap

2014-02-07T11:12:28Z

Sf03r@ecs.soton.ac.uk: /* Data set / Data objects */

=EPrints4 Core Development=

Trying to divide the work into smaller tasks (and questions where relevant).

==Request Handler / Page Controllers==

This deals with how HTTP requests are handled by EPrints: when a request is made by a client (curl, browser..) a number of headers/parameters must be processed (e.g. Accept, Content-Type, EPrints' cookies, auth etc). This is the entry point of any web requests to the system. The main module is EPrints::Apache::Handler (formerly known as Apache::Rewrite).

* Basic security aspects
** detect invalid requests/URL paths (e.g. containing a dot '.')

* Low-level filters for processing of:
** Cookies (eprints_session, eprints_lang)
** URL encoding
** specific HTTP headers: Accept, Content-Type, Content-Length, Content-Range, Content-MD5 (?), ETag (?)

* System initialisation:
** Repository object init (with language selection, via cookie/default lang)
** Protocol (HTTP, HTTPS?)

* Low-level redirects or custom actions via Trigger

* Call for Controller(s) to handle the request (e.g. CRUD if /id/..., UI, storage (file delivery) etc.) via Trigger

* clean-up/post-processing if needed (e.g. setting Cache headers etc).

==Security==

Security (authentication and authorisation) must be handled by the Page Controller. They decide if auth is required at all (for instance a GET on an object via CRUD is usually allowed without auth). If auth may be required, the PerlAccessHandler stack must be defined.

It is worth noting that authentication is likely to be common to most Page Controllers. The typical authentication mechanisms are: Basic Auth (via HTTP Header) and Cookie/Session-based Auth. Session-based is mostly handled internally (via LoginTicket) but the way the credentials are retrieved can be customised (CAS, LDAP...).

Authorisation, on the other hand will be defined by the Page Controller. If the request is trying to modify an object, the Controller needs to check that the logged-in user has the appropriate rights/roles.

Filters must be called using Trigger(s) or similar mechanism to avoid having hard-coded modules in the Request handler. It is then easy to select, add, remove filters at run-time.

==Database==

* Must contain any SQL handling. Custom SQL in scripts is bad and shows lacks in the DB API. This must handle the usual operations required by the system such as data retrieval, modification etc and any DB optimisation (commonly known as hacks).

* The default DB engine is likely to be MySQL/InnoDB with support for transactions.

* The DB layer is "very" low-level and doesn't check security concerns (e.g. can the user modifies that object?). This must be handled by the above layer, usually DataObj and MetaField.

TODO: an audit of the current DB code to remove un-needed/deprecated methods, to re-organise the required existing methods.

==Data Representation==

This defines properties for data objects (for example the "name" of a user) and offers a layer between the raw data (handled by Database) and the application/views using the data (e.g. CRUD, "the" UI, Export/Import plug-ins etc).

Important: data objects and metadata fields do not know how to render themselves on a UI. This is one of the main design aspect of EPrints4 as to remove dependencies of the UI on the data model.

===Metadata fields===

* make sure the data is valid, according to the type's constraints. For instance, you cannot store a string into an integer

* maps any higher level type (e.g. URL) to a low-level DB type (e.g. varchar)

* must provide a clean and clear API to easily modify data (set_value, add_value etc)

* the type "file" whilst not being a piece of metadata directly is nonetheless a valid field - it is the only type that links data to a stored file (rather than being purely DB data).

* XML/SAX handlers are likely to be kept at the Meta-Field level (because this makes sense)

* aspects such as indexing, generating order values are more likely to be included in the Search components (so via Xapian for instance)

* review of the existing types is needed (40ish types at the moment) and non-core types must be removed (recaptcha, compound...)

===Data set / Data objects===

* DataSet/Objects are collections of metadata fields and offer an API for easily manipulating objects/data.
* Dataset offers a number of properties to handle common fields/concepts in a consistent manner across different datasets. For instance the "lastmod" property which is an internal field always set to when the object was last modified or "history" which keeps track of the modifications of the object. Considered properties:
** "states": the graph of states for that object. Similar to "eprint_status" for "eprint" objects in EPrints2/3. Automates and generalises state transfer for objects.
** "revision": keep the revision number which is incremented each time that object is modified (default: ON)
** "acl": enables the ACL related fields and permission checking (TODO)
** "cache": enables the use of memcached (default: ON if globally enabled) - if enabled, keep a copy of data objects in memory rather than reading objects from DB.
** "read-only": makes that data-set read only and forbids any modification/deletion (default: OFF)
** "history": keeps an XML diff of the modifications made to that object. (TODO)
** "lastmod": keeps a last modified field
** "datestamp": the date at which the object was created
* EPrints::DataObj now contains all required information so that custom datasets do not need to have their explicit implementation (EPrints::DataObj::Foo package)

Question: EPrints2/3 does not offer a generalised manner to reference a sub-dataset: "archive" is used as a short-cut for "eprint:archive" but because the dataset naming is global you can't re-use "archive" for other datasets. So we need a common way to reference a dataset. eprint:inbox? eprint/inbox? eprint_inbox?

==Data retrieval and searching==

I think there are two slightly different aspects of data retrieval:

* an internal mechanism for retrieving data straight from the database, for instance:

** all data objects belonging to a dataset
** all data objects owned by a user
** generally the retrieval of data objects based on an EXACT constraint or set of constraints.

** possibility to order the data objects by a given meta field (i.e. a DB column).

* a user search optimised for helping users to find content they're interested to. This will likely be done by Xapian. Because this concept can become difficult to implement, it is better to use a specialist tool such as Xapian to do it. Includes the following scenarios:

** retrieval of all data objects belonging to a dataset (via the Xapian indexes which may be out-of-date or incomplete since objects are indexed by the indexer in a asynchronous manner)
** parsing complex user queries using e.g. boolean operators

One question is how to label these two slightly different searching mechanism?

===Internal Data retrieval===

* Only supports EXACT matching or other SQL-derived tests and operators e.g. NOT NULL (aka is_set)
* Tightly linked to the concept of EPrints::List
* May be used on the UI to display lists of items owned by a user ETC but shouldn't be used in real user searches

===User Searches===

* Requires the creation and management of indexes (because it is the indexes which are searched)

==CLI==

* Use of a SYSTEM user for CLI operation/scripts? If not, ACL type of checks must online be done/enabled for Web requests

==Misc==

EPrints4 Core Roadmap

2014-02-06T16:10:45Z

Sf03r@ecs.soton.ac.uk: /* Data Representation */

=EPrints4 Core Development=

Trying to divide the work into smaller tasks (and questions where relevant).

==Request Handler / Page Controllers==

This deals with how HTTP requests are handled by EPrints: when a request is made by a client (curl, browser..) a number of headers/parameters must be processed (e.g. Accept, Content-Type, EPrints' cookies, auth etc). This is the entry point of any web requests to the system. The main module is EPrints::Apache::Handler (formerly known as Apache::Rewrite).

* Basic security aspects
** detect invalid requests/URL paths (e.g. containing a dot '.')

* Low-level filters for processing of:
** Cookies (eprints_session, eprints_lang)
** URL encoding
** specific HTTP headers: Accept, Content-Type, Content-Length, Content-Range, Content-MD5 (?), ETag (?)

* System initialisation:
** Repository object init (with language selection, via cookie/default lang)
** Protocol (HTTP, HTTPS?)

* Low-level redirects or custom actions via Trigger

* Call for Controller(s) to handle the request (e.g. CRUD if /id/..., UI, storage (file delivery) etc.) via Trigger

* clean-up/post-processing if needed (e.g. setting Cache headers etc).

==Security==

Security (authentication and authorisation) must be handled by the Page Controller. They decide if auth is required at all (for instance a GET on an object via CRUD is usually allowed without auth). If auth may be required, the PerlAccessHandler stack must be defined.

It is worth noting that authentication is likely to be common to most Page Controllers. The typical authentication mechanisms are: Basic Auth (via HTTP Header) and Cookie/Session-based Auth. Session-based is mostly handled internally (via LoginTicket) but the way the credentials are retrieved can be customised (CAS, LDAP...).

Authorisation, on the other hand will be defined by the Page Controller. If the request is trying to modify an object, the Controller needs to check that the logged-in user has the appropriate rights/roles.

Filters must be called using Trigger(s) or similar mechanism to avoid having hard-coded modules in the Request handler. It is then easy to select, add, remove filters at run-time.

==Database==

* Must contain any SQL handling. Custom SQL in scripts is bad and shows lacks in the DB API. This must handle the usual operations required by the system such as data retrieval, modification etc and any DB optimisation (commonly known as hacks).

* The default DB engine is likely to be MySQL/InnoDB with support for transactions.

* The DB layer is "very" low-level and doesn't check security concerns (e.g. can the user modifies that object?). This must be handled by the above layer, usually DataObj and MetaField.

TODO: an audit of the current DB code to remove un-needed/deprecated methods, to re-organise the required existing methods.

==Data Representation==

This defines properties for data objects (for example the "name" of a user) and offers a layer between the raw data (handled by Database) and the application/views using the data (e.g. CRUD, "the" UI, Export/Import plug-ins etc).

Important: data objects and metadata fields do not know how to render themselves on a UI. This is one of the main design aspect of EPrints4 as to remove dependencies of the UI on the data model.

===Metadata fields===

* make sure the data is valid, according to the type's constraints. For instance, you cannot store a string into an integer

* maps any higher level type (e.g. URL) to a low-level DB type (e.g. varchar)

* must provide a clean and clear API to easily modify data (set_value, add_value etc)

* the type "file" whilst not being a piece of metadata directly is nonetheless a valid field - it is the only type that links data to a stored file (rather than being purely DB data).

* XML/SAX handlers are likely to be kept at the Meta-Field level (because this makes sense)

* aspects such as indexing, generating order values are more likely to be included in the Search components (so via Xapian for instance)

* review of the existing types is needed (40ish types at the moment) and non-core types must be removed (recaptcha, compound...)

===Data set / Data objects===

* DataSet/Objects are collections of metadata fields and offer an API for easily manipulating objects/data.

* Dataset offers a number of properties to handle common fields/concepts in a consistent manner across different datasets. For instance the "lastmod" property which is an internal field always set to when the object was last modified or "history" which keeps track of the modifications of the object. Considered properties:

** "states": the graph of states for that object. Similar to "eprint_status" for "eprint" objects in EPrints2/3. Automates and generalises state transfer for objects.

** "revision": keep the revision number which is incremented each time that object is modified (default: ON)

** "acl": enables the ACL related fields and permission checking (TODO)

** "cache": enables the use of memcached (default: ON if globally enabled) - if enabled, keep a copy of data objects in memory rather than reading objects from DB.

** "read-only": makes that data-set read only and forbids any modification/deletion (default: OFF)

** "history": keeps an XML diff of the modifications made to that object. (TODO)

** "lastmod": keeps a last modified field

** "datestamp": the date at which the object was created

* EPrints::DataObj now contains all required information so that custom datasets do not need to have their explicit implementation (EPrints::DataObj::Foo package)

Question: EPrints2/3 does not offer a generalised manner to reference a sub-dataset: "archive" is used as a short-cut for "eprint:archive" but because the dataset naming is global you can't re-use "archive" for other datasets. So we need a common way to reference a dataset. eprint:inbox? eprint/inbox? eprint_inbox?

==Data retrieval and searching==

I think there are two slightly different aspects of data retrieval:

* an internal mechanism for retrieving data straight from the database, for instance:

** all data objects belonging to a dataset
** all data objects owned by a user
** generally the retrieval of data objects based on an EXACT constraint or set of constraints.

** possibility to order the data objects by a given meta field (i.e. a DB column).

* a user search optimised for helping users to find content they're interested to. This will likely be done by Xapian. Because this concept can become difficult to implement, it is better to use a specialist tool such as Xapian to do it. Includes the following scenarios:

** retrieval of all data objects belonging to a dataset (via the Xapian indexes which may be out-of-date or incomplete since objects are indexed by the indexer in a asynchronous manner)
** parsing complex user queries using e.g. boolean operators

One question is how to label these two slightly different searching mechanism?

===Internal Data retrieval===

* Only supports EXACT matching or other SQL-derived tests and operators e.g. NOT NULL (aka is_set)
* Tightly linked to the concept of EPrints::List
* May be used on the UI to display lists of items owned by a user ETC but shouldn't be used in real user searches

===User Searches===

* Requires the creation and management of indexes (because it is the indexes which are searched)

==CLI==

* Use of a SYSTEM user for CLI operation/scripts? If not, ACL type of checks must online be done/enabled for Web requests

==Misc==

EPrints4 Core Roadmap

2014-02-06T16:00:13Z

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

=EPrints4 Core Development=

Trying to divide the work into smaller tasks (and questions where relevant).

==Request Handler / Page Controllers==

This deals with how HTTP requests are handled by EPrints: when a request is made by a client (curl, browser..) a number of headers/parameters must be processed (e.g. Accept, Content-Type, EPrints' cookies, auth etc). This is the entry point of any web requests to the system. The main module is EPrints::Apache::Handler (formerly known as Apache::Rewrite).

* Basic security aspects
** detect invalid requests/URL paths (e.g. containing a dot '.')

* Low-level filters for processing of:
** Cookies (eprints_session, eprints_lang)
** URL encoding
** specific HTTP headers: Accept, Content-Type, Content-Length, Content-Range, Content-MD5 (?), ETag (?)

* System initialisation:
** Repository object init (with language selection, via cookie/default lang)
** Protocol (HTTP, HTTPS?)

* Low-level redirects or custom actions via Trigger

* Call for Controller(s) to handle the request (e.g. CRUD if /id/..., UI, storage (file delivery) etc.) via Trigger

* clean-up/post-processing if needed (e.g. setting Cache headers etc).

==Security==

Security (authentication and authorisation) must be handled by the Page Controller. They decide if auth is required at all (for instance a GET on an object via CRUD is usually allowed without auth). If auth may be required, the PerlAccessHandler stack must be defined.

It is worth noting that authentication is likely to be common to most Page Controllers. The typical authentication mechanisms are: Basic Auth (via HTTP Header) and Cookie/Session-based Auth. Session-based is mostly handled internally (via LoginTicket) but the way the credentials are retrieved can be customised (CAS, LDAP...).

Authorisation, on the other hand will be defined by the Page Controller. If the request is trying to modify an object, the Controller needs to check that the logged-in user has the appropriate rights/roles.

Filters must be called using Trigger(s) or similar mechanism to avoid having hard-coded modules in the Request handler. It is then easy to select, add, remove filters at run-time.

==Database==

* Must contain any SQL handling. Custom SQL in scripts is bad and shows lacks in the DB API. This must handle the usual operations required by the system such as data retrieval, modification etc and any DB optimisation (commonly known as hacks).

* The default DB engine is likely to be MySQL/InnoDB with support for transactions.

* The DB layer is "very" low-level and doesn't check security concerns (e.g. can the user modifies that object?). This must be handled by the above layer, usually DataObj and MetaField.

TODO: an audit of the current DB code to remove un-needed/deprecated methods, to re-organise the required existing methods.

==Data Representation==

This defines properties for data objects (for example the "name" of a user) and offers a layer between the raw data (handled by Database) and the application/views using the data (e.g. CRUD, "the" UI, Export/Import plug-ins etc).

Important: data objects and metadata fields do not know how to render themselves on a UI. This is one of the main design aspect of EPrints4 as to remove dependencies of the UI on the data model.

===Metadata fields===

* make sure the data is valid, according to the type's constraints. For instance, you cannot store a string into an integer

* maps any higher level type (e.g. URL) to a low-level DB type (e.g. varchar)

* must provide a clean and clear API to easily modify data (set_value, add_value etc)

* the type "file" whilst not being a piece of metadata directly is nonetheless a valid field - it is the only type that links data to a stored file (rather than being purely DB data).

* XML/SAX handlers are likely to be kept at the Meta-Field level (because this makes sense)

* aspects such as indexing, generating order values are more likely to be included in the Search components (so via Xapian for instance)

* review of the existing types is needed (40ish types at the moment) and non-core types must be removed (recaptcha, compound...)

===Data set / Data objects===

* DataSet/Objects are collections of metadata fields and offer an API for easily manipulating objects/data.

* Dataset offers a number of properties to handle common fields/concepts in a consistent manner across different datasets. For instance the "lastmod" property which is an internal field always set to when the object was last modified or "history" which keeps track of the modifications of the object. Considered properties:

** "states": the graph of states for that object. Similar to "eprint_status" for "eprint" objects in EPrints2/3. Automates and generalises state transfer for objects.

** "revision": keep the revision number which is incremented each time that object is modified (default: ON)

** "acl": enables the ACL related fields and permission checking (TODO)

** "cache": enables the use of memcached (default: ON if globally enabled) - if enabled, keep a copy of data objects in memory rather than reading objects from DB.

** "read-only": makes that data-set read only and forbids any modification/deletion (default: OFF)

** "history": keeps an XML diff of the modifications made to that object. (TODO)

** "lastmod": keeps a last modified field

** "datestamp": the date at which the object was created

* EPrints::DataObj now contains all required information so that custom datasets do not need to have their explicit implementation (EPrints::DataObj::Foo package)

==Data retrieval and searching==

I think there are two slightly different aspects of data retrieval:

* an internal mechanism for retrieving data straight from the database, for instance:

** all data objects belonging to a dataset
** all data objects owned by a user
** generally the retrieval of data objects based on an EXACT constraint or set of constraints.

** possibility to order the data objects by a given meta field (i.e. a DB column).

* a user search optimised for helping users to find content they're interested to. This will likely be done by Xapian. Because this concept can become difficult to implement, it is better to use a specialist tool such as Xapian to do it. Includes the following scenarios:

** retrieval of all data objects belonging to a dataset (via the Xapian indexes which may be out-of-date or incomplete since objects are indexed by the indexer in a asynchronous manner)
** parsing complex user queries using e.g. boolean operators

One question is how to label these two slightly different searching mechanism?

===Internal Data retrieval===

* Only supports EXACT matching or other SQL-derived tests and operators e.g. NOT NULL (aka is_set)
* Tightly linked to the concept of EPrints::List
* May be used on the UI to display lists of items owned by a user ETC but shouldn't be used in real user searches

===User Searches===

* Requires the creation and management of indexes (because it is the indexes which are searched)

==CLI==

* Use of a SYSTEM user for CLI operation/scripts? If not, ACL type of checks must online be done/enabled for Web requests

==Misc==

EPrints4 Core Roadmap

2014-02-06T15:59:20Z

Sf03r@ecs.soton.ac.uk:

=EPrints4 Core Development=

Trying to divide the work into smaller tasks (and questions where relevant).

==Request Handler / Page Controllers==

This deals with how HTTP requests are handled by EPrints: when a request is made by a client (curl, browser..) a number of headers/parameters must be processed (e.g. Accept, Content-Type, EPrints' cookies, auth etc). This is the entry point of any web requests to the system. The main module is EPrints::Apache::Handler (formerly known as Apache::Rewrite).

* Basic security aspects
** detect invalid requests/URL paths (e.g. containing a dot '.')

* Low-level filters for processing of:
** Cookies (eprints_session, eprints_lang)
** URL encoding
** specific HTTP headers: Accept, Content-Type, Content-Length, Content-Range, Content-MD5 (?), ETag (?)

* System initialisation:
** Repository object init (with language selection, via cookie/default lang)
** Protocol (HTTP, HTTPS?)

* Low-level redirects or custom actions via Trigger

* Call for Controller(s) to handle the request (e.g. CRUD if /id/..., UI, storage (file delivery) etc.) via Trigger

* clean-up/post-processing if needed (e.g. setting Cache headers etc).

==Security==

Security (authentication and authorisation) must be handled by the Page Controller. They decide if auth is required at all (for instance a GET on an object via CRUD is usually allowed without auth). If auth may be required, the PerlAccessHandler stack must be defined.

It is worth noting that authentication is likely to be common to most Page Controllers. The typical authentication mechanisms are: Basic Auth (via HTTP Header) and Cookie/Session-based Auth. Session-based is mostly handled internally (via LoginTicket) but the way the credentials are retrieved can be customised (CAS, LDAP...).

Authorisation, on the other hand will be defined by the Page Controller. If the request is trying to modify an object, the Controller needs to check that the logged-in user has the appropriate rights/roles.

Filters must be called using Trigger(s) or similar mechanism to avoid having hard-coded modules in the Request handler. It is then easy to select, add, remove filters at run-time.

==Database==

* Must contain any SQL handling. Custom SQL in scripts is bad and shows lacks in the DB API. This must handle the usual operations required by the system such as data retrieval, modification etc and any DB optimisation (commonly known as hacks).

* The default DB engine is likely to be MySQL/InnoDB with support for transactions.

* The DB layer is "very" low-level and doesn't check security concerns (e.g. can the user modifies that object?). This must be handled by the above layer, usually DataObj and MetaField.

TODO: an audit of the current DB code to remove un-needed/deprecated methods, to re-organise the required existing methods.

==Data Representation==

This defines properties for data objects (for example the "name" of a user) and offers a layer between the raw data (handled by Database) and the application/views using the data (e.g. CRUD, "the" UI, Export/Import plug-ins etc).

Important: data objects and metadata fields do not know how to render themselves on a UI. This is one of the main design aspect of EPrints4 as to remove dependencies of the UI on the data model.

===Metadata fields===

* make sure the data is valid, according to the type's constraints. For instance, you cannot store a string into an integer

* maps any higher level type (e.g. URL) to a low-level DB type (e.g. varchar)

* must provide a clean and clear API to easily modify data (set_value, add_value etc)

* the type "file" whilst not being a piece of metadata directly is nonetheless a valid field - it is the only type that links data to a stored file (rather than being purely DB data).

* XML/SAX handlers are likely to be kept at the Meta-Field level (because this makes sense)

* aspects such as indexing, generating order values are more likely to be included in the Search components (so via Xapian for instance)

* review of the existing types is needed (40ish types at the moment) and non-core types must be removed (recaptcha, compound...)

===Data set / Data objects===

* DataSet/Objects are collections of metadata fields and offer an API for easily manipulating objects/data.

* Dataset offers a number of properties to handle common fields/concepts in a consistent manner across different datasets. For instance the "lastmod" property which is an internal field always set to when the object was last modified or "history" which keeps track of the modifications of the object. Considered properties:

** "states": the graph of states for that object. Similar to "eprint_status" for "eprint" objects in EPrints2/3. Automates and generalises state transfer for objects.

** "revision": keep the revision number which is incremented each time that object is modified (default: ON)

** "acl": enables the ACL related fields and permission checking (TODO)

** "cache": enables the use of memcached (default: ON if globally enabled) - if enabled, keep a copy of data objects in memory rather than reading objects from DB.

** "read-only": makes that data-set read only and forbids any modification/deletion (default: OFF)

** "history": keeps an XML diff of the modifications made to that object. (TODO)

** "lastmod": keeps a last modified field

** "datestamp": the date at which the object was created

* EPrints::DataObj now contains all required information so that custom datasets do not need to have their explicit implementation (EPrints::DataObj::Foo package)

==Data retrieval and searching==

I think there are two slightly different aspects of data retrieval:

* an internal mechanism for retrieving data straight from the database, for instance:

** all data objects belonging to a dataset
** all data objects owned by a user
** generally the retrieval of data objects based on an EXACT constraint or set of constraints.

** possibility to order the data objects by a given meta field (i.e. a DB column).

* a user search optimised for helping users to find content they're interested to. This will likely be done by Xapian. Because this concept can become difficult to implement, it is better to use a specialist tool such as Xapian to do it. Includes the following scenarios:

** retrieval of all data objects belonging to a dataset (via the Xapian indexes which may be out-of-date or incomplete since objects are indexed by the indexer in a asynchronous manner)
** parsing complex user queries using e.g. boolean operators

One question is how to label these two slightly different searching mechanism?

===Internal Data retrieval===

* Only supports EXACT matching or other SQL-derived tests and operators e.g. NOT NULL (aka is_set)
* Tightly linked to the concept of EPrints::List
* May be used on the UI to display lists of items owned by a user ETC but shouldn't be used in real user searches

===User Searches===

* Requires the creation and management of indexes (because it is the indexes which are searched)

==CLI==

==Misc==

EPrints4 Core Roadmap

2014-02-06T15:58:48Z

Sf03r@ecs.soton.ac.uk: /* Data retrieval */

=EPrints4 Core Development=

Trying to divide the work into smaller tasks (and questions where relevant).

==Request Handler / Page Controllers==

This deals with how HTTP requests are handled by EPrints: when a request is made by a client (curl, browser..) a number of headers/parameters must be processed (e.g. Accept, Content-Type, EPrints' cookies, auth etc). This is the entry point of any web requests to the system. The main module is EPrints::Apache::Handler (formerly known as Apache::Rewrite).

* Basic security aspects
** detect invalid requests/URL paths (e.g. containing a dot '.')

* Low-level filters for processing of:
** Cookies (eprints_session, eprints_lang)
** URL encoding
** specific HTTP headers: Accept, Content-Type, Content-Length, Content-Range, Content-MD5 (?), ETag (?)

* System initialisation:
** Repository object init (with language selection, via cookie/default lang)
** Protocol (HTTP, HTTPS?)

* Low-level redirects or custom actions via Trigger

* Call for Controller(s) to handle the request (e.g. CRUD if /id/..., UI, storage (file delivery) etc.) via Trigger

* clean-up/post-processing if needed (e.g. setting Cache headers etc).

==Security==

Security (authentication and authorisation) must be handled by the Page Controller. They decide if auth is required at all (for instance a GET on an object via CRUD is usually allowed without auth). If auth may be required, the PerlAccessHandler stack must be defined.

It is worth noting that authentication is likely to be common to most Page Controllers. The typical authentication mechanisms are: Basic Auth (via HTTP Header) and Cookie/Session-based Auth. Session-based is mostly handled internally (via LoginTicket) but the way the credentials are retrieved can be customised (CAS, LDAP...).

Authorisation, on the other hand will be defined by the Page Controller. If the request is trying to modify an object, the Controller needs to check that the logged-in user has the appropriate rights/roles.

Filters must be called using Trigger(s) or similar mechanism to avoid having hard-coded modules in the Request handler. It is then easy to select, add, remove filters at run-time.

==Database==

* Must contain any SQL handling. Custom SQL in scripts is bad and shows lacks in the DB API. This must handle the usual operations required by the system such as data retrieval, modification etc and any DB optimisation (commonly known as hacks).

* The default DB engine is likely to be MySQL/InnoDB with support for transactions.

* The DB layer is "very" low-level and doesn't check security concerns (e.g. can the user modifies that object?). This must be handled by the above layer, usually DataObj and MetaField.

TODO: an audit of the current DB code to remove un-needed/deprecated methods, to re-organise the required existing methods.

==Data Representation==

This defines properties for data objects (for example the "name" of a user) and offers a layer between the raw data (handled by Database) and the application/views using the data (e.g. CRUD, "the" UI, Export/Import plug-ins etc).

Important: data objects and metadata fields do not know how to render themselves on a UI. This is one of the main design aspect of EPrints4 as to remove dependencies of the UI on the data model.

===Metadata fields===

* make sure the data is valid, according to the type's constraints. For instance, you cannot store a string into an integer

* maps any higher level type (e.g. URL) to a low-level DB type (e.g. varchar)

* must provide a clean and clear API to easily modify data (set_value, add_value etc)

* the type "file" whilst not being a piece of metadata directly is nonetheless a valid field - it is the only type that links data to a stored file (rather than being purely DB data).

* XML/SAX handlers are likely to be kept at the Meta-Field level (because this makes sense)

* aspects such as indexing, generating order values are more likely to be included in the Search components (so via Xapian for instance)

* review of the existing types is needed (40ish types at the moment) and non-core types must be removed (recaptcha, compound...)

===Data set / Data objects===

* DataSet/Objects are collections of metadata fields and offer an API for easily manipulating objects/data.

* Dataset offers a number of properties to handle common fields/concepts in a consistent manner across different datasets. For instance the "lastmod" property which is an internal field always set to when the object was last modified or "history" which keeps track of the modifications of the object. Considered properties:

** "states": the graph of states for that object. Similar to "eprint_status" for "eprint" objects in EPrints2/3. Automates and generalises state transfer for objects.

** "revision": keep the revision number which is incremented each time that object is modified (default: ON)

** "acl": enables the ACL related fields and permission checking (TODO)

** "cache": enables the use of memcached (default: ON if globally enabled) - if enabled, keep a copy of data objects in memory rather than reading objects from DB.

** "read-only": makes that data-set read only and forbids any modification/deletion (default: OFF)

** "history": keeps an XML diff of the modifications made to that object. (TODO)

** "lastmod": keeps a last modified field

** "datestamp": the date at which the object was created

* EPrints::DataObj now contains all required information so that custom datasets do not need to have their explicit implementation (EPrints::DataObj::Foo package)

==Data retrieval and searching==

I think there are two slightly different aspects of data retrieval:

* an internal mechanism for retrieving data straight from the database, for instance:

** all data objects belonging to a dataset
** all data objects owned by a user
** generally the retrieval of data objects based on an EXACT constraint or set of constraints.

** possibility to order the data objects by a given meta field (i.e. a DB column).

* a user search optimised for helping users to find content they're interested to. This will likely be done by Xapian. Because this concept can become difficult to implement, it is better to use a specialist tool such as Xapian to do it. Includes the following scenarios:

** retrieval of all data objects belonging to a dataset (via the Xapian indexes which may be out-of-date or incomplete since objects are indexed by the indexer in a asynchronous manner)
** parsing complex user queries using e.g. boolean operators

One question is how to label these two slightly different searching mechanism?

===Internal Data retrieval===

* Only supports EXACT matching or other SQL-derived tests and operators e.g. NOT NULL (aka is_set)
* Tightly linked to the concept of EPrints::List
* May be used on the UI to display lists of items owned by a user ETC but shouldn't be used in real user searches

===User Searches===

* Requires the creation and management of indexes (because it is the indexes which are searched)

EPrints4 Core Roadmap

2014-02-06T15:47:22Z

Sf03r@ecs.soton.ac.uk:

=EPrints4 Core Development=

Trying to divide the work into smaller tasks (and questions where relevant).

==Request Handler / Page Controllers==

This deals with how HTTP requests are handled by EPrints: when a request is made by a client (curl, browser..) a number of headers/parameters must be processed (e.g. Accept, Content-Type, EPrints' cookies, auth etc). This is the entry point of any web requests to the system. The main module is EPrints::Apache::Handler (formerly known as Apache::Rewrite).

* Basic security aspects
** detect invalid requests/URL paths (e.g. containing a dot '.')

* Low-level filters for processing of:
** Cookies (eprints_session, eprints_lang)
** URL encoding
** specific HTTP headers: Accept, Content-Type, Content-Length, Content-Range, Content-MD5 (?), ETag (?)

* System initialisation:
** Repository object init (with language selection, via cookie/default lang)
** Protocol (HTTP, HTTPS?)

* Low-level redirects or custom actions via Trigger

* Call for Controller(s) to handle the request (e.g. CRUD if /id/..., UI, storage (file delivery) etc.) via Trigger

* clean-up/post-processing if needed (e.g. setting Cache headers etc).

==Security==

Security (authentication and authorisation) must be handled by the Page Controller. They decide if auth is required at all (for instance a GET on an object via CRUD is usually allowed without auth). If auth may be required, the PerlAccessHandler stack must be defined.

It is worth noting that authentication is likely to be common to most Page Controllers. The typical authentication mechanisms are: Basic Auth (via HTTP Header) and Cookie/Session-based Auth. Session-based is mostly handled internally (via LoginTicket) but the way the credentials are retrieved can be customised (CAS, LDAP...).

Authorisation, on the other hand will be defined by the Page Controller. If the request is trying to modify an object, the Controller needs to check that the logged-in user has the appropriate rights/roles.

Filters must be called using Trigger(s) or similar mechanism to avoid having hard-coded modules in the Request handler. It is then easy to select, add, remove filters at run-time.

==Database==

* Must contain any SQL handling. Custom SQL in scripts is bad and shows lacks in the DB API. This must handle the usual operations required by the system such as data retrieval, modification etc and any DB optimisation (commonly known as hacks).

* The default DB engine is likely to be MySQL/InnoDB with support for transactions.

* The DB layer is "very" low-level and doesn't check security concerns (e.g. can the user modifies that object?). This must be handled by the above layer, usually DataObj and MetaField.

TODO: an audit of the current DB code to remove un-needed/deprecated methods, to re-organise the required existing methods.

==Data Representation==

This defines properties for data objects (for example the "name" of a user) and offers a layer between the raw data (handled by Database) and the application/views using the data (e.g. CRUD, "the" UI, Export/Import plug-ins etc).

Important: data objects and metadata fields do not know how to render themselves on a UI. This is one of the main design aspect of EPrints4 as to remove dependencies of the UI on the data model.

===Metadata fields===

* make sure the data is valid, according to the type's constraints. For instance, you cannot store a string into an integer

* maps any higher level type (e.g. URL) to a low-level DB type (e.g. varchar)

* must provide a clean and clear API to easily modify data (set_value, add_value etc)

* the type "file" whilst not being a piece of metadata directly is nonetheless a valid field - it is the only type that links data to a stored file (rather than being purely DB data).

* XML/SAX handlers are likely to be kept at the Meta-Field level (because this makes sense)

* aspects such as indexing, generating order values are more likely to be included in the Search components (so via Xapian for instance)

* review of the existing types is needed (40ish types at the moment) and non-core types must be removed (recaptcha, compound...)

===Data set / Data objects===

* DataSet/Objects are collections of metadata fields and offer an API for easily manipulating objects/data.

* Dataset offers a number of properties to handle common fields/concepts in a consistent manner across different datasets. For instance the "lastmod" property which is an internal field always set to when the object was last modified or "history" which keeps track of the modifications of the object. Considered properties:

** "states": the graph of states for that object. Similar to "eprint_status" for "eprint" objects in EPrints2/3. Automates and generalises state transfer for objects.

** "revision": keep the revision number which is incremented each time that object is modified (default: ON)

** "acl": enables the ACL related fields and permission checking (TODO)

** "cache": enables the use of memcached (default: ON if globally enabled) - if enabled, keep a copy of data objects in memory rather than reading objects from DB.

** "read-only": makes that data-set read only and forbids any modification/deletion (default: OFF)

** "history": keeps an XML diff of the modifications made to that object. (TODO)

** "lastmod": keeps a last modified field

** "datestamp": the date at which the object was created

* EPrints::DataObj now contains all required information so that custom datasets do not need to have their explicit implementation (EPrints::DataObj::Foo package)

==Data retrieval==

EPrints4 Core Roadmap

2014-02-06T15:42:48Z

Sf03r@ecs.soton.ac.uk:

=EPrints4 Core Development=

Trying to divide the work into smaller tasks (and questions where relevant).

==Request Handler / Page Controllers==

This deals with how HTTP requests are handled by EPrints: when a request is made by a client (curl, browser..) a number of headers/parameters must be processed (e.g. Accept, Content-Type, EPrints' cookies, auth etc). This is the entry point of any web requests to the system. The main module is EPrints::Apache::Handler (formerly known as Apache::Rewrite).

* Basic security aspects
** detect invalid requests/URL paths (e.g. containing a dot '.')

* Low-level filters for processing of:
** Cookies (eprints_session, eprints_lang)
** URL encoding
** specific HTTP headers: Accept, Content-Type, Content-Length, Content-Range, Content-MD5 (?), ETag (?)

* System initialisation:
** Repository object init (with language selection, via cookie/default lang)
** Protocol (HTTP, HTTPS?)

* Low-level redirects or custom actions via Trigger

* Call for Controller(s) to handle the request (e.g. CRUD if /id/..., UI, storage (file delivery) etc.) via Trigger

* clean-up/post-processing if needed (e.g. setting Cache headers etc).

==Security==

Security (authentication and authorisation) must be handled by the Page Controller. They decide if auth is required at all (for instance a GET on an object via CRUD is usually allowed without auth). If auth may be required, the PerlAccessHandler stack must be defined.

It is worth noting that authentication is likely to be common to most Page Controllers. The typical authentication mechanisms are: Basic Auth (via HTTP Header) and Cookie/Session-based Auth. Session-based is mostly handled internally (via LoginTicket) but the way the credentials are retrieved can be customised (CAS, LDAP...).

Authorisation, on the other hand will be defined by the Page Controller. If the request is trying to modify an object, the Controller needs to check that the logged-in user has the appropriate rights/roles.

Filters must be called using Trigger(s) or similar mechanism to avoid having hard-coded modules in the Request handler. It is then easy to select, add, remove filters at run-time.

==Database==

* Must contain any SQL handling. Custom SQL in scripts is bad and shows lacks in the DB API. This must handle the usual operations required by the system such as data retrieval, modification etc and any DB optimisation (commonly known as hacks).

* The default DB engine is likely to be MySQL/InnoDB with support for transactions.

* The DB layer is "very" low-level and doesn't check security concerns (e.g. can the user modifies that object?). This must be handled by the above layer, usually DataObj and MetaField.

TODO: an audit of the current DB code to remove un-needed/deprecated methods, to re-organise the required existing methods.

==Data Representation==

This defines properties for data objects (for example the "name" of a user) and offers a layer between the raw data (handled by Database) and the application/views using the data (e.g. CRUD, "the" UI, Export/Import plug-ins etc).

Important: data objects and metadata fields do not know how to render themselves on a UI. This is one of the main design aspect of EPrints4 as to remove dependencies of the UI on the data model.

===Metadata fields===

* make sure the data is valid, according to the type's constraints. For instance, you cannot store a string into an integer

* maps any higher level type (e.g. URL) to a low-level DB type (e.g. varchar)

* must provide a clean and clear API to easily modify data (set_value, add_value etc)

* the type "file" whilst not being a piece of metadata directly is nonetheless a valid field - it is the only type that links data to a stored file (rather than being purely DB data).

* XML/SAX handlers are likely to be kept at the Meta-Field level (because this makes sense)

* aspects such as indexing, generating order values are more likely to be included in the Search components (so via Xapian for instance)

* review of the existing types is needed (40ish types at the moment) and non-core types must be removed (recaptcha, compound...)

===Data set / Data objects===

* DataSet/Objects are collections of metadata fields and offer an API for easily manipulating objects/data.

* Dataset offers a number of properties to handle common fields/concepts in a consistent manner across different datasets. For instance the "lastmod" property which is an internal field always set to when the object was last modified or "history" which keeps track of the modifications of the object. Considered properties:

** "states": the graph of states for that object. Similar to "eprint_status" for "eprint" objects in EPrints2/3. Automates and generalises state transfer for objects.

** "revision": keep the revision number which is incremented each time that object is modified (default: ON)

** "acl": enables the ACL related fields and permission checking (TODO)

** "cache": enables the use of memcached (default: ON if globally enabled) - if enabled, keep a copy of data objects in memory rather than reading objects from DB.

** "read-only": makes that data-set read only and forbids any modification/deletion (default: OFF)

** "history": keeps an XML diff of the modifications made to that object. (TODO)

** "lastmod": keeps a last modified field

** "datestamp": the date at which the object was created

* EPrints::DataObj now contains all required information so that custom datasets do not need to have their explicit implementation (EPrints::DataObj::Foo package)

EPrints4 Core Roadmap

2014-02-06T14:54:34Z

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

EPrints4 Core Roadmap

2014-02-06T14:45:50Z

Sf03r@ecs.soton.ac.uk: /* Request Handler / Page Controllers */

EPrints4 Core Roadmap

2014-02-06T14:39:42Z

Sf03r@ecs.soton.ac.uk: Created page with '=EPrints4 Core Development= Trying to divide the work into smaller tasks (and questions where relevant). ==Request Handler / Page Controllers== This deals with how HTTP reques…'

EPrints4 Roadmap

2013-11-18T16:37:44Z

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

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

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

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

* 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

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

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

* 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

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

EPrints4 Roadmap

2013-11-18T16:15:31Z

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

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

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

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

* 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

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

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

* 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

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

EPrints4 Roadmap

2013-11-13T17:14:34Z

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

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

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

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

* 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

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

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

* 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

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

EPrints4 Roadmap

2013-11-06T14:15:24Z

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

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

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

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

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

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

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

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

* (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==

* 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

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

EPrints4 Roadmap

2013-11-06T14:09:00Z

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

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

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

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

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

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

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

* 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

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

EPrints4 Roadmap

2013-11-06T14:00:35Z

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

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

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

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

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

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

* 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

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

EPrints4 Roadmap

2013-10-28T11:24:57Z

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

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

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

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

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

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

* 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

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

EPrints4 Roadmap

2013-10-25T18:58:19Z

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

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

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

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

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

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

* 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

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

EPrints4 Roadmap

2013-10-25T18:52:14Z

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

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

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

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

* 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 (lots of hard-coded paths, many obsolete paths)

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

* 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

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

EPrints4 Roadmap

2013-10-25T18:51:30Z

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

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

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

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

* 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 (lots of hard-coded paths, many obsolete paths)

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

* 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

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

EPrints4 Roadmap

2013-10-25T18:49:05Z

Sf03r@ecs.soton.ac.uk:

EPrints4 Roadmap

2013-10-25T18:45:51Z

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

EPrints4 Roadmap

2013-10-25T18:44:42Z

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

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

* Test using memcached (http://code.google.com/p/memcached/) - Cache::Memcached::Fast to cache data objects, perhaps could work to cache XML fragments too.

* 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

* CSS3 Responsive design to support small screens (mobile, tablets etc) - http://alistapart.com/article/responsive-web-design

EPrints4 Roadmap

2013-10-25T17:26:07Z

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

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)

* 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

* Test using memcached (http://code.google.com/p/memcached/) - Cache::Memcached::Fast to cache data objects, perhaps could work to cache XML fragments too.

* 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

* CSS3 Responsive design to support small screens (mobile, tablets etc) - http://alistapart.com/article/responsive-web-design