Timestamps are in GMT/BST.
[0:21] * hpottinger (~hpottinge@161.130.252.241) Quit (Quit: Leaving, later taterz!)
[6:57] -verne.freenode.net- *** Looking up your hostname...
[6:57] -verne.freenode.net- *** Checking Ident
[6:57] -verne.freenode.net- *** Found your hostname
[6:57] -verne.freenode.net- *** No Ident response
[6:57] * DuraLogBot (~PircBot@ec2-107-22-210-74.compute-1.amazonaws.com) has joined #duraspace
[6:57] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:57] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[9:03] * Jesse_Dhammu (~Instantbi@14.139.58.194) has joined #duraspace
[9:04] <Jesse_Dhammu> hellpo
[9:04] <Jesse_Dhammu> my dspace XMLUI is not working
[9:04] <Jesse_Dhammu> can you tell what could be the reason
[9:25] <helix84> Jesse_Dhammu: what do you mean by not working? Expected behaviour/actual behaviour.
[9:26] <Jesse_Dhammu> thanx for reply
[9:26] <Jesse_Dhammu> the Xmlui interface is shoing resource not found error..
[9:26] <Jesse_Dhammu> java.io.FileNotFoundException: C:\DSpace\webapps\xmlui\themes\snazy\sitemap.xmap (The system cannot find the path specified)
[9:26] <Jesse_Dhammu> but the JSPUI is working fine
[9:27] <helix84> well does that file exist? did you copy the snazy theme there? because that's not a theme that's shipped with DSpace.
[9:30] <Jesse_Dhammu> ohhhhh
[9:30] <Jesse_Dhammu> the file is in place
[9:30] <Jesse_Dhammu> but where would i get the default XMLUI theme
[9:30] <Jesse_Dhammu> i coppied the xmlui files and created another theme out of that ..
[9:31] <helix84> The default is Mirage. You specify it in [dspace]/config/xmlui.xconf
[9:34] <Jesse_Dhammu> ok let me tryu
[9:34] <Jesse_Dhammu> try
[9:36] <Jesse_Dhammu> <theme name="Kubrick" regex=".*" path="Kubrick/" />
[9:36] <Jesse_Dhammu> i replace snazy with kubrick
[9:36] <Jesse_Dhammu> is that all ..?
[9:41] <Jesse_Dhammu> helix84: i changed the text as mentioned above
[9:41] <Jesse_Dhammu> still didnt worked
[9:56] <Jesse_Dhammu> thanks dude
[9:57] <Jesse_Dhammu> it started to work
[9:57] <Jesse_Dhammu> but there i a small issue
[9:57] <Jesse_Dhammu> i need to change the default header text of kubrick and its description text on the home page
[9:57] <Jesse_Dhammu> how can i do that .,.?
[11:42] <helix84> Jesse_Dhammu: edit Kubrick.xsl
[11:42] <Jesse_Dhammu> ok
[13:12] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[14:01] * tdonohue (~tdonohue@c-98-215-0-161.hsd1.il.comcast.net) has joined #duraspace
[14:05] * Jesse_Dhammu (~Instantbi@14.139.58.194) Quit (Ping timeout: 245 seconds)
[14:30] <nic-dta> hi, i have a question about support for Fedora
[14:30] <nic-dta> Is there a IRC channel for Fedora support?
[14:31] <mhwood> Tryp #fcrepo
[14:31] <mhwood> Woops, *try* #fcrepo
[14:32] <nic-dta> thanks
[14:32] * nic-dta (~thomas@clouden.granados.se) has left #duraspace
[14:48] * robint (81d7fa56@gateway/web/freenode/ip.129.215.250.86) has joined #duraspace
[15:01] <tdonohue> Hi all, welcome. It's time for our weekly DSpace Dev Mtg. Today's agenda: https://wiki.duraspace.org/display/DSPACE/DevMtg+2015-02-11
[15:01] <kompewter> [ DevMtg 2015-02-11 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2015-02-11
[15:02] <tdonohue> I've made a few minor tweaks to the agenda just in the last hour...I accidentally left a few things around from last week that were not really necessary to have on the agenda for today :) Plus I forgot to add a discussion on GSOC
[15:02] <tdonohue> But, to kick things off, I figured the top priority right now is scheduling a DSpace 5.1 release...since we have some bugs we definitely want to fix in 5.0 in the near future
[15:02] * KevinVdV (~kevin@85.234.195.109.static.edpnet.net) has joined #duraspace
[15:03] <tdonohue> Plus, we can talk about any outstanding issues in 5.0 which would be *nice* to try to fit into the said 5.1 release
[15:03] * cknowles (~cknowles@is-lac-maclap1.is.ed.ac.uk) has joined #duraspace
[15:03] * hpottinger (~hpottinge@mu-162188.dhcp.missouri.edu) has joined #duraspace
[15:04] <tdonohue> So, 5.1 already has some fixes ready to go (on the branch), and a few more that are "in progress"
[15:04] <tdonohue> First, I guess the question is, is there anything else that you are aware of (not already under discussion elsewhere) that we should strive to get into the 5.1 release?
[15:05] <tdonohue> On the agenda, I had still listed DS-2421...which seems like a big bug in the LDAPAuthentication. But, there is a "workaround" for now. Still, if anyone has LDAP and can claim it, it shouldn't be too hard to fix (just needs an LDAP to test against)
[15:05] <kompewter> [ https://jira.duraspace.org/browse/DS-2421 ] - [DS-2421] LDAPAuthentication Plugin only supports auto-registration for Hierarchical LDAP settings - DuraSpace JIRA
[15:06] <tdonohue> are there any other issues we want to ensure get into this 5.1 release (i.e. needing more immediate eyes, but not yet getting them)?
[15:07] <hpottinger> I've been tinkering with DS-570
[15:07] <kompewter> [ https://jira.duraspace.org/browse/DS-570 ] - [DS-570] Redirect users to current page on login - DuraSpace JIRA
[15:08] <hpottinger> it's ancient, and bothersome
[15:08] * tdonohue also notes that regarding some of the 5.x JSPUI outstanding issues, I've been trying to get in touch with CINECA folks (abollini & luigi, etc)... as they seem to be one of the major JSPUI users these days
[15:08] <peterdietz> I have a potential issue that Hilton has emailed me about Elastic Search statistics dashboard, not showing countries. I haven't dug into it. (not a new 5.x bug, but a bug that might have been in older release) That I haven't dug into too much yet
[15:08] <tdonohue> (but if any other JSPUI users want to help out on any outstanding 5.x JSPUI issues, please do ping me...we need more folks working on the JSPUI these days)
[15:09] <tdonohue> hpottinger +1 to 570... I agree it'd be a great fix, whether it gets into 5.1 or later on...it's a needed one
[15:10] <peterdietz> redirect after login turned out to be a can of worms. Where should you be redirected to...
[15:10] <hpottinger> peterdietz: there's a configuration option, which is not currently honored
[15:11] <mhwood> Shouldn't the page requiring login be responsible for telling login where you came from?
[15:11] <hpottinger> however, in most cases, I think the least annoying redirect, in the case of an interrupted session (DSpace says, umm, can you log in, please?), you should be redirected to the thing you were looking for in the first place
[15:14] <hpottinger> but, back to tdonohue's earlier point: JSPUI users need to form a community, I think
[15:14] <tdonohue> In any case, I think we probably all agree 570 is something to fix. May just be a question of whether it is doable in time for 5.1, or if it just comes in later. Hopefully hpottinger can keep us updated on status & where he can use help if needed
[15:15] <tdonohue> RE: XMLUI vs JSPUI -- I'm starting to see the same thing. As we've talked recently in these meetings, we almost have two communities in one. Unfortunately for the JSPUI users, the *current* Committers team seems more XMLUI-heavy...which means we have less folks working on JSPUI at a given moment
[15:16] <tdonohue> i.e. we need more JSPUI help & support out there. If anyone out there is reading these logs (or listening in) and uses JSPUI, honestly we'd love to get you more involved in whatever way we can
[15:17] <peterdietz> Not to assume that XMLUI is without flaws, ahem, cocoon
[15:17] <tdonohue> haha, never said that, peterdietz. More simply that we have more XMLUI developers/committers trying to fix or workaround those flaws ;)
[15:18] <tdonohue> This is all a bit of a moot point now, though..as looking at the folks in this irc chat, it looks like nearly all of us are XMLUI users (IIRC)
[15:19] <tdonohue> But, I did want to let everyone know that behind the scenes I've been contacting our JSPUI committers directly to try and get some extra help. No response as of yet though, but hopefully they are all just "busy" and will respond soon
[15:20] <tdonohue> Do we have any LDAP users here today? Just curious if anyone can "claim" or dig more on DS-2421 (which I mentioned above and which has been encountered many times in the last few weeks on mailing lists)
[15:20] <kompewter> [ https://jira.duraspace.org/browse/DS-2421 ] - [DS-2421] LDAPAuthentication Plugin only supports auto-registration for Hierarchical LDAP settings - DuraSpace JIRA
[15:21] <tdonohue> Ok, hearing none, we'll move along
[15:22] <tdonohue> I'll also mention that I've been working on fixing DS-2278 (should have a PR later today) for 5.1 as well
[15:22] <kompewter> [ https://jira.duraspace.org/browse/DS-2278 ] - [DS-2278] Error pages improperly formatted on certain url patterns - DuraSpace JIRA
[15:23] <tdonohue> Anything else out there that we need to prioritize for 5.1 release?
[15:23] * misilot (~misilot@p-body.lib.fit.edu) Quit (Ping timeout: 250 seconds)
[15:25] <tdonohue> Ok, not hearing anything else. So, the next question is: Anyone (or multiple folks) willing to help chip in on getting this 5.1 release out the door in the next week or so? Ideally, in my mind, we'd strive to get this out the door by end of next week (19th or 20th), assuming all goes well with the fixes in progress
[15:27] <tdonohue> I'll be able to set aside some of my own time to help make this happen. But, would definitely appreciate any help from anyone else along the way (even just avid testers , etc.) :)
[15:29] <mhwood> I see a couple of tickets I ought to review.
[15:30] <tdonohue> testers are very welcome. Obviously as bug fix releases don't go through a full "testathon" it's really imperative that we try and get at least two +1 votes (and testers) on anything that's a more significant fix
[15:31] <hpottinger> I can help test, and even pull the lever, though we could use a few more people with release experience
[15:32] <tdonohue> even just a few of us is better than nothing. Just would appreciate someone(s) to help test and be a second (or third) pair of eyes on release announcements, etc.
[15:33] * misilot (~misilot@p-body.lib.fit.edu) has joined #duraspace
[15:34] <mhwood> Yes, I can check announcements.
[15:34] <hpottinger> tdonohue: you can count on me to help out, just ask. Are we going to have an RC for this release, or is that tdonohue?
[15:35] <tdonohue> Thinking about the 5.1 schedule, I mentioned end of next week, but now rethinking myself. I find releases announcements get more eyes at the *beginning* of a week. So, we may want to try to "wrap up" 5.1 by end of next week, but *announce* it on Monday, Feb 23. If we get done earlier than that though, great. Does this sound like a reasonable goal to you all?
[15:36] <hpottinger> Fine by me
[15:36] <mhwood> Yes
[15:36] <tdonohue> hpottinger: thanks..yea, I'm fine acting as release coordinator (RC) for 5.1
[15:37] <tdonohue> Ok, sounds like we have a general plan here. Goal is to have 5.1 "ready" by end of next week (Feb 19/20), but we'll announce on Monday Feb 23. I'll update folks if it looks like we need to change that date.
[15:37] <hpottinger> And we can drag along the conscripts for 5.0 RT as the 5.1 RT :-)
[15:38] <tdonohue> Anything else on 5.1 that anyone wants to mention? If not, we'll move along to other topics for now
[15:39] <tdonohue> Ok. hearing nothing, we'll move along. If anyone has questions, feel free to get in touch
[15:40] <tdonohue> Next on the agenda: Google Summer of Code (GSoC) 2015. The application process for organizations (who want to participate) is currently open. Those applications are due on Fri, Feb 20 (next Fri). So, the question is, do we feel like we'd want to participate this year?
[15:41] <hpottinger> we've been turned down two years in a row...
[15:41] <tdonohue> As a reminder, Google tends to recommend we *already* have a good list of possible student projects and potential mentors for each project. Without those, it's unlikely we'd get accepted.
[15:41] * KevinVdV (~kevin@85.234.195.109.static.edpnet.net) Quit (Quit: KevinVdV)
[15:42] <tdonohue> We do have a project "ideas list" from last year's application (as hpottinger mentions, we were rejected last year), and most still seem somewhat relevant: https://wiki.duraspace.org/display/GSOC/DSpace+Summer+of+Code+Ideas
[15:42] <kompewter> [ DSpace Summer of Code Ideas - Google Summer of Code - DuraSpace Wiki ] - https://wiki.duraspace.org/display/GSOC/DSpace+Summer+of+Code+Ideas
[15:42] <tdonohue> We have been rejected two years in a row...but I will mention that each time we were essentially told: "Your application looks fine, but we wanted to give more changes to new organizations. Try again next year."
[15:43] <tdonohue> But, that being said, if we just don't have enough possible mentors, then we likely should just sit this year out. I don't want to put in an application unless we feel we really want to make it happen.
[15:44] <tdonohue> Thoughts? what do you think? Should we apply again? Sit this year out? Would you want to mentor a project if we were accepted?
[15:44] <peterdietz> I don't have a crystal ball. But, if we could get dspace to accept dynamic configs. Having a student project to implement a UI for that would be good
[15:45] <hpottinger> to be blunt, it takes work to actually be able to commit to being a mentor, I don't get to decide whether I have free time to commit to other projects
[15:46] <tdonohue> peterdietz: it's a great idea, but that might be a pretty big "if" unless someone is already working on the dynamic configs. Remember we have OR2015 between now and GSoC, so I know a lot of folks tend to be busy prepping for OR2015 talks/demos/things
[15:47] <tdonohue> yes, being a mentor does take some time. If you wanted to be a mentor, you likely should either run it by your boss, or find a way to do it in your "free time" over the summer
[15:47] <hpottinger> I'm not opposed to our participating, I'm just saying I don't think I can, I should probably remove my name as a potential mentor
[15:47] <peterdietz> I think Longsight could get behind putting effort into Dynamic Configs. It's a huge support drain for us, so its got a great payoff
[15:47] <tdonohue> but, if there *is* a project that your institution would like to see happen for DSpace, and it's "doable" in the summer, then mentoring a student to *do the work* could be a win/win
[15:48] <peterdietz> Need to ensure we can fix the DSpace "plumbing" beforehand though
[15:48] <tdonohue> peterdietz: that'd be awesome. I know others have "dabbled" in dynamic configs in the past (Joao Melo, IIRC, was the latest), but it does need someone to help drive it forward. I agree it is sorely needed
[15:50] <tdonohue> So, I'm sensing that no one is "super excited" about participating in GSoC 2015 (correct me if I'm wrong)...or you are all just still thinking it through. It may be a discussion that I also need to bring to -commit list or -devel to see if there's others (not in attendance) who want to participate in GSoC
[15:51] <peterdietz> An easier project could be a REST-based UI app.. I Think we've done that before though...
[15:53] <tdonohue> peterdietz: yea, it might need "scoping" though. Trying to do the entire UI (Admin + Submit + Access) is a huge endeavor (may not be possible in a summer). But, just doing a part (e.g. just Access) may be plausible.
[15:54] <mhwood> Agreed, access should get priority. It's simple, regular.
[15:54] <tdonohue> Ok, I'll bring this GSoC topic to mailing lists as well, and we can chat through it more there. Mainly though we just need possible projects and possible mentors (who are excited to participate), before we'd apply.
[15:55] <tdonohue> Noticing we have ~5mins left here. Any other topics that anyone would like to bring up?
[15:56] <mhwood> Package builders?
[15:56] <tdonohue> mhwood is noticing the same vague reference that someone added (helix84?) into the Agenda: "There are several nice package builders to support batch ingestion, but none "in the box". Should we try to adopt one? Which one? What would be our selection criteria?"
[15:56] <mhwood> No, that was me.
[15:57] <tdonohue> Oh, ok. :)
[15:57] <tdonohue> So, what package builders are you referring too? What to explain more?
[15:57] <peterdietz> SAFBuilder
[15:58] <tdonohue> oh, I misread that... I thought you meant *non-DSpace* package builders. I understand now.
[15:58] <mhwood> And peterdietz told me that Terry Brady has a nice one too, right?
[15:58] <peterdietz> Yeah, some Georgetown PHP tools.
[15:58] <tdonohue> Yes, I agree, it might be nice to bring SAFBuilder into the main codebase (or even just into the "DSpace" GitHub project, if it doesn't "fit" into the main codebase)
[15:58] <mhwood> This is something that everybody seems to write for himself. We ought to have a good general-purpose one "in the box".
[15:59] <tdonohue> The PHP tools might be harder to argue for (since we are all Java right now), but we could link off to them as additional tools
[16:00] <tdonohue> So, peterdietz, are you wanting to contribute SAFBuilder back to DSpace? If so, I think that'd be a great addition, TBH
[16:00] <tdonohue> (for anyone following along, SAFBuilder = https://github.com/peterdietz/SAFBuilder)
[16:00] <peterdietz> Yeah, there's no reason for it to be "my" project. It can live inside dspace
[16:01] <peterdietz> It could be /dspace/bin/dspace safbuilder <args>
[16:01] <hpottinger> https://github.com/Georgetown-University-Libraries/File-Analyzer/ is Terry Brady's thing, it's a desktop Java app, not PHP
[16:01] <kompewter> [ Georgetown-University-Libraries/File-Analyzer · GitHub ] - https://github.com/Georgetown-University-Libraries/File-Analyzer/
[16:01] <mhwood> Then I can retire my hideous Perl script.
[16:01] <tdonohue> It seems (to me) like it is something that could even potentially "live" in the DSpace API itself, so that it can be hooked into the "dspace" CLI command (like peterdietz just said)
[16:02] <tdonohue> peterdietz: so if you wanted to submit SAFBuilder as a PR, I think that it should be analyzed for inclusion in 6.0. I'd vote for it, to be honest
[16:02] <hpottinger> +1 for SAFbuilder in 6.0
[16:03] <mhwood> One thing I want to mention is that tucking it into bin/dspace might not be very handy for people who want to build packages but *don't* have access to the server.
[16:03] <peterdietz> Then SAFBuilder gets tucked into dspace-api. The CLI can call it. Some UI elements could also build against it. i.e. you feed it a .zip of csv and files. It computes it all, validates, then passes it to the next stage (cleaned up input, suitable for import)
[16:04] <mhwood> Didn't we just release a feature to upload packages through the UI?
[16:04] <mhwood> I'm starting to think I need to go read our current options more closely.
[16:05] <peterdietz> Yeah, so you could have RawImportZIP, (recently added BatchImportZIP).
[16:05] <tdonohue> mhwood: yea, we did release a upload packages through UI feature. Good point.
[16:05] <peterdietz> BatchImportZIP requires valid SAF.
[16:05] <hpottinger> mhwood: I think peterdietz might be envisioning expanding that batch interface to make it "work better" with just a pile of files and a metadata csv
[16:05] <peterdietz> RawImportZIP would require csv+files.. It will bark if your input is bad. If your input is good, it will crunch it, and I guess import it
[16:05] <mhwood> Super Simple Archive Format.
[16:06] <tdonohue> +1 hpottinger. Yea, if the batch UI importer could actually *use* the SAFBuilder, then that's an argument to definitely merge SAFBuilder into the API
[16:06] <hpottinger> Really Really Simple Archive Format
[16:06] * tdonohue notes we are a bit overtime here...but we can finish up this thought/thread
[16:06] <mhwood> I think the argument is to bypass SAF altogether and just have a flat directory with asset and metadata files in it.
[16:06] * robint (81d7fa56@gateway/web/freenode/ip.129.215.250.86) Quit (Quit: Page closed)
[16:06] <peterdietz> SAF could become dead. RawImportZIP will generate SAF as an intermediary step, but it would just keep processing until the import is complete. And sites won't need to bother creating SAF, if you can just hand over the raw
[16:07] <helix84> peterdietz++
[16:07] <tdonohue> peterdietz: so, it sounds like the next step is just to get SAFBuilder into a PR for DSpace. Then hopefully we can plug more things into it, as you just noted (peterdietz++)
[16:07] <helix84> also remember that neither SAF nor batch import can currently import simple embargo
[16:08] <peterdietz> So RawImportZIP would need a zip file, containing all this stuff. RawImport(2.0) could be a glamourous UI that allows for Dragon-Drop of CSV and files, and has smiley faces, and angry-face-clippy to alert you of potential problems
[16:09] <tdonohue> peterdietz: it sounds like a good direction to me...let's get SAFBuilder into 6.0 early and we can work towards enhancing things along the way ;)
[16:09] <hpottinger> PR now!
[16:09] <peterdietz> helix84: I think we're given a free pass to ignore trickier use-cases, and just say, we designed DSpace primarily for open access
[16:09] <hpottinger> peterdietz: you're not supposed to say it out loud
[16:10] <helix84> peterdietz: so I understand merging SAFBuilder as an intermediate step before we can handle CSV + bitstreams from the UI directly?
[16:10] <tdonohue> I think SAF should eventually support embargo. I think that should be logged as a bug. But, I agree that it's not important to everyone, depending on how you use DSpace
[16:10] <peterdietz> A PR would have to provide some functionality. I would make it so that it works from XMLUI before creating PR.
[16:11] <peterdietz> I also have a SAFBuilder/ItemImport enhancement that allows you to batch import a batch to multiple collections. Its pretty crazy, and pretty awesome, if your users give you crazy input
[16:11] <peterdietz> Thus, the input is no longer crazy, since you can handle it just as easily.
[16:11] <helix84> I have to admit that if the goal is to allow CSV + bitstream import from UI, merging SAFbuilder sounds to me like a step sideways
[16:12] <peterdietz> helix84: I think dancing involves forward, sideways, and backwards steps. Its a process
[16:12] <tdonohue> helix84: not really. importing CSV + bitstream from the UI would be a major overhaul (which could take a while to do). SAFBuilder brings us one step closer, but I do agree that eventually SAFBuilder could be "refactored out" once we get to a full CSV + bitstream import
[16:13] <mhwood> Well, it's still useful for workflows that *do* include giving someone with access to the server a box of stuff and a CSV.
[16:13] <helix84> peterdietz: metaphors aside, if I enumerate the steps for the two ways to the same goal (with and without SAFbuilder), I get SAFBuilder as an extra step
[16:13] <tdonohue> helix84: so it's a question of...do we wait a (potentially) long time for someone to redo batch import with CSV + bitstreams? Or do we merge an incremental improvement with SAFBuilder that helps immediately and gets us a step closer to making batch import *easier*
[16:14] <peterdietz> I think it follows a unix model. Build a tool that does one thing well. (files+csv) -> SAFBuilder.java -> (SAF) -> ItemImport.java -> (New Items)
[16:15] <helix84> tdonohue: the thing is, you need to build a UI for SAFBuilder. Why not directly extend the BTE UI with bitstreams.
[16:15] <helix84> s/BTE/BME (=CSV)/
[16:15] <kompewter> helix84 meant to say: tdonohue: the thing is, you need to build a UI for SAFBuilder. Why not directly extend the BME (=CSV) UI with bitstreams.
[16:16] <mhwood> BTW I'm aware of a non-DSpace local project that takes metadata directly as spreadsheet files, not CSV. In case someone wants even more to do. :-)
[16:16] <peterdietz> BME doesn't create items, doesn't it just edit items?
[16:17] <tdonohue> helix84: BTE UI just takes a CSV though...you'd need a way to package up all those bitstreams referenced. Batch import takes a ZIP (which is a package of bitstreams + metadata). I agree long term merging those UIs could be nice..but it's a big project
[16:17] <helix84> peterdietz: sure it does edit, create, delete, withdraw and reinstate items
[16:17] <tdonohue> helix84: so I'm not disagreeing..I'm just noting that you are talking about a larger project than just "merge SAFBuilder" so that Batch Import is easier to use.
[16:17] <helix84> peterdietz: check out id=+ and the action column
[16:18] <tdonohue> helix84: so, *if* we have someone willing to do that larger project...awesome, let's do it. Otherwise, "merge SAFBuilder" is at least a major improvement to using the existing Batch Import
[16:19] <helix84> tdonohue: I really don't see the extra complexity (compared to the SAFBuiler UI proposal). You make it sound like a large project, where it's really a smaller one (the BME funtionality is already in the UI)
[16:19] <peterdietz> Yeah. SAF or BME. It looks like its going in the same direction. So, an overhaul should account for incorporating features of both.
[16:20] <tdonohue> helix84: then, PRs are more than welcome ;)
[16:20] <peterdietz> Merging SAF and BME to BatchEverythingEdit, adds a bit more scope to the project
[16:20] <peterdietz> But, it's probably best to streamline
[16:20] <tdonohue> I do agree though that finding a way to "merge" the interfaces for SAF & BTE & "Bulk Metadata Editing" would be a good long term goal. These are all *similar* but don't share the same underlying code yet
[16:21] <helix84> tdonohue: right. plus packager (AIP).
[16:21] <tdonohue> helix84: don't take things the wrong way though... I do agree with you. I'm just noting that I'm not going to turn down "SAFBuilder" for a "PR to be built later"... But, if someone jumps at merging those UIs, I'd take that solution *over* SAFBuilder any day
[16:22] <peterdietz> So. If SAF were plugged into DSpace, and could do the import directly, it doesn't need to do the extra work of creating a SAF package. So, would we still want it to be capable of creating a SAF package? i.e. has some other non-DSpace tool made use of SAF?
[16:22] <hpottinger> mhwood: not a single person took the bait, I have zero free time, but would love to hear more about your local tool
[16:22] <mhwood> Not *mine*, and I've told you all I know.
[16:23] <helix84> peterdietz: I bet a lot of custom tools are using SAF. I have one (which I'm working to replace).
[16:23] <mhwood> Probably most sites have their own. That's what I wanted to address.
[16:23] <hpottinger> I know there is quite a bit of Perl out there to work with SAF
[16:24] * mhwood nods
[16:24] <peterdietz> All just going in the direction of streamlining the import process. I'm getting a little bit nervous of what happens to tomcat/nginx/apache, if you make the UI do too much... The JSPUI version of BatchImport is a bit more graceful, and uses a background thread
[16:25] <helix84> there is also the external Globus work at U of Exeter (presented, but not contributed yet)
[16:25] <peterdietz> Not just people who have created 1000 different tools to create SAF, to they can import into DSpace. But imagine you had the "ideal" tool, that could take CSV+file, and import that into DSpace. Then, 900 of those custom tools don't need to exist. 100 other groups maybe have too wonky of input, that it won't fit into the solution
[16:27] <mhwood> I'd be happy to contribute any local quirks that fit into a nice general tool.
[16:27] * tdonohue notes we are nearly 30mins over time here...but I'll not stop this discussion. Just noting that we are digging into our normal "JIRA Backlog hour". We may want to "wrap this up" into a JIRA ticket or two to propose solutions
[16:29] <peterdietz> yeah. I've got to deal with sessionID's and load balancers
[16:29] <mhwood> Right now, I'm satisfied just to get this idea moving.
[16:31] <mhwood> Shall I write up a short issue: "batch submission could be less complex"?
[16:31] <mhwood> Then discussion can happen there.
[16:31] <helix84> mhwood: I think we have one for unified import UI
[16:32] <helix84> DS-2204
[16:32] <kompewter> [ https://jira.duraspace.org/browse/DS-2204 ] - [DS-2204] Consolidate/Clean Batch Import UI code - DuraSpace JIRA
[16:32] <helix84> ok, that's not it, looking
[16:32] <mhwood> It's a good idea, though.
[16:32] <tdonohue> yea, 2204 is closed. it only referred to "batch import via SAF"
[16:34] <helix84> ok, can't find one
[16:34] <tdonohue> So, I agree, we need a ticket to track this discussion & some possible options
[16:35] <helix84> if I had to daydream, it would be a UI using HTML5 File Upload API where you could drop CSV + bitstreams
[16:35] <tdonohue> helix84: that'd work great, as long as you don't have 5,000 bitstreams ;)
[16:35] <tdonohue> but, I like the idea of using HTML5 as the "default" with an option to just upload a ZIP instead
[16:36] <helix84> it would immediately show you a diff of what actions will be performed, kind of like what the CSV import UI shows now, only more streamlined
[16:36] <mhwood> My use case is when someone comes to me and says, "I have 5000 articles to load. Is there some better way than submitting them one by one?"
[16:36] <hpottinger> heh, if I had a daydream, it would be the ability to change the order (and which) metadata fields displayed on an item view page in XMLUI, without having to muck about in a theme's XSLT
[16:36] <helix84> tdonohue: I actually built such a tool (separately from DSpace) and it worked fine with about 1500 bistreams (no reason why it wouldn't work with more)
[16:37] <helix84> *works
[16:37] <tdonohue> helix84: OK, maybe I'm wrong. I was more thinking about the process of *selecting* 5,000 bitstreams to drag & drop. But, maybe they'd all be in the same directory and it'd be "easy" :) In any case, I do like going the HTML5 route anyhow by default
[16:38] <helix84> BTW the reason why I don't work on such things directly in DSpace circles back to our multiple UIs/themes problem
[16:39] * cknowles (~cknowles@is-lac-maclap1.is.ed.ac.uk) Quit (Ping timeout: 240 seconds)
[16:39] <mhwood> Currently I have one of those "someone"s with a thousand items, and nearly all of the metadata is either the same or follows a pattern, so he wants to use his spreadsheet tool to do the duplication and crank out the mechanical stuff. So being able to submit it all in one archive file is still quite useful.
[16:40] <tdonohue> yep, I fully realize that, helix84...which is why I & DSpace Steering are hoping to get us moving somewhere on that multiple UIs problem
[16:40] <helix84> I personally kind of like both UIs but I don't really love either :p
[16:41] <helix84> got to go, see you later
[16:42] <mhwood> So, what to put into Jira and who will do it?
[16:43] <mhwood> Maybe two Issues: (1) we need a less complicated workflow for offline batch submission (batch builder); (2) we need a nice gooey online batch submission system.
[16:44] <tdonohue> yea, two seems reasonable.
[16:44] <mhwood> They can probably share a good deal of logic.
[16:45] <mhwood> I can write up the offline submission ticket. Anybody want to do online?
[16:48] <mhwood> Oh, dear, I feel a third ticket coming on, somewhat related: factor all of the commandline stuff out of dspace-api into two new projects: user tools and administrator tools. Each produces an executable JAR that you can distribute to people who need such things.
[16:49] <hpottinger> write em up, let me know if you need help
[16:49] <mhwood> I'm not sure I can do justice to the online submission ticket.
[16:50] <hpottinger> mhwood: refresh my memory: eclipse, netbeans or idea?
[16:50] <mhwood> Netbeans
[16:50] <hpottinger> that's what I thought
[16:50] <hpottinger> Netbeans is next on my list
[16:50] <hpottinger> I'm not digging IDEA's Vagrant plugin alll that much, kinda clunky
[16:52] <hpottinger> there are a lot more goodies in this: http://plugins.netbeans.org/plugin/50630/vagrant
[16:52] <kompewter> [ Vagrant - NetBeans Plugin detail ] - http://plugins.netbeans.org/plugin/50630/vagrant
[17:01] <mhwood> DS-2453
[17:01] <kompewter> [ https://jira.duraspace.org/browse/DS-2453 ] - [DS-2453] we need a less complicated workflow for offline batch submission (batch builder) - DuraSpace JIRA
[17:01] <mhwood> Drat, I poked the button without editing my working title. It could perhaps be improved.
[17:02] * tdonohue has been pulled away for a bit. Obviously though, our official DSpace DevMtg time is concluded. I'll still be around though, so ping me if needed.
[17:02] <mhwood> Thanks.
[22:02] * mhwood (mwood@mhw.ulib.iupui.edu) has left #duraspace
[22:36] * tdonohue (~tdonohue@c-98-215-0-161.hsd1.il.comcast.net) has left #duraspace
[22:56] * hpottinger (~hpottinge@mu-162188.dhcp.missouri.edu) Quit (Quit: Leaving, later taterz!)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.