Developers Meeting on Weds, March 19, 2014

Let's Talk About Features!

This entire meeting will be devoted to discussion/brainstorming of possible new features to add to DSpace 5.0 (and beyond).

The purpose of this meeting is to share and discuss:

• New DSpace features you or your institution are already working on (or may have already completed) 
• New DSpace features or ideas you'd love to collaborate with others on
• Anything you'd like to "give back" to the community and donate to the next release of DSpace (version 5.0 scheduled for late 2014)

It is an opportunity to share your ideas or half-finished code with other DSpace developers and committers (and get early feedback or find collaborators). It's also an opportunity to brainstorm new collaborative projects, and/or locate others developers who may want to help you turn your idea into code.

We plan to hold these "Let's Talk About Features" meetings on the third Wednesday of the month, up until the DSpace 5.0 Feature Freeze (date TBA - likely Sept or Oct)

Agenda

Feature Discussions / Brainstorms

1. Bitstream Format-dependent  streaming / pseudo-streaming (Jason Sherman)
   1. General Idea:

      1. For my small library, pseudo-streaming is enough, and it's really only necessary for video and audio formats. It would be trivial to add a mime-type check into the current byte-range code. This would get around the PDF reader problem.

      2. Why not add either add a boolean value to the format registry or have a variable in dspace.cfg that enables streaming/pseudo-streaming for specific bitstream formats? There could also be a variable in dspace.cfg to choose between no streaming, pseudo-streaming, and real streaming.

      3. If institutions who would like to use a real streaming server would like/need to choose which bitstream formats get streamed for bandwidth concerns, I would favor adding the boolean to the format registry; if choosing how to served based on format is only desired/necessary for pseudo-streaming, then I would just stick it in dspace.cfg.

   2. Any code yet?
      1. DSPR#504. So far I've implemented the basic idea in xmlui.
   3. Related Links/Discussions
      1. Unable to locate Jira server for this macro. It may be due to Application Link configuration.
      2. Discussion from 2014-02-12 Developer Meeting (Streaming discussion starts around [20:50] in the logs)

      3. Audio/Video Streaming (RTMP, HLS, DASH) Support (This is more about "real server streaming" than pseudo-streaming)

      4. Unable to locate Jira server for this macro. It may be due to Application Link configuration.  (Again, more about "real server streaming")
2. Metadata for all DSpaceObjects (Mark H. Wood)
   1. General Idea:  Item-like metadata support for all DSpaceObject subclasses.  The focus here is on simply reworking the code so that every DSO concrete type has consistent metadata methods which are used throughout, all backed by the
      MetadataValue table instead of object record fields (as has been the case with e.g. Community and Collection).  Once this is in place, we can do other projects to take advantage of this for things like multiple abstracts in different languages.
   2. Any code yet?  DSPR#486, a work in progress.
   3. Related Links/Discussions:  Unable to locate Jira server for this macro. It may be due to Application Link configuration.
3. Never prompt Site-visitors (as opposed to Content Contributors and Administrators) to login.  Monika Mevenkamp
   1. Use Case at Princeton:  We have OA content and IP restricted content that should be available to everybody or everybody on campus. We do not ever want Site Visitors to be prompted to login on the other hand we do need Administrators and Content Submitters to be redirected to our authentication system. In our case I solved the issue by changing DSPaceServlet to not try to Authenticate further inside handle-request
4. Configure Items/Collections/Communities with a Usage Agreement that is shown before Bitstreams Monika Mevenkamp
   1. Use Case at Princeton: We have Student generated content in our collections that we do not want that readers share them widely. As a minimal protection we make readers agree to the usage terms before getting bitstreams to them 
   2. My post to [Dspace-devel] 'show agreement  before  responding with bitstream' describes the implementation   
5. If you have a feature Idea or code that you wish to add to the discussion, either add it here or email Tim Donohue

Meeting Notes

Meeting Transcript

• Full IRC Transcript is available at - http://irclogs.duraspace.org/index.php?date=2014-03-19

Action Items

(Action items go here, if any)