Page History

...

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. Jira
         server DuraSpace JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key DS-1942

      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. Jira
         server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key DS-1115

          (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: 

      Jira
      server DuraSpace JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key DS-1582

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

...