Versions Compared

Old Version 53

changes.mady.by.user Tim Donohue

Saved on

compared with

New Version 54

changes.mady.by.user Tim Donohue

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • Filling out / Approving the #Actionable Takeaways list below
  • Helping new Developers / Users get started (brief discussion)
    • Can we get some better documentation or user training in place for new users & new developers?
    • Put some basic install instructions up on GitHub too (once we migrate – which seems definite now)
  • Advanced Embargo Feature
    • Being talking about at the next DCAT meeting to make sure it meets community requirements
    • Committers should discuss in more detail in future as well – possible 3.0 feature.
  • Higher Level Discussion of what encompasses "DSpace"
    • This began on Dabbleboard whiteboard but ran into some technical issues (multiple editors at same time cause it to get confused).
    • General Goal: Simplify the 'dspace-api' module! As much as possible it really should just be the DSpace Data Model / Kernel. There are many "pieces" that should be refactored out of 'dspace-api' in future (hopefully as part of Modernized DSpace work)
    • Things that could/should be refactored out of 'dspace-api':
      • Content Manipulation (Curation Tasks) -> includes both curation tasks themselves and MediaFilters (which likely should be rewritten as Curation tasks anyways)
      • Ingesters/Disseminators -> includes both packagers and crosswalks
      • Usage Statistics (it's already separate in Solr Stats)
      • External Identifier Services (ala Dryad – see below)
      • Versioning Services (ala Dryad)
      • Usage Event Services?
      • Search / Browse API (already separate in Discovery)
  • Dryad Project codebase
  • Feedback on Summit
    • Positive overall. Many like the voice chat (easier to cover larger topics)
    • A week is too long? 3-4 days is "sweet spot".
    • Maybe we should start having occasional meetings via Skype? e.g. once per month? or just "Special Topic Meetings"?

Actionable Takeaways

These are final takeaways from the discussion notes above. We've tried to assign these to one or more people when we could, but some are just 'philosophical' takeaways (in how we plan to move the platform forward). For more details on each takeaway, see the discussion notes above.

  • REST API
    1. Look to replace Sakai bus implemenation with something else (Spring WebMVC?) – Unassigned (though Mark Diggory & Bojan Suzic have been discussing)
    2. Install REST API on http://demo.dspace.org (allows for more testing/visability, etc) – Unassigned (Tim can take if no one else has time)
    3. Create some "embed this" Javascript code that goes against REST API – (Assigned: Peter Dietz with help from others)
    4. "RESTFul DSpace" philosophy:
      • Individual REST APIs should stay simple & not attempt to replace/rewrite any existing standards (e.g. SWORD).
      • We should encourage multiple RESTful interfaces (similar to Twitter). For example, Search/Browse API may likely be separate from the basic REST API.
      • We should also encourage multiple implementations (as necessary), with an eye towards choosing a "best in class".
  • Discovery
    1. Prototype whether Elastic Search can be used as an alternative to Solr. (Assigned: Kevin Van De Velde)
    2. Vote on whether Discovery should become default or even "only" Search/Browse mechanism in future. (Tim & all)
  • Maven Project Consolidation
    1. Document our new standard Maven Project structure (SWORD2 is the model). Eventually this should go under: Advanced Customisation
    2. Test to ensure this new consolidated structure still works well with major IDEs
    3. Actually consolidate existing Maven subprojects (e.g. XMLUI and JSPUI subprojects) to use this new structure (Assigned: Mark Diggory with help from others)
  • Mobile Device Support
    1. Look to better optimize our existing UIs for mobile devices (a vague task) – Unassigned
      • Andrea Schweer knows of folks who are working on making Mirage Theme more Mobile friendly. Hopefully they can give that work back, if it can be made generally useful.
    2. Hope that a stable set of REST APIs can let others build native client apps or mobile-tailored UIs (e.g. ClientUI project (from GSoC 2011))
  • Metadata for all Objects
    • Takeaways were not very specific. Just that this is important, and that there are use cases for having metadata on Bitstreams, Communities & Collections.
  • Modernized DSpace
    1. This is an important project which many seem to be watching closely. Important to keep it moving forward (All of us).
    2. "DSpace Kernel/API" philosophy:
      • We should strive to simplify the Kernel. It has gotten bloated over time, and we should work to separate out individual "functions" into other APIs. This will be an ongoing process, but it falls to all of us.
  • Business Logic API
    1. Bring some of the related Dryad work out into more public areas (GitHub? Wiki?) – Mark Diggory with Ryan Scherle
    2. Investigate whether WebMVC code could be the basis for some of the Business Logic API (Mark Diggory and many others)
  • Dryad Codebase -> Possible 3.0 Features
    1. Dryad has several major features (Versioning & External Identifiers) that would be very flashy for 3.0. We need to start looking more closely at this work, and get a team of us working on bringing it into 3.0. (Assiged to All in coming weeks)
    2. Pester MarkD & @mire (in a nice way) to help get this Dryad code documented so that the Committers can begin helping to make it generalizable.
  • GitHub Migration
    1. We will turn off the "issue tracker" as we don't want to confuse folks. We want all issues logged in JIRA.
    2. We likely may want to enhance the README to be more helpful / perhaps even provide some quick install hints (along with links to install docs, etc.)
  • Virtual Summit itself
    • Mostly positive feedback so far (Send your feedback to Tim!)
    • In future, may want to hold Summit from Mon-Thurs (4 days) or Mon-Weds. The Friday meeting is harder as it ends up being Friday evening in Europe/UK & Saturday morning in NZ.
    • Regularly Scheduled Summit?
      • Once a year? e.g. January/February
      • Twice a year? e.g. January & May/June
      • Three times a year? e.g. January, May & Sept