Page History

...

• What may a "Common Business Logic API" look like? Can we build an API that makes it easier for new DSpace UIs to be built?
• Are there ways we could simplify DSpace ("Do one thing and do it well")? This could be at any level (Object Model, API, User Interface, etc.)
• How could we move towards "Metadata on All Objects" (i.e. Not just metadata for Items, but also for Bitstreams, Communities & Collections)?
• What other ways can we start to "Modernize" DSpace at all levels (Object Model, API, User Interface)?
  • As a potential starting point in modernizing DSpace's API see Richard Rodgers' work on GitHub: https://github.com/richardrodgers/mds
• "App Store" or "Sharing Code": How do we work to better share custom code like custom curation tasks, themes, etc. amongst those in our community?
• "DSpace Virtual Hack-a-thon": Could there be a way to hold a virtual hackathon, as a way of rapidly prototyping/developing out ideas in the span of a week or two?
• How to manage ongoing translations of DSpace? This has become harder & harder as we have increased the number of messages.xml files (Discovery, SWORD Client, etc).
  • Should we rethink this direction or look towards Translation Management software, like Pootle (doesn't work for XML messages though) or similar.

Summit Meeting Notes

Day #1 Notes (Feb 27)

Attendees: Kevin Van De Velde, Graham Triggs, Peter Dietz, Andrea Schweer, Kim Shepherd, Hardy Pottinger, Mark Wood, Tim Donohue

...

• Interaction/Code Share via GitHub.
  • Can we come up with some best practices for forking GitHub, so that we can all start to share code more easily? I.e. allow institutions to pull in code from one another, etc.
  • We may need to spend some time developing some GitHub best practices.
  • We should also leverage Maven to obviously create separate GitHub projects for features that can just extend DSpace API, etc.
• Business Logic API discussion led into talking about REST API as a potential area for this "common business logic"
• REST API - Who is using it? What should it do, and how should it interact with SWORD / Solr / etc.
  • No one in attendance is using REST API in Production (though a few have used it for development)
  • We should try and "show it off" more by writing some simple Javascript "embed" code to embed DSpace Content in a website. We can post that code up to http://demo.dspace.org and enable the REST API there. This could also allow for more testing.
  • REST API should never create its own 'conventions' for common tasks. Rather it should use existing standards (e.g. SWORD for deposit, etc)
  • Question: Should REST API "wrap" things like SWORD & Solr (which can be accessed RESTFully themselves)? Could "RESTFul" DSpace just be a combination of SWORD + Solr + Admin REST API + other RESTFul interfaces?
    • Several in disagreement here. Pros/Cons to various approaches
    • Fedora actually has a separate REST API from Browse/Search. You Browse/Search via RSearch, and then lookup an item by ID via REST API. This approach allows you to simplify the REST API to very specific tasks, and use other existing services/interfaces where they are more 'standard' or widely accepted.
    • However, AuthZ is may be simplified if you 'wrap' everything (even with a thin wrapper).
    • Also if you 'wrap' the Search/Browse in REST API, then at a later time you could swap out Solr (or whatever) for something like Elastic Search, and your clients would not need to change.

...