Timestamps are in GMT/BST.
[6:32] -dickson.freenode.net- *** Looking up your hostname...
[6:32] -dickson.freenode.net- *** Checking Ident
[6:32] -dickson.freenode.net- *** Found your hostname
[6:32] -dickson.freenode.net- *** No Ident response
[6:33] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:33] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:33] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[11:13] * kshepherd2 (~kim@121-99-157-35.bng1.nct.orcon.net.nz) has joined #duraspace
[11:36] * kshepherd2 (~kim@121-99-157-35.bng1.nct.orcon.net.nz) Quit (Ping timeout: 240 seconds)
[11:42] * kshepherd2 (~kim@121-99-157-35.bng1.nct.orcon.net.nz) has joined #duraspace
[11:56] * kshepherd2 (~kim@121-99-157-35.bng1.nct.orcon.net.nz) Quit (Ping timeout: 246 seconds)
[12:03] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[12:45] * kshepherd2 (~kim@121-99-157-35.bng1.nct.orcon.net.nz) has joined #duraspace
[13:02] * tdonohue (~tdonohue@c-50-179-112-246.hsd1.il.comcast.net) has joined #duraspace
[13:34] * kshepherd2 (~kim@121-99-157-35.bng1.nct.orcon.net.nz) Quit (Ping timeout: 264 seconds)
[13:55] * hpottinger (~hpottinge@mu-160123.dhcp.missouri.edu) has joined #duraspace
[14:46] * linux4u (~james@employed.library.emory.edu) has joined #duraspace
[16:42] * edInCo (~smuxi@seta.coalliance.org) has joined #duraspace
[17:22] * edInCo (~smuxi@seta.coalliance.org) Quit (Remote host closed the connection)
[17:22] * edInCo (~smuxi@seta.coalliance.org) has joined #duraspace
[19:00] <tdonohue> Hi All, our first official DSpace "Let's Talk about Features" meeting is starting now. Agenda for today: https://wiki.duraspace.org/display/DSPACE/DevMtg+2014-03-19+-+Let%27s+Talk+About+Features
[19:00] <kompewter> [ DevMtg 2014-03-19 - Let's Talk About Features - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2014-03-19+-+Let%27s+Talk+About+Features
[19:01] <tdonohue> As we have a lot of feature discussions that have been added to this agenda, I'm not sure if we'll get to *all* of them today. But I'm going to do my best to keep us "on time"
[19:02] <tdonohue> First feature up is "Bitstream Format-dependent streaming / pseudo-streaming" suggested by jsherman. Some early code at DSPR#504
[19:02] <kompewter> [ https://github.com/DSpace/DSpace/pull/504 ] - Per format pseudo streaming DS-1942 by jsnshrmn
[19:02] <mhwood> I thought this was at 20:00 UTC.
[19:03] <tdonohue> oh, crud. I have my time wrong, don't I?
[19:03] <tdonohue> no wonder
[19:03] * hpottinger sighs in relief
[19:03] <hpottinger> so, backlog hour, go go go
[19:03] <tdonohue> duh, it's 19:00UTC still, and my personal calendar is wrong
[19:04] <tdonohue> thanks for the reminder, mhwood. :)
[19:04] <mhwood> I used to get confused too. Then I stuck another xclock on my desk, set to UTC.
[19:05] <PeterDietz> I'll take a moment to think about new features I'd like to tackle. Perhaps Read/Write REST API is on my shortlist
[19:05] <hpottinger> perhaps?
[19:05] <hpottinger> put the CUD back in CRUD
[19:05] * tdonohue notes this "Let's talk about features" meeting will resume at the appropriate time (in about 55 mins at 20:00UTC)
[19:06] <hpottinger> oh, OK
[19:06] <hpottinger> over to #dspace for backlog hour?
[19:06] <tdonohue> But, we can still do informal discussion or backlog review now... I'm not meaning to pause *all* discussions. Just noting that the official meeting shouldn't begin yet
[19:07] <tdonohue> sure, over to #dspace for the next 54 mins until meeting time
[19:51] * Jonathan__ (596578eb@gateway/web/freenode/ip.89.101.120.235) has joined #duraspace
[19:52] * monikam_ (~Monika_Me@monika.Princeton.EDU) has joined #duraspace
[20:00] <tdonohue> Hi All, our first official DSpace "Let's Talk about Features" meeting is starting now. Agenda for today: https://wiki.duraspace.org/display/DSPACE/DevMtg+2014-03-19+-+Let%27s+Talk+About+Features
[20:00] <kompewter> [ DevMtg 2014-03-19 - Let's Talk About Features - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2014-03-19+-+Let%27s+Talk+About+Features
[20:00] <tdonohue> As we have a lot of feature discussions that have been added to this agenda, I'm not sure if we'll get to *all* of them today. But I'm going to do my best to keep us "on time"
[20:00] <tdonohue> First feature up is "Bitstream Format-dependent streaming / pseudo-streaming" suggested by jsherman. Some early code at DSPR#504
[20:01] <kompewter> [ https://github.com/DSpace/DSpace/pull/504 ] - Per format pseudo streaming DS-1942 by jsnshrmn
[20:01] <tdonohue> (I'll give you all a moment to catchup. I just pasted in a lot)
[20:02] <tdonohue> It looks like Jason Sherman isn't here today (unless he's under a pseudonym or not yet arrived). But, as this discussion is logged, we can always pass it his way later on.
[20:04] <mhwood> We may need to add a paragraph to our hardware requirements, if people start streaming out of the DSpace box. First we'll need some experience to know what to say, though.
[20:04] <tdonohue> So, any thoughts on Jason's idea and/or early code? I know this is of high interest, as there has been a lot of related discussions about supporting a streaming server. Jason's idea seems to be to provide a way to do minimally "pseudo-streaming" but had a "hook" for full streaming
[20:05] <tdonohue> s/had/add/
[20:05] <kompewter> tdonohue meant to say: So, any thoughts on Jason's idea and/or early code? I know this is of high interest, as there has been a lot of related discussions about supporting a streaming server. Jason's idea seems to be to provide a way to do minimally "pseudo-streaming" but add a "hook" for full streaming
[20:06] * edInCo (~smuxi@seta.coalliance.org) Quit (Write error: Broken pipe)
[20:06] <PeterDietz> I know that kshepherd has been digging into streaming, last I heard
[20:07] <mhwood> What level of detail are we discussing here? I have some thoughts about representing "streamability" in the database....
[20:07] <tdonohue> yes, kshepherd has been digging into streaming -- but he's been doing more of the full streaming (with a backend streaming server) idea. What I like about Jason's idea here is that it *could* also possibly work for institutions that really only need/want "pseudo-streaming"
[20:08] * edInCo (~smuxi@seta.coalliance.org) has joined #duraspace
[20:09] <tdonohue> mhwood: I think we can discuss it at any of those levels. Since this is more than just a "concept" (it also has sample code), I think feedback on the code is also warranted
[20:09] <hpottinger> I'd like to know if Jason is running this code in production
[20:09] <hpottinger> and if so, if we can "kick the tires"
[20:09] <mhwood> OK, rather than just a "streamable" flag, a URL. "internal:" or a base URL to an external streamer. This probably needs more thought.
[20:09] <hpottinger> http://tinyurl.com/dspace-streaming
[20:10] <kompewter> [ Audio/Video Streaming (RTMP, HLS, DASH) Support - DSpace - DuraSpace Wiki ] - http://tinyurl.com/dspace-streaming
[20:10] <tdonohue> hpottinger: From my emails with Jason, it sounds like he is not (yet) running this in production. He notes in the PR that it's a "work in progress"
[20:11] <tdonohue> mhwood: so you think each format needs its own URL for streaming? Not sure I understand the URL comment
[20:11] <hpottinger> I think Keith Gilbertson is running a variation of this (without the "streamable" flag)
[20:12] * aschweer (~schweer@schweer.its.waikato.ac.nz) has joined #duraspace
[20:12] <tdonohue> hpottinger: if so, that'd be good to know. I wasn't sure if anyone was doing this pseudostreaming in production yet
[20:12] <mhwood> Just a first thought about handling "real" vs. "pseudo" streaming. I haven't really given it enough thought, but the simple flag seemed too inflexible.
[20:13] <mhwood> I should go stare at code.
[20:13] <tdonohue> mhwood: the "streamable" flag in the database isn't for "real" vs. "pseudo". It's actually to flag which File Formats you want to make *streamable* in your DSpace. Or at least that's my understanding
[20:14] <mhwood> But then you have to say elsewhere how you stream. Perhaps, how you stream *this format*.
[20:14] <tdonohue> mhwood: but, you are correct, there may need to be a configuration (dspace.cfg) which specifies the URL / Base URL where the streaming occurs (based on whether it is real or pseudo)
[20:15] <mhwood> It gets worse. Someone is sure to ask: can I make this format streamable in some collections and not others? Can I override streamability per-Item? per-Bitstream?
[20:15] <Jonathan__> I actually had something similar
[20:15] <Jonathan__> for restricted items
[20:15] <Jonathan__> make the content streamable
[20:15] <Jonathan__> restricted bitstreams*
[20:16] <tdonohue> mhwood and Jonathan__ : good points. We'd need to likely set some initial boundaries here though... I'm not sure we'd want to open up the entire "can of worms" all at once
[20:17] <hpottinger> link to the discussion thread about this area of the code: http://dspace.2283337.n4.nabble.com/Psuedo-video-streaming-with-item-attachment-and-seeking-enabled-td4662291.html#a4662339
[20:17] <kompewter> [ DSpace - Tech - Psuedo video streaming with item attachment and seeking enabled ] - http://dspace.2283337.n4.nabble.com/Psuedo-video-streaming-with-item-attachment-and-seeking-enabled-td4662291.html#a4662339
[20:17] <mhwood> Well, I could go on making up requirements, but it would be good to hear from people who have *actual* requirements.
[20:19] <tdonohue> The requirement to allow streaming of some restricted bitstreams (so you could view but *not* download) is probably a good use case to keep in mind. Almost makes me wonder if we need the ability to just say "make *this* Item or Bitstream streamable". Though you wouldn't always want to specify it one-by-one
[20:19] <hpottinger> pseudo streaming, with restricted items, you'll still end up with a file on the client after they've "viewed" the stream
[20:20] <tdonohue> hpottinger: true. pseudo-streaming won't work for restricted items/bitstreams. For that you need full/real streaming
[20:20] <tdonohue> So, I want to wrap up the discussion on this first topic as best we can. Next steps?
[20:21] <tdonohue> * Sounds like we want to know if anyone is using pseudo-streaming in production yet.
[20:21] <mhwood> Lots of answers to "if you had this, how would *you* use it?"
[20:21] <mhwood> Rather "how would you *want to* use it?"
[20:21] <tdonohue> * Sounds like we need to gather some use cases / requirements for both pseudo-streaming and real-streaming, and start to determine the similarities and differences
[20:22] <hpottinger> I like the idea that there's code here to test, I'd like to know more about the "nitty gritty" details
[20:22] <mhwood> Yes.
[20:22] <mhwood> Yes, tdonohue.
[20:23] <tdonohue> Ok, so that seems like some good initial feedback here. I wonder, is kshepherd "leading" these streaming discussions in any way? Perhaps we try and ping him, and also start getting use cases documented on his page, etc.?
[20:23] <hpottinger> I don't think kshepherd would mind if we used part of the "real streaming" page to talk about use cases for both real streaming and pseudo streaming
[20:24] <tdonohue> Cause to me, it looks like we have some interesting / promising "starts" from both Jason and kshepherd. Just a matter of more analysis of use cases to find a way forward
[20:24] <hpottinger> kshepherd was thinking of using Trello to manage the streaming work
[20:25] <Jonathan__> One of the problems I always had with thinking about video/audio storage is you may have it in certain formats which are great for preservation but not ideal for streaming
[20:25] <mhwood> Curation issue.
[20:26] <tdonohue> Ok. I can take the task of copying/linking these notes into Jason's ticket, and also trying to make kshepherd aware of this parallel "pseudo-streaming" work (if he doesn't notice all these mentions of his name in IRC)
[20:26] <hpottinger> Jonathan__: right, and do derivatives really warrant the same care we give to originals?
[20:26] <mhwood> You want efficient streaming, you transcode to a derivative format that makes it so.
[20:27] <mhwood> Thanks, tdonohue, that sounds good.
[20:27] <tdonohue> In the essence of time, I suspect we need to move along here to next feature topic. As it is, I'm doubting we'll make it through all these topics today.
[20:27] <tdonohue> So, the next topic is "Metadata for all DSpaceObjects" from mhwood
[20:28] <tdonohue> started at DSPR#486
[20:28] <kompewter> [ https://github.com/DSpace/DSpace/pull/486 ] - [DS-1582] All DSpaceObjects should have metadata support by mwoodiupui
[20:29] <mhwood> This is just building out the infrastructure. I'm deliberately not changing the treatment of e.g. Collection blurbs at this time.
[20:29] <tdonohue> I think this concept (Metadata for all objects) in general is much needed / much desired
[20:30] <mhwood> I know I found a need for it. There are some ugly lists of Community and Collection IDs that might be able to go away....
[20:30] <monikam_> q102 changed files - are most of the changes sort of mechanical aka GetMetada("name") instead of GetName()
[20:30] <mhwood> In the dspace.cfg that is.
[20:30] <tdonohue> My only big question here is whether there are similarities with KevinVdV's "Hibernate / Metadata on all Objects" work (https://github.com/KevinVdV/dspace-hibernate-datamodel)? Or are these two implementations of the same thing?
[20:30] <mhwood> Much of it has been mechanical.
[20:31] <monikam_> wait - how do you make these lists go away ?
[20:31] <tdonohue> https://github.com/KevinVdV/dspace-hibernate-datamodel
[20:31] <kompewter> [ KevinVdV/dspace-hibernate-datamodel · GitHub ] - https://github.com/KevinVdV/dspace-hibernate-datamodel
[20:31] <mhwood> Is Kevin reworking metadata too?
[20:32] <tdonohue> mhwood: I only have a vague understanding (from discussions with Lieven at @mire), but I heard mention of data model changes to also support "metadata on all"
[20:32] <mhwood> monikam_: Set a metadata value on e.g. a Collection, then look for it.
[20:32] <hpottinger> mhwood: I think there is an intention to do so, I don't think he's done it yet
[20:32] <tdonohue> mhwood: so, we may need to talk more with KevinVdV to understand whether there are overlaps and/or whether these two ideas can be "merged" in some way
[20:33] <mhwood> Certainly they have to touch the storage of DSpaceObject concrete classes while redoing the database access.
[20:34] <hpottinger> there's definitely room for collaboration, I'm glad you mentioned @mire's work, tdonohue, I kinda wish they were here to talk about it
[20:34] <mhwood> Me too.
[20:34] <tdonohue> It seems like, if we have two developer types both interested (in KevinVdV and mhwood), along with others helping do review/chip in, then we should be able to hopefully move this forward (hopefully more quickly)
[20:35] <hpottinger> if anyone out there has an itch to play with Hibernate and DSpace, check out KevinVdV's work
[20:35] <tdonohue> So, maybe what we need to do with this topic is to (1) reach out to @mire/KevinVdV about mhwood's work -- make them aware of it, and (2) find a future meeting where we can all devote more time to discussion, hopefully with both mhwood and KevinVdV in attendance
[20:35] <monikam_> once there is metadata on all objects - would it make sense to rework authorization as metadata - that way it would be easy to export/import
[20:36] <mhwood> We could look at that. But the structure of authorization data is kind of specialized.
[20:36] * jsherman (a43a1787@gateway/web/freenode/ip.164.58.23.135) has joined #duraspace
[20:36] <tdonohue> Personally, I think the concepts behind both mhwood's work and KevinVdV's work are good ones. I just would rather find a way to collaborate, rather than seemingly work in parallel
[20:36] <hpottinger> monikam_: I'm not sure about "metadat" per se, but, Hibernate can tie in to the frameworks I'm looking at for replacing AuthN/Z
[20:36] <mhwood> There are layers and layers of stuff to be done on metadata handling in DSpace.
[20:36] <hpottinger> s/metadat/metadata/
[20:36] <kompewter> hpottinger meant to say: monikam_: I'm not sure about "metadata" per se, but, Hibernate can tie in to the frameworks I'm looking at for replacing AuthN/Z
[20:36] <monikam_> Yup - but authorization needs improvement :)
[20:37] <mhwood> I'd say we should look at what we need to do and *then* figure out how best to represent it.
[20:37] <jsherman> apologies for tardiness
[20:37] <tdonohue> welcome jsherman. Just wanted to note that we already discussed your idea (in the first 25 or so minutes). Logs are at: http://irclogs.duraspace.org/index.php?date=2014-03-19
[20:37] <kompewter> [ IRC Log for #duraspace on irc.freenode.net, collected by DuraLogBot ] - http://irclogs.duraspace.org/index.php?date=2014-03-19
[20:38] <hpottinger> monikam_: add your contact info on this page, if you're interested in helping out with AuthN/Z replacement http://tinyurl.com/dspace-replace-auth
[20:38] <kompewter> [ Replace Authentication and Authorization code in DSpace with a 3rd-party framework - DSpace - DuraSpace Wiki ] - http://tinyurl.com/dspace-replace-auth
[20:38] <tdonohue> jsherman: but we can always loop back to your topic maybe at the end (or post-meeting) if needed
[20:39] <tdonohue> So, is it time to move along to the next topic? Sounds like with "Metadata for All Objects" we really need to get @mire / KevinVdV looped in, and figure out a way to collaborate on it.
[20:39] <monikam_> hpottinger ; added name - we'll see how much time I really have
[20:39] <mhwood> I agree.
[20:40] <tdonohue> Ok, so next feature topic: "Never prompt Site-visitors (as opposed to Content Contributors and Administrators) to login" from monikam_
[20:40] <tdonohue> 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
[20:40] <monikam_> this is actually real easy in jsp - I think
[20:41] <monikam_> all you have to do is a small change
[20:41] <monikam_> see http://monika.princeton.edu/~monikam/PATCH-DSPaceServlet
[20:41] <monikam_> sorry for the formatting
[20:42] <tdonohue> I'm not sure I fully understand the "use case" here... I feel like I'm not sure what you mean by "Site Visitors" (is this the general public?)
[20:43] <monikam_> yep
[20:43] <hpottinger> monikam_: you might consider making a PR for just the JSPUI, I'm with tdonohue, I'm not sure I understand the use case, either
[20:43] <mhwood> And how does it know you're a visitor without first authenticating you?
[20:43] <monikam_> anybody that visits the site without having a 'realtionship' with it
[20:43] <monikam_> we'll you have an IP
[20:43] <tdonohue> When does this "redirection" happen? Are you wanting to redirect people when they access a restricted doc? Or are you restricting access to the *entire site*?
[20:44] <mhwood> Ah, the piece I was missing.
[20:44] <monikam_> there is GET - the ip either gives you rights or not
[20:44] <monikam_> if you don't have rights you get an error page
[20:45] <tdonohue> So, your IP address gives you rights to the entire site? or to individual items? I'm still slightly confused on the setup here of your DSpace
[20:45] <monikam_> No - some collections are completely open
[20:45] <mhwood> So there's special-group magic that happens before this point.
[20:46] <monikam_> other collections allow viewing from campus IPS
[20:46] <monikam_> the specia IP magic seems to happen when the DSPACE Conext is built
[20:46] <mhwood> Yes, that would be the place.
[20:46] <tdonohue> Ok, that makes more sense. So you are using the IP authentication tools to let some folks have immediate access to certain collections (based on their IP address)
[20:47] <monikam_> yes
[20:47] <mhwood> So, to generalize this so that it can become stock code, I think we'd need to wrap the new behavior in a configuration flag. Some sites will want the old behavior.
[20:47] <monikam_> IPs from campus may see - outsiders may not - but never prompt
[20:48] <monikam_> yes I agree - something in dspace.cfg that indicates whether explicitAuthentication is wanted with a default of true
[20:48] <monikam_> to match the old behaviour
[20:49] <Jonathan__> Would you not need a further flag for specific collections?
[20:50] <Jonathan__> so which collections are open or not
[20:50] <mhwood> I think that is done with existing resource policies, no?
[20:50] <monikam_> no - the ip restrictions are set via authorizations
[20:51] <mhwood> Collection A allows anonymous read; Collection B requires membership in the IP special group.
[20:51] <monikam_> in groups
[20:51] <monikam_> exactly
[20:51] <tdonohue> I admit, I'm still having some issue "visualizing" the core issue/problem here. I suspect there is one... But, I know I've been able to setup DSpace in the past with both IP-based authentication and normal password-login (for Admins, etc.)
[20:52] <monikam_> yes - BUT
[20:52] <monikam_> assume there is have IP restriction in collection A
[20:52] <monikam_> jorshmo does a wget on an item in the collection
[20:53] <monikam_> since he does not come from the right ip address
[20:53] <monikam_> the system will try to prompt for authemtication (if there is another mechanism in the auth stack)
[20:54] <monikam_> BUT
[20:54] <monikam_> jorshmo really should just be told that he's not allowed to see
[20:55] <tdonohue> but, why? What if "jorshmo" actually is an Admin.. shouldn't he be allowed to authenticate even if he's come from the wrong ip address?
[20:55] <monikam_> jorshmo can always authenticate by going through the mydspace first
[20:55] <tdonohue> (I think that's my issue ... the use case seems odd to me... i think there must be a reason you want it to work this way, but I don't quite understand)
[20:56] <monikam_> and voila he can see
[20:56] <mhwood> So the issue is strictly one of when to prompt. You're not trying to keep people out based on network topology alone.
[20:57] <monikam_> Yes the issue is to just be excplicit - You can't do this instead of saying : try to login here
[20:57] <monikam_> So this may not be as genreallt interesting as I think -
[20:57] * PeterDietz (~peterdiet@dietz72m1.lib.ohio-state.edu) Quit (Read error: Connection reset by peer)
[20:57] * PeterDietz (~peterdiet@dietz72m1.lib.ohio-state.edu) has joined #duraspace
[20:57] <mhwood> I have to say that I prefer the current behavior.
[20:58] <monikam_> Partly this was triggered on my part because the authentication put in place - made things go in a loop - a bug in other code — so if you guys think it is not interesting for other - never mind …
[20:58] <tdonohue> I'm not sure I'd want it to act this way myself, I'll admit. I prefer the current behavior just cause it's less steps for the Admins. If they are at a wrong IP, they can still immediately get access by logging in. However, if we change that behavior, they have to somehow know to go login *first* and then retry their request.
[20:59] <hpottinger> could be interesting... I'd say proceed and make a PR
[20:59] * PeterDietz (~peterdiet@dietz72m1.lib.ohio-state.edu) Quit (Remote host closed the connection)
[20:59] <mhwood> With the stock code, if you wget something protected, then instead of failing, wget writes a file full of login form. Yucky.
[20:59] * PeterDietz (~peterdiet@dhcp-164-107-233-114.osuwireless.ohio-state.edu) has joined #duraspace
[20:59] <tdonohue> But, I'd not stand in the way here... You are still welcome to make a PR, and we can do a wider review.
[21:00] <monikam_> OK - lets just settle on - I make a PR - and decision time later
[21:00] <mhwood> I feel that this is nibbling at a larger issue, but can't quite characterize it.
[21:00] <hpottinger> the topic of the meeting is to talk about features :-) we don't have to agree on 'em :-)
[21:01] <tdonohue> Right, I think "make a PR" is the next step. We can bubble up the discussion to more committers...there may be other interest or a bigger issue here
[21:01] <monikam_> sounds good
[21:01] <hpottinger> even if it's JSPUI-only
[21:01] <Jonathan__> On your point monika I was delving into the request a copy code to see when the request a copy page is called when a user clicks on a restricted bitstream
[21:01] <tdonohue> Ok. We are at 21:00 UTC. However, there's one more "Feature Idea" from monikam_. Are others OK with going a bit over time today?
[21:02] <Jonathan__> that point in the code maybe where you would be interested in doing a change like that
[21:02] <hpottinger> I'm OK with going overtime
[21:02] <tdonohue> Ok, moving along to the last Feature Topic
[21:02] <tdonohue> "Configure Items/Collections/Communities with a Usage Agreement that is shown before Bitstreams" by monikam_
[21:03] <tdonohue> described at http://dspace.2283337.n4.nabble.com/show-agreement-before-responding-with-bitstream-td4671868.html
[21:03] <kompewter> [ DSpace - Devel - show agreement before responding with bitstream ] - http://dspace.2283337.n4.nabble.com/show-agreement-before-responding-with-bitstream-td4671868.html
[21:03] <monikam_> Is this feature clearer ?
[21:03] <hpottinger> this has come up around here, specific to data sets
[21:03] <mhwood> I have to go, but this one is clearer to me and sounds like others would be interested.
[21:03] <monikam_> ok not used to format yet
[21:03] <monikam_> here links
[21:03] <monikam_> http://monika.princeton.edu/~monikam/bitstream-agreement.jsp
[21:04] * PeterDietz (~peterdiet@dhcp-164-107-233-114.osuwireless.ohio-state.edu) Quit (Ping timeout: 240 seconds)
[21:04] <monikam_> http://monika.princeton.edu/~monikam/ViewAgreement.java
[21:04] * mhwood (mwood@mhw.ulib.iupui.edu) has left #duraspace
[21:04] <monikam_> http://monika.princeton.edu/~monikam/dspace.cfg
[21:04] <tdonohue> This feature sounds clearer to me. You basically just want users to be prompted to some sort of "agreement" before the Bitstream download begins?
[21:04] <hpottinger> I think it would have general appeal, though I also think that in order to enforceable one would need to involve their institution's general counsel and get their blessing
[21:05] <monikam_> yep - lots of talk to administrators - lots of waiting for wording and such
[21:05] <hpottinger> And, I also think that you'd need to have an open and honest conversation with your content contributors about what open access means, when it comes to data sets
[21:06] <monikam_> there is one feature they way it has been requested here which is a bit weird
[21:06] <monikam_> there is a timeout on the agreement
[21:06] <monikam_> the agreement is tied to a collection
[21:07] <tdonohue> ah, I was just going to ask where this agreement text is stored. It's new collection metadata?
[21:07] <monikam_> once agreed it is good for timeout minutes (as long as the seesion survives)
[21:07] <hpottinger> collection meatadata, good one, tdonohue ;-)
[21:07] <monikam_> no the files under dsoace.dir/config/agreements
[21:08] <monikam_> modeled after the multilungual way of doing emails
[21:08] <tdonohue> oh, ok
[21:10] <monikam_> sounds like I do another PR - and we go from there >
[21:10] <monikam_> ???
[21:10] <tdonohue> So, this idea in general sounds like it may have some general interest
[21:10] <hpottinger> +1 PR
[21:10] <tdonohue> I agree, a PR might be best.
[21:10] <tdonohue> It'd at least give something for others to respond to. I wonder whether this specific implementation would work for everyone...but hopefully those discussions can come up around the PR itself
[21:11] <monikam_> that's the plan then
[21:11] <tdonohue> I don't know enough about what institutions would want out of such an agreement. But, I suspect that other instutions *would* want this
[21:11] <tdonohue> sounds great! Thanks, monikam_ for sharing your code/ideas today!
[21:12] <monikam_> again this JSP - can anybody point me to how I would do this in XMLUI ?
[21:12] <tdonohue> you don't *have* to do it for both UIs. Oftentimes, features will be implemented in one UI by one person, and then another person will "port it" over to the other UI
[21:13] <hpottinger> there are committers who enjoy migrating features back and forth between the two UIs, we can help you once you have your PR
[21:13] <monikam_> ok
[21:13] <tdonohue> So, starting with a PR that is JSPUI specific is OK. Then we'd review it and try to get agreement on the direction. If agreement is achieved, chances are someone who uses the XMLUI heavily will port it over
[21:15] <monikam_> thanks - got my todo list - gotta run
[21:15] * monikam_ (~Monika_Me@monika.Princeton.EDU) has left #duraspace
[21:15] <tdonohue> So, that's all of our feature topics for today. But, jsherman if you are still around and have questions/comments on the IRC logs, you are more than welcome to ask now (otherwise we can discuss via JIRA ticket, etc)
[21:15] <jsherman> I do, Won't take long.
[21:15] <tdonohue> go ahead
[21:16] <hpottinger> in addition, if anyone has some features they are working on, or know of, shout out (but wait for jsherman to finish, obviously)
[21:16] <jsherman> The discussion pretty much nailed it so far. Not using the code in production.
[21:16] <jsherman> I was imagining making pseudo-streaming useful by doing a media filter with ffmpeg or handbrake-cli
[21:16] <jsherman> a curation task has been mentioned
[21:17] <jsherman> Maybe tying it altogether with an embedded flowplayer?
[21:17] <jsherman> I'd like to get away from theme dependency
[21:17] <jsherman> this is the part that might get yucky,
[21:17] <hpottinger> there are jquery-based players
[21:18] <tdonohue> (and we do use jquery quite a bit in both UIs already, so that might be a nice direction)
[21:18] <jsherman> I guess the question is: does the idea of automated offline video transcode appeal to anybody else?
[21:18] <tdonohue> I like the idea of a mediafilter to help with pseudo-streaming
[21:19] <jsherman> I've done ffmpeg automation on personal project, so I could take a shot at it.
[21:19] <tdonohue> In general, I like the idea of having a "very basic" pseudo-streaming option in DSpace. I, personally, suspect that many institutions won't be able to jump at putting up a full-fledged streaming server (other than the bigger institutions). So, it'd be nice if they had a more simplistic, nearly "out-of-the-box" option
[21:20] <hpottinger> pseudo streaming is appealing in that it uses stuff we already have... my only problem is using up storage and preservation tools for derivatives
[21:20] <jsherman> not much getting around that.
[21:20] <tdonohue> (but to be clear, I still think DSpace needs to also integrate with external streaming servers -- but that'd be for the "advanced" users who want more advanced streaming options)
[21:20] <jsherman> for this kind of a solution for sure
[21:21] <jsherman> I'm looking at producing at least 3 video types as derivatives
[21:21] <jsherman> webm, h264, and something else.
[21:22] <aschweer> we've tried going down that route, we just couldn't find a combination of video player + formats that worked on all devices we wanted to support
[21:22] <hpottinger> one thing, transcoding is kind of a dark art, you can sometimes do a "one size fits all" approach, but, I hear you better results if you twiddle the knobs a bit
[21:22] <aschweer> yeah we did a lot of twiddling and still didn't get there, not sure if it was because our theme is too far away from HTML5
[21:23] <aschweer> our sysadmins weren't too happy with having to make custom ffmpeg builds either
[21:23] <jsherman> _hpottinger That is definitely true, I would need to code in lots of hints
[21:23] <aschweer> and we were concerned about the extra storage space needed for the derivatives
[21:23] <aschweer> so tl;dr - we're interested in this and have tried it but have given up for now
[21:23] <jsherman> I'd love to get access to test files
[21:24] <jsherman> the really weird stuff
[21:24] <tdonohue> yea, storage space for these (larger) derivatives might be an issue for some. We may need to "turn off" generating those derivatives by default, but make an option to easily enable them for those that want them
[21:24] <jsherman> *nodding*
[21:25] <hpottinger> I appreciate that you've made a PR, we actually tried just uncommenting out the byte-range request stuff last year, but commented it back out as soon as we realized it broke PDF viewing
[21:25] <jsherman> The more I think about the media filter, the more it makes me think the "streamable" stuff in the registry may not be necessary.
[21:26] <hpottinger> just to dot an i here, here's one jQuery-based media viewer: http://html5-ninja.com/#/item/Bootstrap-video-player-jQuery-plugin/5
[21:26] <kompewter> [ HTML5 Ninja - HTML5 marketplace | Items, Themes, Templates | HTML5 Ninja ] - http://html5-ninja.com/#/item/Bootstrap-video-player-jQuery-plugin/5
[21:26] <tdonohue> Nice to hear though that others are playing / have played around in this space...hoping that means that there are collaboration opportunities & others who can chip in with feedback/brainstorms
[21:26] * tdonohue admits to being a total novice to most everything "streaming" related...but I'm glad others are digging in and figuring some things out
[21:27] <aschweer> yup I would be interested in chipping in, it's definitely still on the "we're interested" list for my repositories
[21:27] <jsherman> this has been really good feedback. I'll come up with something on the media-filter front that imbeds a jquery player.
[21:27] <aschweer> jsherman: I'm happy to give you links to the DSpace items / video files we used for our testing
[21:27] <tdonohue> I'd be interested as well, personally. I just need to learn more myself about what is out there, etc :)
[21:27] <jsherman> aschweer, could I coopt youas a tester?
[21:28] <jsherman> great
[21:28] <hpottinger> it would be cool if we could get the two bootstrap-based themes (JSPUI and Mirage 2) to include some media viewers, too
[21:28] <hpottinger> +1 test files
[21:28] <aschweer> jsherman: yes, happy to help test. I can probably even officially get some time for this but probably more towards the second half of the year (hope it's not too late then)
[21:28] <aschweer> yes, we've postponed this to after Mirage 2 thinking it might help to be closer to valid HTML5
[21:29] <jsherman> I guess the only question is whether or not it makes it into ds5.
[21:29] <jsherman> in answer to "too late"
[21:29] <tdonohue> In terms of timeframes -- I suspect the "Feature Freeze" for DSpace 5.0 will be sometime around late Sept / early Oct. It's not finalized yet though
[21:29] <hpottinger> want to take a peek at Mirage2?
[21:29] <tdonohue> Mirage 2 is "supposedly" aimed for DSpace 5.
[21:29] <aschweer> maybe it's time to talk to Richard Rodgers again about turning the media filters into curation tasks. I built my conversion on his work in that area.
[21:30] <tdonohue> aschweer +1 That'd be nice
[21:31] <hpottinger> http://atmire.com/website/?q=download-mirage-2
[21:31] <kompewter> [ Download Mirage 2 Alpha 1 | atmire ] - http://atmire.com/website/?q=download-mirage-2
[21:31] <aschweer> he has https://github.com/richardrodgers/ctask I just don't know what the status is on this
[21:31] <kompewter> [ richardrodgers/ctask · GitHub ] - https://github.com/richardrodgers/ctask
[21:31] <tdonohue> The Mirage 2 preview/demo is at: https://atmire.com/preview/ (hpottinger just linked the code/docs)
[21:31] <kompewter> [ Mirage 2 Preview Repository ] - https://atmire.com/preview/
[21:32] <hpottinger> aschweer: mind adding your notes on your streaming work to the project page on the wiki? http://tinyurl.com/dspace-streaming
[21:32] <kompewter> [ Audio/Video Streaming (RTMP, HLS, DASH) Support - DSpace - DuraSpace Wiki ] - http://tinyurl.com/dspace-streaming
[21:33] <aschweer> hpottinger: I'll try to remember to dig them up and add them
[21:33] <tdonohue> Ok, it sounds like we've mostly "wrapped up here". Thanks to jsherman as well for the great ideas & discussion
[21:33] <jsherman> Again, apologies for my tardiness!
[21:33] <tdonohue> I'm going to call a close to the official meeting. But, feel free to continue discussions as long as you wish
[21:33] <hpottinger> thanks, jsherman!
[21:33] <tdonohue> No problem, jsherman. Glad you could make it and hang around a little later
[21:34] * Jonathan__ (596578eb@gateway/web/freenode/ip.89.101.120.235) Quit (Quit: Page closed)
[21:36] <jsherman> quit gotta go!
[21:36] * jsherman (a43a1787@gateway/web/freenode/ip.164.58.23.135) Quit (Quit: Page closed)
[21:37] * hpottinger (~hpottinge@mu-160123.dhcp.missouri.edu) has left #duraspace
[21:47] * aschweer (~schweer@schweer.its.waikato.ac.nz) Quit (Quit: leaving)
[22:00] * tdonohue (~tdonohue@c-50-179-112-246.hsd1.il.comcast.net) has left #duraspace
[23:07] * misilot (~misilot@p-body.lib.fit.edu) Quit (Ping timeout: 246 seconds)
[23:10] * misilot (~misilot@p-body.lib.fit.edu) has joined #duraspace
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.