EPrints4 Status

From EPrints Documentation
Jump to: navigation, search

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)