DSpace Developers Virtual Summit (Feb 27 to Mar 2)

Why a "Virtual Summit"?

We've often heard feedback that DSpace Developers just don't get enough time to sit down (face-to-face or otherwise) to discuss larger topics or brainstorm out future ideas for the DSpace platform. Our weekly DSpace Developers Meetings just don't allow for enough time to dig deeply into big topics, and there is sometimes a limit to how much we can discuss via text chat (IRC). Often the only time we are able to discuss larger topics in detail are at the Open Repositories (OR) conference.

The idea is that this "Virtual Summit" will be a form of DSpace "unconference", bringing developers around the world together in a virtual fashion via either audio or video technology. Those in attendance will decide the topics, but we have provided some suggested "hot topics" (which have come up frequently in the past) below.

All discussions will also be fed back to the general public. We'll take notes and send those notes back to everyone on dspace-devel listserv. This allows for non-attendees to also provide feedback throughout the Summit (and afterwards).

If all goes well, we may hold these Virtual Summits a few times a year. We also could brainstorm whether it'd be possible to hold a "Virtual Hack-a-thon" to rapidly develop/prototype out ideas that were brainstormed during the Summit.

Who is invited?

• All Committers,
• Any other interested DSpace developers or technology-savvy individuals

At least initially, this summit is geared towards developers, as discussion will primarily revolve around the existing codebase & internal architecture. However, discussions from this summit will be forwarded out to the community for broader feedback at all levels (repository manager, user, developer, etc.).

If you don't fall into one of the above categories, you are still welcome to attend. However, be warned that discussion will likely get very technical at times (which is why we recommend you be a developer or have a technology background).

Logistics

• When: Meetings will happen daily starting at 20:00UTC and last for 1-2 hours apiece. _We will attempt to keep discussions to about 1 hour in length. But, if topics run over and people have time to continue, we may extend beyond that.
• Where:
  • Call in via Skype or Phone line - See #Connection Instructions below
  • In addition, #duraspace IRC will be utilized as a discussion "backchannel" – to share links to current discussion topics/ideas, and potentially even take notes.
• Attendance Limit: None.
• Daily Notes: Each day we will have a notetaker. Similar to OR11, we may wish to take notes publicly via IRC or PiratePad. Meeting notes will be sent to 'dspace-devel' listserv after each meeting, in order to allow for broader community feedback.

Connection Instructions

You can call in via either Skype or via your Phone. This call will be audio-only. We will also use the #duraspace IRC as a discussion "backchannel" (to share links, etc.)

Via Phone:

• Dial-in Number: (805) 399-1200
  • Participant Code: 929807#

Via Skype:

1. Search and Add Contact: "freeconferencecallhd.8053991200"
   • Copy and paste freeconferencecallhd.8053991200 (the entire name) into your contact search area
   • add as a contact
2. After freeconferencecallhd.8053991200 is listed in your contact list, simply call that contact.
3. Enter the participant code through the Skype keypad (not by just typing in the numbers on your keyboard): 929807# (you will prompted to add the # sign).
   • Mac Users: The Skype Keypad can be found at the top of your call window (look for the little phone keypad icon).
   • Windows Users: The Skype Keypad is unfortunately hidden under the Call -> Show Dial Pad menu

More info on Skype connections also available at: http://www.freeconferencecallhd.com/skypeinstructions.html

Potential Discussion Topics

The following topics are just possible topics we may wish to discussion. Topics need not be limited by this listing, and others can feel free to add topics they feel may be important.

In no particular order:

• 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

Primary Discussion topics:

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

We took notes via IRC. So, the full notes are up in IRC chatroom: http://irclogs.duraspace.org/index.php?date=2012-02-27

Day #2 Notes (Feb 28)

Attendees: Kevin Van De Velde, Mark Wood, Andrea Schweer, Richard Rodgers, Scott Phillips, Mark Diggory, Hardy Pottinger, Peter Dietz, Tim Donohue

Primary Discussion topics:

• Revisiting REST API Discussion
  • Seems to be an assumption that we should only have one REST API
  • No reason why we cannot have multiple APIs, or even different implementations (and let the best one win out in the end)
  • Revisiting whether one REST API should 'wrap' all calls. Tim noticed Twitter (and many other sites have many many REST APIs)
    • https://dev.twitter.com/docs - Twitter specifically has a basic REST API, Search API, Streaming API, etc. They even do OAuth / AuthZ via REST API.
• Business Logic API
  • Can we "mature" design/modeling of the Business Logic API by thinking of it more as a REST API?
  • Services that would be part of a Business Logic API:
    • Item Submission processes (special ingest workflow)
    • Reviewer Workflow processes
    • Creation processes for Collections / Communities (also includes initializing roles, template items, etc. – almost like a "workflow" process to create these objects)
    • Creation processes for Groups / EPeople?
    • Running Curation Tasks - Richard Rodgers notes he's already building a demo REST API for Curation Framework using Jersey (http://jersey.java.net/). This will be posted to GitHub in near future
    • Smaller Activities: User feedback, Statistics, metadata registry, bitstream format registry
    • Authority Control? (managing internal or external controlled vocabularies & taxonomies)
  • Questions / Concerns on Business Logic API
    • Need to avoid it being too "large" / all-encompassing.
    • Where do we draw the line between underlying "DSpace Business Logic" and UI? E.g. Is Search/Browse part of Business Logic API? Or is it a separate API?
      • Mentioned that DSpace Discovery Module has been made more generic (no longer Solr specific) – may be the basis for a separate "Search API"?
• REST API usage of Sakai bus
  • Are we satisfied with the Sakai-based REST implementation? Sounds like several have concerns about complexity & ongoing maintanence
  • May need to work towards a new implementation – based on Spring WebMVC or something else (Apache CXF? Jersey?)
  • Should be able to still reuse much of existing REST API work – especially the modeling of DSpace Objects as Resources bound to URLs
• Mobile Device Support - DSpace is lagging behind. How do we plan to move in this direction?
  • Several seem interested in this, but no one known to be working directly on it.
  • Two levels of mobile support: (1) Making current UIs more 'mobile friendly' , (2) making DSpace more RESTful to support building native apps/clients
    • http://en.wikipedia.org/wiki/Responsive_Web_Design

We took notes & shared additional links via IRC. http://irclogs.duraspace.org/index.php?date=2012-02-28