Timestamps are in GMT/BST.
[6:51] -orwell.freenode.net- *** Looking up your hostname...
[6:51] -orwell.freenode.net- *** Checking Ident
[6:51] -orwell.freenode.net- *** Found your hostname
[6:51] -orwell.freenode.net- *** No Ident response
[6:51] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:51] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:51] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[8:24] * aawoods_ (~awoods@c-67-165-245-76.hsd1.co.comcast.net) has joined #duraspace
[8:28] * awoods (~awoods@c-67-165-245-76.hsd1.co.comcast.net) Quit (Ping timeout: 240 seconds)
[10:44] * kshepherd2 (~kim@121-99-157-35.bng1.nct.orcon.net.nz) has joined #duraspace
[12:00] * ruebot_ (~ruebot@192.241.253.49) Quit (Quit: Please, sir, I want some more.)
[12:00] * ruebot (~ruebot@pdpc/supporter/professional/ruebot) has joined #duraspace
[12:01] * kshepherd2 (~kim@121-99-157-35.bng1.nct.orcon.net.nz) Quit (Ping timeout: 240 seconds)
[12:21] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[12:58] * tdonohue (~tdonohue@c-50-179-112-246.hsd1.il.comcast.net) has joined #duraspace
[13:55] * aawoods_ is now known as awoods
[14:32] * hpottinger (~hpottinge@mu-160123.dhcp.missouri.edu) has joined #duraspace
[15:36] * richardrodgers (~richardro@18.189.115.43) has joined #duraspace
[15:36] <richardrodgers> Hey all - got Hardy's email
[15:38] <hpottinger> oh, hey, richardrodgers!
[15:40] <richardrodgers> In a funny coincidence, I was just going to reach out to tdonohue and others over a service question I've been thinking about (related to packages)
[15:40] <hpottinger> tdonohue and I were just chatting privately about both a possible intersection with RTS and MDS work, and also the potential for pulling out parts of the MDS work for inclusion in DSpace 5.0
[15:40] <tdonohue> hi richardrodgers
[15:41] <richardrodgers> Hey tdonohue , want to hear my pitch?
[15:41] <hpottinger> Missouri is looking at using RTS to back up our IR, and I'd be willing to pitch in to help the BagIt package format reach parity withe the METS package format
[15:41] <tdonohue> sure, pitch away. Please note though that we are in the publicly "logged" channel (not that it should make a difference)
[15:42] <hpottinger> move to #dspace?
[15:42] <richardrodgers> I've been working on a REST API, and have been struck by the fact that we (DSpace, mds, etc) have a package-oriented ingest (SWORD), but no real package-oriented dissemination.
[15:43] <hpottinger> we were just talking about that :-)
[15:43] <richardrodgers> I can move to #dspace, but this is OK for me also
[15:44] <richardrodgers> So I was thinking that I'd extend the REST api to allow a new resource type for packaged content.
[15:44] <hpottinger> keep it logged, maybe someone will find the conversation interesting (maybe even volunteer to help out? A guy can hope, right?)
[15:45] <tdonohue> Fine with continuing here. Keeping it logged has its advantages...but I just wanted to note which room we were in
[15:46] <richardrodgers> E.g. (using mds URIs) /content/123456789/1 is an item, and /content/123456789/1/package/foo is a package of the item
[15:47] <tdonohue> right, makes sense (as long as the items are public, of course)
[15:47] <hpottinger> aha, I was just about to ask if you were talking about MDS REST or DSpace REST
[15:47] <richardrodgers> A given repo could configure one or more package types (the 'foo'), maybe even different package types for different content types. For example,
[15:48] <richardrodgers> we at MIT disseminate IMS-CP packages for course material, but not any other types
[15:48] <hpottinger> there might be a potential overlap with ResourceSync
[15:49] <tdonohue> overlap is probably OK. ResourceSync can always take advantage of this functionality if it's made available elsewhere as well.
[15:50] <richardrodgers> tdonohue: yes, public, but one could even imagine a packager that is sensitive to resource policies (e.g. put one bundle's stuff in, but not anothers)
[15:50] <hpottinger> +1 REST-API that's aware of resource policies :-)
[15:51] <richardrodgers> hpottinger: yes, I see a clear relation to ResourceSync - one could imagine publishing different 'sets' based on package types..
[15:53] <tdonohue> yea, I think this sounds good. I suspect the package types would need options to enable them for commandline (local) vs. REST API (remote). Some folks may want some package types enabled for local & remote, and others just locally
[15:53] <richardrodgers> So anyway, what I was going to do (as a prototype in mds) is provide a 'reference implementation' of this idea with Bagit packages, then lean on TIm to provide a METs one ;)
[15:54] <hpottinger> the direction I came at this idea from is that I was recently asked to share the test content I use to populate my Vagrant-DSpace repository
[15:55] <richardrodgers> hpottinger: exactly, if one was running a REST API, it would be a simple http GET of on an item
[15:56] <tdonohue> If you need something "timely", leaning on me these days is not recommend ;) My plate is overflowing and I don't get to much coding these days. But, I still like the idea, even if it's initially BagIt (until someone can get to METS AIPs).
[15:56] <hpottinger> that would be so cool, to be able to just pull the most recent collection & community structure
[15:58] <hpottinger> my brain is trying to tell me that earlier today I was just reading an article about relying upon "the network" as a package
[15:59] <richardrodgers> OK - sounds good. What I'm working on now is a bit of refactoring to move a lot of the packaging logic/code from Curation Task Suite Replication to a more central area, since this REST service isn't about curation...
[15:59] * mhwood butts in: whenever you think of access, don't think options. DSpace config. is overflowing with options, and they don't model access decisions very well. Think rights (i.e. resource policies).
[15:59] <hpottinger> found it: https://www.domenkozar.com/2014/03/11/why-puppet-chef-ansible-arent-good-enough-and-we-can-do-better/
[15:59] <kompewter> [ Domen Kožar ] - https://www.domenkozar.com/2014/03/11/why-puppet-chef-ansible-arent-good-enough-and-we-can-do-better/
[16:01] <hpottinger> +1 resource policies
[16:02] <richardrodgers> mhwood: yes, the approach I'm using doesn't overload config properties at all
[16:03] <tdonohue> richardrodgers: is this work you are doing in MDS then? Or do you plan to try and do some of this for the main DSpace-API? Just not clear which codebase you are working with
[16:03] <mhwood> Good. If we need more "special groups" (like one for "local user" = commandline) we can make them.
[16:04] <richardrodgers> tdonohue: The POC will be in mds - if we like the results, it should be (with effort of course) portable to DSpace-API
[16:05] <hpottinger> we have two members of the RT present now, so I hope I can safely speak for us when I say: we want this stuff for 5.0
[16:05] <hpottinger> we want ALL THE STUFF for 5.0 :-)
[16:05] <mhwood> Do we *have* a 5.0 RT?
[16:06] <hpottinger> OK, details schmetails :0)
[16:06] <richardrodgers> mhwood: yes, that's news to me also
[16:06] <hpottinger> I'm on autopilot, we don't have a 5.0 RT, just me assuming that the same folks who show up will continue to show up
[16:07] <hpottinger> so, I'm kind of a zombie RT member, careful, I bite
[16:08] <richardrodgers> I think some of the problems (which SWORD has, by the way) revolve around a decent standardized way to identify packages …(http X- Header, mimeType, etc)
[16:08] <tdonohue> we don't have a 5.0 RT yet. We can start to form one whenever we want to put out the call. I just hadn't done so yet, as I was waiting for 4.x to settle down (and it seems to be doing so)
[16:09] <hpottinger> sorry, I've been "shaking the trees" for features for a few weeks, I get carried away
[16:10] <mhwood> I do think this work should be represented in any 5.0 features discussion.
[16:13] <tdonohue> Out of curiosity, are there any other MDS "features" / refactors that we could aim towards "porting" over to DSpace 5.0?
[16:16] <hpottinger> one potential would be to look at any "easy wins" of dependency modernization, mhwood is already doing that, but MDS is really exploring the potential from that kind of modernization work...
[16:16] <richardrodgers> I've got to run now, but I'm hearing some interest in pursuing package-based content delivery, so I'll proceed with a Bagit POC in mds
[16:17] <richardrodgers> bye all
[16:17] <hpottinger> bye!
[16:17] <kompewter> see ya
[16:17] * richardrodgers (~richardro@18.189.115.43) has left #duraspace
[16:26] * edInCo (~smuxi@seta.coalliance.org) has joined #duraspace
[16:41] * PeterDietz (~peterdiet@dietz72m1.lib.ohio-state.edu) has joined #duraspace
[17:00] * PeterDie_ (~peterdiet@dhcp-164-107-232-38.osuwireless.ohio-state.edu) has joined #duraspace
[17:03] * PeterDietz (~peterdiet@dietz72m1.lib.ohio-state.edu) Quit (Ping timeout: 246 seconds)
[17:06] * PeterDie_ (~peterdiet@dhcp-164-107-232-38.osuwireless.ohio-state.edu) Quit (Remote host closed the connection)
[17:33] * PeterDietz (~peterdiet@dhcp-164-107-232-38.osuwireless.ohio-state.edu) has joined #duraspace
[19:12] * PeterDietz (~peterdiet@dhcp-164-107-232-38.osuwireless.ohio-state.edu) Quit (Remote host closed the connection)
[19:16] * PeterDietz (~peterdiet@dietz72m1.lib.ohio-state.edu) has joined #duraspace
[21:10] * mhwood (mwood@mhw.ulib.iupui.edu) Quit (Remote host closed the connection)
[21:21] * hpottinger (~hpottinge@mu-160123.dhcp.missouri.edu) has left #duraspace
[22:10] * tdonohue (~tdonohue@c-50-179-112-246.hsd1.il.comcast.net) has left #duraspace
[23:47] * edInCo (~smuxi@seta.coalliance.org) Quit (Read error: Connection reset by peer)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.