EPrints4 Status

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!