Timestamps are in GMT/BST.
[2:39] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Quit: bradmc)
[2:49] * dan_davis (183ae85b@gateway/web/freenode/ip.24.58.232.91) Quit (Ping timeout: 252 seconds)
[6:38] -kornbluth.freenode.net- *** Looking up your hostname...
[6:38] -kornbluth.freenode.net- *** Checking Ident
[6:38] -kornbluth.freenode.net- *** Found your hostname
[6:38] -kornbluth.freenode.net- *** No Ident response
[6:38] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:38] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:38] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[8:10] * grahamtriggs (~Graham@host213-123-239-134.in-addr.btopenworld.com) has joined #duraspace
[11:33] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[12:10] * mhwood (~mhwood@2001:18e8:3:10ab:21e:4fff:feba:a425) has joined #duraspace
[12:55] * bradmc__ (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[12:55] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Read error: Connection reset by peer)
[12:55] * bradmc__ is now known as bradmc
[13:20] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Read error: Connection reset by peer)
[13:21] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[13:23] * tdonohue (~tdonohue@c-98-228-50-45.hsd1.il.comcast.net) has joined #duraspace
[13:44] * tdonohue (~tdonohue@c-98-228-50-45.hsd1.il.comcast.net) Quit (Quit: Heading out...talk to you later.)
[13:45] * tdonohue (~tdonohue@c-98-228-50-45.hsd1.il.comcast.net) has joined #duraspace
[13:57] * scottatm (~scottatm@adhcp164.evans.tamu.edu) Quit (Quit: scottatm)
[16:08] * grahamtriggs (~Graham@host213-123-239-134.in-addr.btopenworld.com) has left #duraspace
[16:44] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Quit: bradmc)
[16:55] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[18:30] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Ping timeout: 252 seconds)
[18:33] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[19:14] * barmintor (barmintor@specdl11.cul.columbia.edu) has joined #duraspace
[19:29] * KevinVdV (KevinVdV@d54C14F72.access.telenet.be) has joined #duraspace
[19:33] * BramDS (~bram@94-224-17-72.access.telenet.be) has joined #duraspace
[19:35] * grahamtriggs (~Graham@cpc2-stev6-2-0-cust333.9-2.cable.virginmedia.com) has joined #duraspace
[19:40] * scottatm (~scottatm@adhcp164.evans.tamu.edu) has joined #duraspace
[19:44] * hpottinger (80cea2c6@gateway/web/freenode/ip.128.206.162.198) has joined #duraspace
[19:51] <tdonohue> Hi all, in about 10mins, we have our weekly DSpace Devel Mtg here. https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-07-27
[19:59] * richardrodgers (~richardro@pool-96-237-109-89.bstnma.fios.verizon.net) has joined #duraspace
[20:00] <tdonohue> Hi all, it's that time again. Here's our agenda for today: https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-07-27
[20:00] <tdonohue> we'll kick things off with our normal JIRA review. https://jira.duraspace.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+DS+AND+resolution+%3D+Unresolved+AND+Key%3E%3DDS-851+ORDER+BY+key+ASC
[20:00] <tdonohue> starting with DS-851
[20:01] <tdonohue> (hmm...no kompewter today?)
[20:01] <tdonohue> https://jira.duraspace.org/browse/DS-851
[20:01] * Franoculator (~dennycran@zorin.mpowell.ws) has joined #duraspace
[20:01] * mdiggory (~mdiggory@rrcs-74-87-47-114.west.biz.rr.com) has joined #duraspace
[20:02] * bojans (~Bojmen@62.68.118.52) has joined #duraspace
[20:02] * PeterDietz (~PeterDiet@peterdietz.lib.ohio-state.edu) has joined #duraspace
[20:02] <tdonohue> hi all (who just joined) -- we're starting with a JIRA review of https://jira.duraspace.org/browse/DS-851
[20:03] * kompewter (~kompewter@peterdietz.lib.ohio-state.edu) has joined #duraspace
[20:03] <PeterDietz> DS-851 test
[20:03] <kompewter> [ https://jira.duraspace.org/browse/DS-851 ] - [#DS-851] qualdrop_value required fail - DuraSpace JIRA
[20:03] <tdonohue> thanks PeterDietz :)
[20:03] <tdonohue> So, starting with DS-851 today
[20:03] <kompewter> [ https://jira.duraspace.org/browse/DS-851 ] - [#DS-851] qualdrop_value required fail - DuraSpace JIRA
[20:04] <tdonohue> thoughts? looks like Alex Lemann has verified this as a bug. Anyone want to try and tackle it?
[20:04] <richardrodgers> Is this JSPUI only?
[20:04] <PeterDietz> I'm guessing this is a documented feature of input forms?
[20:05] <PeterDietz> comment says both jspui/xmlui
[20:05] <tdonohue> according to comment, it's both XMLUI & JSPUI
[20:06] <PeterDietz> sorry, I've never touched an input-form. Just uploaded modifications of our librarians
[20:08] <tdonohue> ok. Sounds like we have no takers for now. I'll add these notes to comments of Ds-851 and see if someone else in community can provide a patch
[20:08] <tdonohue> Ds-851 Summary: verified bug, needs a volunteer to provide a patch
[20:08] <tdonohue> next up DS-852
[20:08] <kompewter> [ https://jira.duraspace.org/browse/DS-852 ] - [#DS-852] Split the Creative Commons and Licence steps into two seperate steps. - DuraSpace JIRA
[20:08] <richardrodgers> I think this is done?
[20:08] <tdonohue> oh, wait, that's assigned to robintaylor (who is on holiday this week). I'm assuming he has that under control...
[20:09] <mdiggory> I'm wondering how this will impact the CC Webservices patch from MIT
[20:09] <richardrodgers> already integrated, but good observation mdiggory
[20:09] <tdonohue> ok, we'll move on. From comments in Ds-852, robint has this all under control
[20:09] <mdiggory> excellent….return to lurking mode
[20:09] <tdonohue> next up, DS-854
[20:09] <kompewter> [ https://jira.duraspace.org/browse/DS-854 ] - [#DS-854] Licenses on non-DSpace files have been replaced by DSpace boilerplate license - DuraSpace JIRA
[20:10] <mdiggory> crap…..
[20:10] <PeterDietz> ;)
[20:10] <PeterDietz> this was on release day
[20:10] <tdonohue> ugh, that's odd. Yea, Ds-854 sounds like we need some more pom.xml exclusions
[20:10] <mdiggory> yes, it does
[20:11] <tdonohue> anyone want to tackle this?
[20:11] <mdiggory> should be handled at the level of thier inclusion
[20:11] <mdiggory> IE in dspace-xmlui-webapp and dspace-jspui-webapp
[20:11] <PeterDietz> i vote whoever "included" the autolicensing magic thing... aka mdiggory
[20:11] * mdiggory crap I gotta get outa here
[20:12] <tdonohue> mdiggory -- do you have the time / inclination to take this on? If not, I guess I can try and do it
[20:12] <mdiggory> ummm… ok
[20:12] <tdonohue> ok meaning : assign mdiggory?
[20:12] <mdiggory> yes
[20:12] <tdonohue> ok, Ds-854 Summary: assign to mdiggory for completion before 1.8.0
[20:13] <tdonohue> next up, DS-859
[20:13] <kompewter> [ https://jira.duraspace.org/browse/DS-859 ] - [#DS-859] DSpace Test supporting files get quickly out of date - DuraSpace JIRA
[20:13] * PeterDietz noticed that mdiggory is typing ellipsises not 3 periods, but a single character dot-dot-dot
[20:13] <tdonohue> oh wait, Ds-859 -- isn't mhwood looking into this?
[20:13] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Read error: Connection reset by peer)
[20:13] * mhwood is looking into that, yet.
[20:13] <mhwood> fs$yet$yes$$
[20:13] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[20:14] <tdonohue> ok, Ds-859 Summary: assign mhwood. He's already looking at it. If he needs help, he should just yell ;)
[20:14] <tdonohue> next up, DS-861
[20:14] <kompewter> [ https://jira.duraspace.org/browse/DS-861 ] - [#DS-861] Salt PasswordAuthentication - DuraSpace JIRA
[20:16] <tdonohue> +1 to this idea -- though, I agree with mhwood that salts need to be unique per Eperson. I'm guessing we may not get this done in time for 1.8.0 though (unless someone wants to run with it in coming weeks)
[20:16] <mhwood> I can work on it but can't promise today that it will land for 1.8.0.
[20:16] <mdiggory> Seems that unless the salt is some locally unique value, most could figure it out from the source code
[20:17] <mdiggory> even if it were per EPerson
[20:17] <mhwood> Doesn't matter: it makes cracking the hashes more difficult anyway.
[20:17] <PeterDietz> unique, from google analytics code.. wait thats public on page
[20:17] <tdonohue> that's fine by me, mhwood, if you want to take a look at it. At this point, I wouldn't expect new projects to be completed in time for 1.8.0
[20:18] <tdonohue> Ds-861 Summary: mhwood will investigate. No promises that it will be ready for 1.8.0. Likely will have to wait for next major version.
[20:18] <tdonohue> last one for today, DS-863
[20:18] <kompewter> [ https://jira.duraspace.org/browse/DS-863 ] - [#DS-863] Still possible to register despite xmlui.user.registration set to false - DuraSpace JIRA
[20:19] <richardrodgers> looks like patch & test conducted, just apply
[20:19] <PeterDietz> patch looks good. looks like a good candidate for 1.8
[20:19] <tdonohue> Yep. I'd agree, looks good & just needs to be applied. Someone want to apply it for 1.8.0?
[20:19] <mdiggory> yes, seems good
[20:19] <PeterDietz> comment at start of codeblock says Preform, not perform (not introduced by patch though)
[20:20] <mhwood> There are scads of "preform"s in various places around DSpace.
[20:20] <tdonohue> yea -- we have tons of misspellings...some of us aren't the best spellers
[20:21] <mdiggory> do be do be do
[20:21] <tdonohue> Ok, Ds-863 Summary: Assign tdonohue, he'll just commit it today or tomorrow.
[20:21] <tdonohue> We'll stop JIRA review there for today
[20:22] <tdonohue> The only other topic I had for today was to basically have everyone do updates on 1.8.0. Robin's on holiday as mentioned, but, we thought it'd be good to get updates on: "what is still coming?" "what is less likely for 1.8.0 now?" etc.
[20:23] <tdonohue> https://wiki.duraspace.org/display/DSPACE/DSpace+Release+1.8.0+Notes
[20:23] <kompewter> [ DSpace Release 1.8.0 Notes - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DSpace+Release+1.8.0+Notes
[20:23] <KevinVdV> I have something that I have been working on, a new configuration for Discovery
[20:23] <KevinVdV> https://jira.duraspace.org/browse/DS-971
[20:23] <kompewter> [ https://jira.duraspace.org/browse/DS-971 ] - [#DS-971] New Discovery configuration system - DuraSpace JIRA
[20:23] <kompewter> [ [#DS-971] New Discovery configuration system - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS-971
[20:23] <tdonohue> that page has our current "tentative" features....are all of these still on their way (if they aren't in trunk already)? Are there any "new features" to expect, or others that won't make it?
[20:24] <richardrodgers> I can report on a few:
[20:24] <PeterDietz> A Note to All.. Tim and I had a conference call with Apple Inc today, to talk about the iTunes Podcast support coming in 1.8. Expect an announcement, me to commit some patches, and we need volunteer's who've got content they'd like to syndicate to jump in early to start trialing it.
[20:24] <mdiggory> its out of order, but we may try to fit the above into 1.8.0 discovery once patches are delivered
[20:25] <KevinVdV> mdiggory please take into account the new Discovery configuration: https://jira.duraspace.org/browse/DS-971
[20:25] <kompewter> [ https://jira.duraspace.org/browse/DS-971 ] - [#DS-971] New Discovery configuration system - DuraSpace JIRA
[20:25] <tdonohue> Re Ds-971: I was just looking at that earlier, KevinVdV. I think the concept looks good. But, I'd want to see the code too. Plus, we would definitely need to think about how to Transition users from the "old" discovery configs to the new ones (it may just be some clear documentation is needed)
[20:25] <kompewter> [ [#DS-971] New Discovery configuration system - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS-971
[20:25] <KevinVdV> I will have the code & the first documentation version ready by sunday
[20:26] <mdiggory> PeterDietz: I'm pondering all the DSpace installs that will suddenly be under massive loads when iTunes starts subscribing to them
[20:27] <tdonohue> Re: PeterDietz's announcement about Apple. They seem pretty excited about DS-528 coming into 1.8.0. But, we are also looking for more testers or people who can help provide feedback (even if mainly during Testathon).
[20:27] <kompewter> [ https://jira.duraspace.org/browse/DS-528 ] - [#DS-528] RSS feeds to support richer features, such as iTunes Podcast or Media RSS - DuraSpace JIRA
[20:27] <PeterDietz> I did a quick look at our apache access logs, and noticed that actual users (non-robots), accounted for about 1/20th of our visitors
[20:28] <mdiggory> but I assume to be able to search these feeds, is Apple going to be crawling them and adding them to their store? or will this require individual subscription by the end user.
[20:29] <PeterDietz> I have an idea for an xmlui theme customized to display audio files. i.e. bitstream = some-file.mp3, It could have a play button next to it that lets you play it from the site.
[20:29] * mdiggory is sure its not a big deal
[20:29] <hpottinger> PeterDietz: the Ds-528 patch does support an external streaming server, yes?
[20:30] <PeterDietz> current practice will be that RepoAdmin adds RSS feed for Collection-X to their iTunes U instance, which apple when then begin crawling the feed periodically
[20:30] <mdiggory> no, not really necessary… podcasts would generally be downloaded to iTunes/ipod
[20:30] <mdiggory> that was a response for hpottinger
[20:31] <mdiggory> PeterDietz, seems sensible...
[20:31] <PeterDietz> the 528 patch does introduce the idea that you could add a metadata field dc.external-media-url or something for you to link to an external copy of your bitstream such as your campuses streaming-media CDN
[20:31] <mdiggory> I like that
[20:32] <PeterDietz> ...but the straight-forward use case of bitstream x.mp3 or x.mpg will get added to feed is the primary use-case, and it works fine
[20:33] <mhwood> Make that ds.external-media-url and I'm sold.
[20:34] <tdonohue> Ok, other updates? richardrodgers you were about to update on 1.8 MIT stuff above?
[20:34] <richardrodgers> yes - I think we will have a port of MediaFilters -> curation tasks
[20:34] <tdonohue> mhwood: I think the actual metadata field is configurable -- though, I agree, it'd be nice to get a "ds" (internal dspace) schema at some point.
[20:35] <tdonohue> richardrodgers: awesome!
[20:35] <richardrodgers> and a number of modest improvements to the curation framework itself
[20:35] * stuartlewis (~stuartlew@gendiglt02.lbr.auckland.ac.nz) has joined #duraspace
[20:35] <richardrodgers> also the (DROID-based) format-identification tas k
[20:36] <tdonohue> richardrodgers: you might want to glance at my suggested changes in DS-939 (for site-wide curation tasks) -- to make sure it doesn't conflict with your work
[20:36] <kompewter> [ https://jira.duraspace.org/browse/DS-939 ] - [#DS-939] Enhancements to Curation Framework (Site-wide Tasks & Associated EPerson with Tasks) - DuraSpace JIRA
[20:36] <mdiggory> richardrodgers: I have a prototype for extracting a core part of MEdiaFilterManager into a separate class, I'd be curious if you took a similar approach
[20:36] <tdonohue> (admittedly, part of Ds-939 is your code though, richardrodgers -- so, the conflicts should be minimal if any)
[20:37] <richardrodgers> mdiggory: OK, but I was just going to abandon the MediaFilterManager approach altogether...
[20:37] <mdiggory> https://wiki.duraspace.org/display/DSPACE/Refactoring+MediaFilterManager+for+greater+reuse+and+flexibility
[20:37] <kompewter> [ Refactoring MediaFilterManager for greater reuse and flexibility - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/Refactoring+MediaFilterManager+for+greater+reuse+and+flexibility
[20:37] <mdiggory> This was going to be the demo I was going to use for OR11, but did not get completed in time
[20:38] <mdiggory> richardrodgers: thats all well and good
[20:38] <richardrodgers> all those interfaces (FormatFilter, MediaFilter), etc seem clunky to me, no reason to preserve
[20:39] <tdonohue> agreed, those interfaces are all a bit clunky (as are the current Packagers/Crosswalks interfaces, but those will likely have to wait for after 1.8)
[20:39] <richardrodgers> but in any case, I'll open a JIRA ticket, post the code and solicit comment
[20:40] <tdonohue> sounds good.
[20:40] <mdiggory> as long as I can write tools that don't force me to just operate on intputstreams/outputstreams I'm good
[20:40] <mdiggory> we seldom have such simple mapping requirements as are present in those interfaces
[20:41] <tdonohue> Any updates on the "Context Guided Ingest" project? (just curious if that will still make it in, or if it may need delaying)
[20:41] <mdiggory> richardrodgers: I continue to employe the group to start adopting spring for configuration, are you looking into it for this as well?
[20:42] <richardrodgers> that's up in the air ATM tdonohue. I'd love to get it in, but it's a stretch - I may reach out for collaborators..
[20:42] <mdiggory> employé = emplore (damn you OSX Lion auto replace)
[20:43] <richardrodgers> I'm also committed to fixing the tombstone stuff, I think...
[20:43] <mdiggory> TBH, I'd rather see the Submission/Reviewer workflow improvements gotten into place before further refactoring or additions
[20:43] <mdiggory> richardrodgers: if your listening in on the dspace-devel… theres a tombstone solution coming from UMich
[20:44] <richardrodgers> Oh - have you looked at it?
[20:44] <tdonohue> mdiggory: I think the push behind the Context Guided Ingest stuff was because it was something that DCAT was very interested in...but, we never really promised it'd be ready for 1.8.0
[20:44] <mdiggory> no, UMich wanted to implement a Tombstone solution and I've been advising them on implementation
[20:45] <richardrodgers> I think that was something that got 'lost in translation' from JSP to Manakin
[20:45] <richardrodgers> but thanks mdiggory I'll check in with them
[20:46] <mdiggory> yes it was
[20:46] <tdonohue> SideNote: for those wanting to dig more into Spring Configuration, I've found mdiggory's "Tao of DSpace Services" and "Spring Services Tutorial" both to be extremely helpful resources
[20:47] <tdonohue> https://wiki.duraspace.org/display/DSPACE/The+TAO+of+DSpace+Services
[20:47] <kompewter> [ The TAO of DSpace Services - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/The+TAO+of+DSpace+Services
[20:47] <tdonohue> https://wiki.duraspace.org/display/DSPACE/DSpace+Spring+Services+Tutorial
[20:47] <kompewter> [ DSpace Spring Services Tutorial - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DSpace+Spring+Services+Tutorial
[20:47] <mhwood> Thanks, I will note those.
[20:47] <tdonohue> Another SideNote: I've been messing around a bit with moving Packagers & Crosswalks to a Spring Configuration -- but, this work will *not* be ready by 1.8.0 unfortunately
[20:48] <mdiggory> thats good news....
[20:48] <tdonohue> yea, but it's still very early days, mdiggory :) It has helped me to better learn Spring-based configs though...so that's a bonus
[20:49] <tdonohue> Ok, do we have other updates to add? mdiggory, anything you want to update on the stuff listed as "@mire led"?
[20:50] <BramDS> https://jira.duraspace.org/browse/DS-968
[20:50] <kompewter> [ https://jira.duraspace.org/browse/DS-968 ] - [#DS-968] XML configurable workflow - DuraSpace JIRA
[20:50] <kompewter> [ [#DS-968] XML configurable workflow - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS-968
[20:50] <mdiggory> Yes, this is an important one, and I will be attaching the schedules we have planned for these contributions
[20:51] <mdiggory> we almost have this patch completed and it will be attached within the next week for the community to see, but be assured that, like Discovery, we are working to make switching to the new Workflow as painless as possible
[20:52] <mdiggory> It will be possible to continue to support the legacy solution while you plan porting to the new configurable workflow
[20:53] <mdiggory> and since there are still integration projects with the new workflow and the Curation Tools, we think that this is best for an initial feature contribution. It may be possible to contribute integrations of Curation Tools as future minor release fixes.
[20:54] <mdiggory> or, if resources are available, to complete those integrations during the freeze period.
[20:54] <tdonohue> Quick question on new XML Workflow. Does this *become* the default, out-of-the-box workflow system then? Just hasn't been clear to me if it is enabled out-of-the-box (or if it's more like Discovery, where you need to configure it to use it)
[20:55] <mdiggory> That is open to decision making
[20:55] <tdonohue> Also, if it doesn't support Curation Tools, then isn't that accidentally removing a feature of 1.7.x (where a Curation task could be kicked off via workflow)?
[20:56] <mdiggory> I would assume that it may be best to make decisions if we are upgrading vs fresh installing
[20:56] <mdiggory> tdonohue: the original workflow is still present for those who are not ready to abandon that feature
[20:57] <mdiggory> The XML Workflow is only enabled if switched on in the configuration.
[20:57] <tdonohue> ok. that clarifies things. I didn't fully understand that this is a completely *separate* workflow option (and that users could choose between two workflow options)
[20:57] <mdiggory> note, that integrating CurationTolls requires changes to Curation Tools, not to the XML Workflow
[20:58] <BramDS> tdonohue: curation support should be possible in the future but will be difficult since both features are currently under development
[20:58] <mdiggory> and that those changes will increase the complexity of maintaining both approaches
[21:00] <tdonohue> I'm a bit fuzzy on the complexity of Curation Tools + XML Workflow, but obviously you all have investigated it & found it difficult/complex for 1.8. So, I'm willing to take your word for it... (especially since this is just one workflow option, and the other workflow option continues to support Curation Tools)
[21:01] <mdiggory> There will be some improvements in XMLUI Aspects that will allow us to maintain separate Aspects for Submission, Reviewer Workflow and more general Administration, these will lead to greater abilities to swap out, turn off parts of the XMLUI (Submission, Review, Admin, etc)
[21:01] <tdonohue> cool..that sounds interesting
[21:02] <mdiggory> tdonohue: Basically, with hardcoded workflow steps, certain rules are hardcoded into the Curation Tools
[21:02] <mdiggory> thèse need to be moved out and be made configurable.
[21:03] <mdiggory> and on top of this, given we've adopted a separate xml and spring configuration for Reviewer Workflow, we now need to consider if certain configuration details in the curation tools should instead be part of the Reviewer Workflow
[21:04] <tdonohue> We're starting to run over time here -- any other 1.8 updates people want to interject?
[21:05] <mdiggory> I believe that we are traveling down a roadmap that looks something like 1.) refactor workflow, 2.) integrate curation tools, 3.) adopt Database driven configuration from "GSoC Submission project." By the time we've completed this roadmap (and possibly added some feature from the Context guided Ingest) we will have a fairly rich Submission and Review System for DSpace
[21:06] <mdiggory> And one that can be configured by the Collection Manager at that
[21:06] <mdiggory> without having to rebuild or restart DSpace
[21:06] <hpottinger> I'm working on something tiny, a change to the simple password auth request system (adding ability to add allow/deny rules, instead of a blanket "allow" rule) should be done and tested by next week, but it'll have to go in as a new JIRA ticket and patch, dunno if that qualifies as for 1.8, but I thought I''d mention it
[21:07] <tdonohue> mdiggory -- I agree. Just a small FYI, I know DCAT tends to be quite interested in a lot of the Submission based features (and things that can be done by the Collection Manager, etc). So, if you want feedback on any of these things, I'd recommend we try and get thoughts from DCAT
[21:08] <tdonohue> hpottinger : it definitely could qualify...it's not "too late" until after Aug 19 (and then, after that point, we can still accept bug fixes obviously)
[21:08] <mdiggory> Yes, I agree. I'd like to see the DCAT recommendations be more "first hand", possibly in the JIRA tickets themselves where possible.
[21:08] * gaurav_kl (75c62002@gateway/web/freenode/ip.117.198.32.2) has joined #duraspace
[21:09] <tdonohue> mdiggory -- they do add thoughts into JIRA tickets. Also, Bram L is on DCAT, so he can filter things through to them for feedback (as can I or Val). DCAT meetings & listserv are also public, so anyone can join (Robin T & I have been attending many recent meetings)
[21:09] <tdonohue> So, if there's things that need DCAT feedback, we can get it in front of them as soon as possible
[21:10] * robertqin (~robertqin@bb116-14-151-145.singnet.com.sg) has joined #duraspace
[21:10] <mdiggory> another aside…. It'd be good to see the DCAT meetings scheduled in the Duraspace Public Events google calendar...
[21:11] <mhwood> *sigh* must dash...thanks, all!
[21:11] <tdonohue> I'll ask Val about that. That'd make sense to me too.
[21:11] * mhwood (~mhwood@2001:18e8:3:10ab:21e:4fff:feba:a425) has left #duraspace
[21:11] <mdiggory> tdonohue: Its best to see those DCAT requests be managed publicly via community dialog, meeting notes, JIRA, etc.
[21:13] <mdiggory> One final topic… I've posted the patch for Domain Model fixes
[21:13] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Read error: Connection reset by peer)
[21:13] <mdiggory> https://jira.duraspace.org/browse/DS-845
[21:13] <kompewter> [ https://jira.duraspace.org/browse/DS-845 ] - [#DS-845] Support for DSpace Domain Model Interfaces - DuraSpace JIRA
[21:13] <kompewter> [ [#DS-845] Support for DSpace Domain Model Interfaces - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS-845
[21:13] <richardrodgers> I have to run as well, sorry. Thanks all
[21:13] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[21:14] * richardrodgers (~richardro@pool-96-237-109-89.bstnma.fios.verizon.net) Quit (Quit: richardrodgers)
[21:14] <tdonohue> mdiggory : FYI, DCAT discussions are all public actually. I think it just may be that it's not very well advertised. Public DCAT discussions are at: https://wiki.duraspace.org/display/dsforum/Home These discussions are always linked back to JIRA (usually via a JIRA comment)
[21:14] <kompewter> [ Home - DSpace Forum - DuraSpace Wiki ] - https://wiki.duraspace.org/display/dsforum/Home
[21:14] <mdiggory> Please… do have a look, note some corrects to point made in the last discussion… it does not require moving any classes out of dspace-api
[21:15] <tdonohue> mdiggory -- sounds good, I'll have a look at Ds-845
[21:15] <mdiggory> The topic of where the api resides is still open
[21:16] <tdonohue> Ok, we're we'll over time here. Do we want to close up the Developers Meeting and switch over to GSoC Updates?
[21:19] <tdonohue> hearing no response, I'm assuming we're all fine with that. We'll consider the Developers Mtg ended. We'll switch now to any GSoC updates / discussions / comments, etc
[21:19] * KevinVdV (KevinVdV@d54C14F72.access.telenet.be) Quit ()
[21:20] * BramDS (~bram@94-224-17-72.access.telenet.be) Quit (Quit: BramDS)
[21:20] * hpottinger (80cea2c6@gateway/web/freenode/ip.128.206.162.198) Quit (Quit: Page closed)
[21:20] <tdonohue> everyone got quiet all the sudden ;) Anyone have anything to bring up for GSoC discussion today? If not, that's fine...we could always call it a day, and move any other discussions to lists, etc.
[21:21] <bojans> Ok I have one notice related to REST UI project and test EC2 instance
[21:21] <bojans> Vibhaj informed me recently that there has been an increase in I/O requests, which put the instance near the monthly limits
[21:21] <bojans> I think it was about 30000 operations
[21:22] <bojans> so he disabled the instance up to the end of this month
[21:22] <mdiggory> crawlers?
[21:22] <bojans> he said it was caused internally
[21:22] <bojans> like there haven't been much external traffic
[21:23] <bojans> but will ask him again to check details
[21:24] <tdonohue> wow. ok, that's good to know. Let us know if he somehow gets charged for that (but hopefully he disabled it in time)
[21:24] <bojans> yes he disabled it in order to prevent charging
[21:24] <bojans> but we have to investigate it further
[21:24] <bojans> also thanks for the detailed harvesting explanation
[21:24] <bojans> i did copied some collections here locally
[21:25] <bojans> and it will be enough for testing
[21:25] <bojans> for this reason we postpoined transfer of those testing data to test instance
[21:25] <bojans> but he works further on documentation and polishing of other things, so there will be no gap
[21:26] <tdonohue> ok, sounds good then. If he discovers what the cause may have been, it'd be nice to know. That way we can reanalyze whether we'd want to find an alternative to the Free EC2 instances for future GSoCs
[21:27] <bojans> ok, will check it
[21:29] <mdiggory> gaurav_kl: per your question in the list, some features of submission.js will move to a new workflow.js that is separate from administrative.js
[21:30] <gaurav_kl> ok.thats what i was thinking.
[21:30] <gaurav_kl> its clear now
[21:31] <mdiggory> excellent
[21:31] <gaurav_kl> one thing more
[21:31] <gaurav_kl> you suggested a ne workspaceservice
[21:31] <gaurav_kl> instead of workspaceitem
[21:31] <gaurav_kl> why do we need
[21:31] <gaurav_kl> that
[21:32] <gaurav_kl> workspaceitem needs to be there to support the old workflow?
[21:33] * robertqin (~robertqin@bb116-14-151-145.singnet.com.sg) Quit ()
[21:34] <mdiggory> Yes, the logic is that we work to create two completely separate implementations of Submission, one that is the legacy approach and one that is the new approach and that they are completely separate from storage to api to view
[21:34] <gaurav_kl> ok
[21:36] <gaurav_kl> so in the new approach as we are removing the concept of pages..should each page be a separate action like in DescribeStep..coz giving more than 1 page in an action could be difficult
[21:36] <mdiggory> The objective is to avoid implementing JSPUI based solutions by focusing on this being a new system just for XMLUI, and given we are already doing the same for CRW
[21:37] <gaurav_kl> yeah
[21:37] <mdiggory> The topic of separate pages / actions… I'm not sure.
[21:38] <mdiggory> I'm not yet convinced we should have "pages" at all
[21:38] <mdiggory> and that each page should be a separate step
[21:40] <mdiggory> but that would require rewriting Describe Step and input-forms.xml
[21:40] <gaurav_kl> ok..but like for DescribeStep we can have 3 Actions for the 3 pages.
[21:40] <mdiggory> if a Step with multiple pages is supported, then, yes I assume each page would need to be a separate action
[21:41] <gaurav_kl> hmm
[21:41] <mdiggory> but this would require configuration in both the submission step and the input-forms.xml rather than previously just being in input-forms.xml
[21:43] <mdiggory> unless somehow the actions in the case of DescribeStep were somehow auto configured off the input-forms.xml the way pages currently are int he legacy Describe.Step.java
[21:45] <gaurav_kl> ok.what do you mean by "auto-configured"? we can separate 3 action classes from the current DescribeStep legacy code
[21:47] <mdiggory> How many pages would be allowed, how are they assigned in submission, whereas previously, they were assigned in input-forms.xml?
[21:48] <gaurav_kl> ok.
[21:49] <gaurav_kl> yeah so the "page" concept of input-forms.xml wont be used now
[21:51] <mdiggory> given the proposition of your submission solution being a wholly from legacy, you can choose to reuse existing input-forms.xml or not, I would imagine that having one or more "DescribeSteps" one for each page, would lend to eventually creating separate input-forms (xml or db driven) per Step.
[21:52] <mdiggory> "being a wholly from legacy" == "being a wholly separate implementation from legacy"
[21:53] <gaurav_kl> yeah having separate input-forms per step seems the feasible way now
[21:55] <mdiggory> can you I"m not sure, its a design dialog it might be good to get community feedback on
[21:56] <gaurav_kl> ok..i will mai the community
[21:56] <gaurav_kl> dspace-gsoc list for feedback
[21:56] <gaurav_kl> as this might be a big change
[21:57] <mdiggory> right now inputs-forms.xml contains a unified list of all forms used across the site. both the number of pages and the communities/collection they apply to
[21:57] <mdiggory> we would end up with a lot of separate input forms-xml if we attempted to split it up
[21:58] <gaurav_kl> hmm..can we link the splitted DescribeAction somehow to "page" without removing "page" from input-forms.xml
[21:59] * tdonohue (~tdonohue@c-98-228-50-45.hsd1.il.comcast.net) has left #duraspace
[22:00] <mdiggory> Maybe its time to look a little further out on the roadmap… how would you propose including your earlier input forms database GSoC work into the current project? Would this lead you to see a few steps in-between the current approach and that full integration?
[22:01] <mdiggory> can you present a bit of that model again?
[22:01] <gaurav_kl> yeah..i think with the db-driven input-forms it might be easier
[22:02] <mdiggory> your GSoC 2009 page got butchered in the wiki migration, the attachments are gone https://wiki.duraspace.org/display/GSOC/Google+Summer+of+Code+2009+Submission+Enhancements
[22:02] <kompewter> [ Google Summer of Code 2009 Submission Enhancements - Google Summer of Code - DuraSpace Wiki ] - https://wiki.duraspace.org/display/GSOC/Google+Summer+of+Code+2009+Submission+Enhancements
[22:03] <gaurav_kl> oh.
[22:04] <gaurav_kl> i can try to reuse that code
[22:08] <gaurav_kl> but it might take some time to get familiar with that code again..
[22:11] <mdiggory> At this point, if there is an interest in getting this into 1.8.0, you will need to ramp up your work to get there. If there are simpler / shorter paths to get something that works, you should consider taking them.
[22:14] <gaurav_kl> yeah..i feel for getting it before the feature freeze we might need some other approach..
[22:15] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Quit: bradmc)
[22:18] <gaurav_kl> i will look at the previous code and try to analyze
[22:18] <gaurav_kl> and will mail the list
[22:22] <gaurav_kl> i was facing one problem in my intellij.actually i created a new project to ckeck if my patch was getting applied properly
[22:23] <gaurav_kl> but in the new project my maven librairies are not getting recognized
[22:24] <gaurav_kl> i cpoied the files from the .idea/libraries folder of older project but still its not showing the JARs in "external libraries" view
[22:25] <mdiggory> You've added the parent pom in this Maven "View"
[22:25] <mdiggory> I wouldn't copy .idea files...
[22:25] <mdiggory> I'd always try to get IDEA to build the project files off of the maven poms… there will be less chances of error
[22:26] <gaurav_kl> actually i checcked iut from git outside
[22:26] <gaurav_kl> IIDEA
[22:26] <gaurav_kl> and then imported the project from local machine
[22:27] <gaurav_kl> while importing from local machine can there be an option to import maven projects
[22:30] * grahamtriggs (~Graham@cpc2-stev6-2-0-cust333.9-2.cable.virginmedia.com) Quit (Quit: Leaving.)
[22:31] <gaurav_kl> ok..i think there is an option
[22:31] <gaurav_kl> i was thinking it was there only when we checkout
[22:37] * gaurav_kl (75c62002@gateway/web/freenode/ip.117.198.32.2) Quit (Quit: Page closed)
[23:18] * mdiggory (~mdiggory@rrcs-74-87-47-114.west.biz.rr.com) Quit (Quit: mdiggory)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.