Timestamps are in GMT/BST.
[6:45] -barjavel.freenode.net- *** Looking up your hostname...
[6:45] -barjavel.freenode.net- *** Checking Ident
[6:45] -barjavel.freenode.net- *** Found your hostname
[6:45] -barjavel.freenode.net- *** No Ident response
[6:45] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:45] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:45] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[12:58] * tdonohue (~tdonohue@c-67-177-111-99.hsd1.il.comcast.net) has joined #duraspace
[13:06] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[18:50] * helix84 (~a@ip4-95-82-147-170.cust.nbox.cz) has joined #duraspace
[19:40] * hpottinger (~hpottinge@mu-161244.dhcp.missouri.edu) has joined #duraspace
[19:58] * bollini (~chatzilla@host241-193-dynamic.116-80-r.retail.telecomitalia.it) has joined #duraspace
[20:01] <tdonohue> Hi all..the DSpace Developers meeting will be starting momentarily, here's our agenda: https://wiki.duraspace.org/display/DSPACE/DevMtg+2013-08-28
[20:01] <kompewter> [ DevMtg 2013-08-28 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2013-08-28
[20:02] <tdonohue> we'll start things off with a few Pull Request reviews: https://github.com/DSpace/DSpace/pulls?direction=asc&page=1&sort=created&state=open
[20:02] <kompewter> [ Pull Requests · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pulls?direction=asc&page=1&sort=created&state=open
[20:03] <tdonohue> realized I accidentally skipped over PR #229 : https://github.com/DSpace/DSpace/pull/229
[20:03] <kompewter> [ Updated SWORDv2 module by richard-jones · Pull Request #229 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/229
[20:03] <mhwood> I thought we discussed it last week?
[20:04] <tdonohue> But, the status of this particular PR is that RichardJones needs support in "cleaning it up". Basically, we need someone who is more "git savvy" to help Richard out, as the current PR accidentally reverts many changes
[20:04] <tdonohue> mhwood -- nope, not in the "official meeting" (I just checked). A small group discussed it in the "JIRA Backlog review"
[20:04] <mhwood> OK, brain fade.
[20:05] * l_a_p (~chatzilla@host195-221-dynamic.55-79-r.retail.telecomitalia.it) has joined #duraspace
[20:05] <tdonohue> So, I just wanted it to be more "broadly" known (and logged), that we need some extra help on PR#229. Anyone with some extra time & some "git-fu" is welcome
[20:05] <hpottinger> I think Peter Dietz is working with Richard Jones, but I could be wrong
[20:06] <tdonohue> I don't know there's much more we can talk about regarding #229 though...so, I'm gonna move on.
[20:06] <hpottinger> and kompewter should be pinging Peter right about now
[20:06] <tdonohue> hpottinger... I've heard 'rumors' of that, but no actual proof. I think everyone suspects that PeterDietz may be...put, it'd be nice to know for sure :)
[20:07] <tdonohue> (Just really don't want #229 to slip through the cracks...it's got a lot of fixes we need to get into 4.0)
[20:07] <tdonohue> Ok...moving along to #230: https://github.com/DSpace/DSpace/pull/230
[20:07] <kompewter> [ Fix for Metadata Schema lookup by long namespace and not short name. by awaterma · Pull Request #230 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/230
[20:08] <mhwood> This one needs some more debugging. We don't know what the method is receiving that isn't working, or where it comes from.
[20:08] <tdonohue> oh yea. awaterma has been in #dspace in recent days. mhwood & I both chatted with him, and asked for some more examples of the error he's seeing (I'm still not sure I understand the problem)
[20:08] <bollini> I agree with Richard, this change is not necessary. We shouldn't have any metadata in the registry that is not bind to a schema
[20:08] <tdonohue> awaterma said he's gonna get us some more info & hopefully better examples of how to reproduce the issue he sees
[20:09] <tdonohue> So, I think we're "waiting on more info" with #230.
[20:09] <tdonohue> next up, #232 : https://github.com/DSpace/DSpace/pull/232
[20:09] <kompewter> [ [DS-1456] "dspace version" command-line script by mwoodiupui · Pull Request #232 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/232
[20:10] <tdonohue> this is the second part to DS-1456 (the basics have already been committed though for 4.0)
[20:10] <kompewter> [ https://jira.duraspace.org/browse/DS-1456 ] - [#DS-1456] "dspace version" command-line script - DuraSpace JIRA
[20:11] <hpottinger> +1 use of the word "kooky" in a commit message :-)
[20:12] * helix84 whips up a dictionary
[20:12] * awaterma_ (~awaterma@200.23.34.33) has joined #duraspace
[20:12] <awaterma_> Hi
[20:13] <mhwood> "offbeat", or "insane" but in a funny way.
[20:13] <tdonohue> so, if I've got this right... this PR creates a new "Webapp" table in the database, where any running DSpace webapp then "registers itself". This then allows the "dspace version" commandline script to report which webapps are running
[20:13] <mhwood> Yes. I didn't like doing it that way, but we had no other place visible to all running pieces of DSpace that didn't require at least as much cleanup.
[20:14] <tdonohue> hi, awaterma_: sorry, I had moved along to the next Pull Request. You can read our IRC logs up at http://irclogs.duraspace.org/index.php?date=2013-08-28
[20:14] <kompewter> [ IRC Log for #duraspace on irc.freenode.net, collected by DuraLogBot ] - http://irclogs.duraspace.org/index.php?date=2013-08-28
[20:14] <awaterma_> Will do
[20:14] <helix84> tdonohue: yes. the reason for doing it so is that one webapp listing other webapps is hard without it having some elevated privileges and elevating privileges just for this is probably a bad idea
[20:15] <helix84> tdonohue: the DB table approach is not without its issues, either - a crashed webapp would be visible as running.
[20:15] <tdonohue> mhwood & helix84: yea, I wasn't saying it's a "bad" way to "register" the running webapps...just was making sure I understood how it was working. :)
[20:16] <awaterma_> Yes, I still haven't had time to put together some more information for you guys. I'm leaving for new work in the US and have been tasked with rebuilding our DSpace server for production.
[20:16] <tdonohue> RE: #232 the only "other" way I could think of would be to write some basic "lock" file to filesystem (which signifies a particular webapp has started up)...but, I don't know that's any different/better than the DB version here.
[20:17] <bollini> why not read url informations from the dspace.cfg and make a ping ?
[20:17] <mhwood> Yes, that was my thinking.
[20:17] <helix84> tdonohue: it's the exact same thing
[20:18] <tdonohue> bollini: that works for the *primary* webapp, but it may not help you find Solr/OAI-PMH/SWORD/etc.
[20:18] <bollini> the only webapp that is not visible in the dspace.cfg is the jspui or xmlui when the other is used as primary
[20:18] <awaterma_> Basically, the issue is that when I submit metadata that is not in the main DC schema, the data does not show up. I had to use a debugger to step through source to determine that getSchemaID was returning a blind DC schema id. Hence the pull request.
[20:18] <bollini> solr and sword have properties in dspace.cfg
[20:19] <bollini> oai-pmh should have one so that we can link the interface in the home page for example
[20:19] <awaterma_> (sorry about the out of context messages)
[20:19] * hpottinger wonders if DSpace is the wrong application to ask about what's running in a particular container?
[20:20] <helix84> hpottinger: yes, hence the "register itself" approach
[20:20] <mhwood> Perhaps all of the app.s *should* have configured paths, but I don't see one for PMH.
[20:20] <tdonohue> bollini: good point. Solr & SWORD do have URLs in configs... "solr.server" and "servicedocument.url" (for SWORD). If we added one also for OAI-PMH, we might be able to get away with a "ping"
[20:21] <helix84> solr config variables can point to other hosts
[20:21] <mhwood> The other side of that coin is that we wouldn't need to configure these paths in dspace.cfg if each app. works out where it is and supplies that in the table.
[20:21] <awaterma_> Hey could you guys ping me when you have time to discuss my PR? I'm working on an init script for another project at the moment. If you prefix a comment with my name, I'll get an alert.
[20:21] <helix84> s/config/url/
[20:21] <kompewter> helix84 meant to say: solr url variables can point to other hosts
[20:22] <bollini> report an oai-pmh base url in metatag could be useful also for project like oaister, etc.
[20:22] <tdonohue> awaterma_ sure...not sure when we'll get back to it. I think we mostly just still need a good example how to replicate, and I'm not sure if we'll have a chance to talk through that in today's meeting
[20:22] <helix84> awaterma_: IMHO it's OK to discuss this asynchronously
[20:22] <helix84> bollini: but this is what this issue is about - you need A because you need A :)
[20:22] <mhwood> bollini: yes, *if* there is a well-known place to put such information so that consumers know what to look for.
[20:23] <bollini> well we are the developers of the major repository platform so we can make the standard :-)
[20:23] <tdonohue> awaterma_ : as I mentioned earlier today, I just don't have any idea how to replicate the issue you are seeing with #230, so at least I'd want more of a step-by-step process of how to replicate the problem and an example error message, etc.
[20:23] <awaterma_> [ah okay, I'll try and setup a vanilla install and replicate the error. I'm pretty sure it's reproducible with my tests for our Guzzle client for SwordV2 [https://github.com/ecosur-infonomia/sword2-client/tree/master/test]
[20:25] <tdonohue> so, with #232... would a "ping" be a "good enough" solution, going against various URLs as configured in your dspace.cfg? In a way, I kinda like that, as it also checks that you've properly set the URLs in your dspace.cfg (which can be a common issue) ;)
[20:25] <hpottinger> I'm thinking that there ought to be a way to ask the container what apps are running, and then present that information in a machine-readable fashion.
[20:25] <mhwood> bollini: I agree that *if* we had declared paths in dspace.cfg then pinging them would serve, and there would be nothing to clean up. OTOH now we have the possibility that dspace.cfg declares something that is not true, if the app.s are actually installed at other context paths.
[20:25] <tdonohue> Though, I'm not against this DB solution either... what mhwood has done is actually quite cool
[20:25] <helix84> tdonohue: no, the Solr urls are not meant for that purpose
[20:26] <tdonohue> helix84: why not?
[20:26] <bollini> mhwood: if the path on the dspace.cfg are wrong the other webapp don't run properly
[20:27] <helix84> what if the oai solr URL points to http://example.com/solr/oai? what does it tell you about the oai webapp?
[20:27] <bollini> helix84: solr provide a ping method
[20:27] <helix84> bollini: OAI solr can run fine and it's still possible OAI is not running or is not working
[20:28] <bollini> helix84: oai need a specific settings we should promove the use of a new property in the dspace.cfg to disseminate this information
[20:28] <mhwood> Notice that the code does ping the URL stored in the table, and removes dead registrations.
[20:28] <tdonohue> helix84 : right, that's why we need a separate OAI-PMH config (to ping whether OAI is actually running). But, pinging individual Solr instances is still useful to tell if Solr is also running
[20:28] <bollini> what if I make a default installation of all the webapps and next I remove something? all the webapps will be registred but not running
[20:28] <helix84> bollini: no, the OAI url is not configured in dspace configuration, it's configured in servlet container configuration
[20:29] <bollini> helix84: yes, I know. But I want to add this information in the dspace.cfg
[20:29] <helix84> bollini: so it will be in two places?
[20:29] <bollini> also the dspace.url is known to the container
[20:29] <mhwood> Actually I wonder if we could remove some of the config. that we have, and probe it out of the container.
[20:30] <helix84> bollini: IMHO configuring the same value in two places is just asking for trouble. The "register itself" solution is cleaner because a webapp knows in which context it's running.
[20:30] <awaterma_> tdonahue: Thanks for taking a look. I should have something put together tomorrow around this plan. The underlying issue is in "getMetaDataField" in Item which has a schemaId check and precludes inclusion of parsed metadata if it can't be looked up by means of the find method (during Update in Item). https://github.com/awaterma/DSpace/blob/dbce3eb21b963c8ab94f687abef2c012d161e48f/dspace-api/src/main/java/org/dspace/content/Item.java#L1819
[20:30] <awaterma_> ]
[20:30] <kompewter> [ DSpace/dspace-api/src/main/java/org/dspace/content/Item.java at dbce3eb21b963c8ab94f687abef2c012d161e48f · awaterma/DSpace · GitHub ] - https://github.com/awaterma/DSpace/blob/dbce3eb21b963c8ab94f687abef2c012d161e48f/dspace-api/src/main/java/org/dspace/content/Item.java#L1819
[20:30] <mhwood> Well-behaved servlets should not have their own opinions about where they are situated in URL space; they should be told by the container.
[20:30] <tdonohue> mhwood : what configs would you see being able to remove? (I'm definitely interested in cleaning up configs)
[20:31] <mhwood> There are a lot of URLs at the front, that we might be able to reduce or eliminate. I don't *know* that we can do this, but I'd like to find out.
[20:31] <awaterma_> tdonahue: So we lose valuable data, due to the inability to match a schemaId to an existing schema, that fails during the find lookup. Hence the secondary lookup based on Namespace.
[20:32] <bollini> mhwood: there are lot of case to take in account... load balancing, multiple url with some used only internally for maintenance
[20:32] <tdonohue> one possible problem with "removing" URLs from configs is whether it limits the ability to do things like: Run Solr on a separate server from DSpace (i.e. we probably shouldn't assume everyone is gonna run Solr on localhost)
[20:32] <awaterma_> tdonahue: all of this coming out of a verification sub-task in Item.update.
[20:33] <awaterma_> tdonahue: there's also code to handle a null schemaId that will never get triggered, due to returning the default DC schema. https://github.com/awaterma/DSpace/blob/db9f6e6f368d8c07bde844d3333ca53ab1b6b887/dspace-api/src/main/java/org/dspace/content/Item.java#L1623
[20:33] <kompewter> [ DSpace/dspace-api/src/main/java/org/dspace/content/Item.java at db9f6e6f368d8c07bde844d3333ca53ab1b6b887 · awaterma/DSpace · GitHub ] - https://github.com/awaterma/DSpace/blob/db9f6e6f368d8c07bde844d3333ca53ab1b6b887/dspace-api/src/main/java/org/dspace/content/Item.java#L1623
[20:34] * helix84 likes that this lead us to revisit architectural questions
[20:35] <mhwood> Well, this is veering away from whether 232 is an acceptable approach today. We've uncovered lots of other stuff to think about, and the version code could be reworked later to harmonize with other things we decide to do.
[20:35] <helix84> tdonohue: I think that you're misunderstanding the Solr URLs - they're not relevant in this context - on which URL a webapp lives - those two things are completely independent. Even solr and a webapp running are independent.
[20:36] * PeterDietz (~peterdiet@128.146.173.70) has joined #duraspace
[20:36] <bollini> helix84: solr can say much about other application
[20:36] <tdonohue> awaterma_ : yea, I think I grasp what you are saying... but, like Richard Rodgers, I don't really understand *how* this is happening... It seems like there is a scenario where "getMetadataField" may return null (https://github.com/awaterma/DSpace/blob/dbce3eb21b963c8ab94f687abef2c012d161e48f/dspace-api/src/main/java/org/dspace/content/Item.java#L1840). Not sure I understand the full context of the issue here.
[20:36] <kompewter> [ DSpace/dspace-api/src/main/java/org/dspace/content/Item.java at dbce3eb21b963c8ab94f687abef2c012d161e48f · awaterma/DSpace · GitHub ] - https://github.com/awaterma/DSpace/blob/dbce3eb21b963c8ab94f687abef2c012d161e48f/dspace-api/src/main/java/org/dspace/content/Item.java#L1840).
[20:37] <hpottinger> Pst, PeterDietz: http://irclogs.duraspace.org/index.php?date=2013-08-28
[20:37] <kompewter> [ IRC Log for #duraspace on irc.freenode.net, collected by DuraLogBot ] - http://irclogs.duraspace.org/index.php?date=2013-08-28
[20:37] <bollini> helix84: if you have content in the oai core your are mostly like to run the xoai , the search core says about discovery
[20:37] <helix84> bollini: what do you mean? it can't say a) whether the webapp is running b) which URL it's running on
[20:37] <tdonohue> helxi84: I fully understand that SOLR URLs are different from webapp URLs. But, both are important to know whether both are running. I realize there's a SOLR-OAI URL and a OAI-PMH URL, just like there's a SOLR Stats URL and an XMLUI URL.
[20:39] <tdonohue> helix84: e.g. if your OAI-PMH URL is failing...it'd be a huge red flag if your SOLR OAI URL is also failing.. Similarly if you are complaining that Stats aren't displaying in the XMLUI, it'd be nice to know if you SOLR Stats URL is configured properly
[20:39] <awaterma_> tdonahue: yeah, when the schema ids don't match, which is what I was getting. Hence, a backup lookup by namespace was the route I tried out. It might be just cleaner to return only valid schema IDs and throw some type of exception when the schema can't be found, that would expose any underlying issue my namespace lookup might hide. Although, from my point of view, the idea is just to get a handle to the schema by any means possible, in or
[20:39] <awaterma_> der to perform the update.
[20:39] <awaterma_> tdoanhue: that's the full context, I remember what I was trying to do there now.
[20:40] <helix84> yes, I agree it's good to know whether all 3 solr URLs has a solr running (and I don't see a problem with finding out). it's just not relevant to this issue (where and whether webapps are running).
[20:40] <mhwood> awaterma_: Richard seems to be saying that your solution shouldn't work, that something elsewhere is asking the wrong question.
[20:41] <mhwood> Possibly as part of a separate issue I (or someone) should factor "webapps running" out for multiple callers.
[20:41] <tdonohue> helix84: I actually don't agree that Solr is "not relevant to this issue". Solr itself *is* a webapp (and responds as such). It's completely relevant if we are trying to determine which webapps are running in your DSpace.
[20:41] <awaterma_> tdonahue: could you let me know why returning the DC_Schema_Id is preferable to throwing an exception or doing a backup lookup (and then throwing an exception if not found)?
[20:42] <awaterma_> tdonahue: especially in context of the validation step in Item.Update? :) https://github.com/awaterma/DSpace/blob/db9f6e6f368d8c07bde844d3333ca53ab1b6b887/dspace-api/src/main/java/org/dspace/content/Item.java#L1623
[20:42] <kompewter> [ DSpace/dspace-api/src/main/java/org/dspace/content/Item.java at db9f6e6f368d8c07bde844d3333ca53ab1b6b887 · awaterma/DSpace · GitHub ] - https://github.com/awaterma/DSpace/blob/db9f6e6f368d8c07bde844d3333ca53ab1b6b887/dspace-api/src/main/java/org/dspace/content/Item.java#L1623
[20:42] <tdonohue> awaterma_ : I'm actually not the best person to ask. I need to look closer at the code in that area (It's been a long long time since I have). RichardRodgers actually has worked with DSpace longer than I have, so I trust his opinion here. It might be best to bring some of this discussion back to your PR, maybe?
[20:43] <mhwood> I'd say that blindly returning DC_Schema_Id is wrong. But why does the second lookup succeed? Apparently the method should not be receiving namespace URIs.
[20:43] <awaterma_> tdonahue: I will, I'll pull the lines from the log and append to the PR.
[20:43] <bollini> the default to dc_schema_id was introduced for backward compatibility when in dspace there was not schema concept
[20:44] * tdonohue notes we probably need to wrap up this discussion. We've sorta taken over this meeting with a long brainstorm around tracking DSpace webapps and the like :)
[20:44] <awaterma_> ah, a bug fix! :)
[20:44] <mhwood> So, should 232 wait, for now?
[20:44] <tdonohue> I suspect we may need to bring these discussions back to their respective PRs / JIRA tickets for now... I'm not sure of a better option.
[20:45] <helix84> so, did anyone suggest a better approach to finding out webapp URL and whether it's running?
[20:45] <tdonohue> mhwood: I suspect yes, 232 might need to wait. I feel like we all need to think on this more and bring it back up in a future meeting. Not sure we have common ideas on this yet?
[20:45] <mhwood> OK.
[20:46] <awaterma_> Very good, I'm moving back to my upstart script for Node. :) You guys take care, I'll add the discussion to my PR so it's captured.
[20:46] <tdonohue> helix84: yes, the other approach suggested was the "ping each URL based on it's configuration setting". But, that spun us off into arguments ;)
[20:46] <mhwood> thanks awaterma_.
[20:47] <helix84> ..... we don't have those URLs :(
[20:47] <tdonohue> So, I suspect we have two options: (1) Do a very simple ping of URLs based on their configuration (in dspace.cfg and the like), OR (2) do #232 database option
[20:47] <tdonohue> helix84...I think you are missing the point.. we DO have most of those URLs that we need to ping. They are in config files
[20:47] <helix84> ok - use case
[20:47] <tdonohue> helix84: there's only one (or possibly two) URLs that are NOT obtainable from a config file
[20:48] <tdonohue> (and those we could add)
[20:48] <helix84> one reason we wanted to find out the webapp URL is to be able to display an OAI URL
[20:48] <helix84> where do you get it from in configuration?
[20:48] <hpottinger> for the record, I'm not opposed to the approach that 232 takes, if it scratches an itch that needs scratching, it seems fine to me... I have a hunch this information is already available, but using a DB is OK, too
[20:49] <tdonohue> helix84: right. the OAI URL is one of the few that are MISSING from the configuration. We had a suggestion (from bollini) to add a new config for the OAI URL
[20:49] <tdonohue> helix84: but, you can obtain the primary URL (XMLUI or JSPUI), SWORD URL, SWORD2 URL, and most SOLR URLs from configuration files. OAI-PMH is the only one missing
[20:49] <helix84> this is completely upside down
[20:50] <helix84> servlet container's configuration is the place which actually authoritatively says this webapp lives onthis URL
[20:50] <tdonohue> like I said... we obviously have two differing opinions being presented here.. which is why I suspect we need to think on this more
[20:50] <mhwood> Indeed, the container knows, while the config is only guessing.
[20:51] <helix84> that we happen to duplicate this information in dspace.cfg for one (or several) webapps is ... accidental design
[20:51] <tdonohue> I agree: "The container knows, while the config is only guessing", but since DSpace uses the *config* setting...something is likely to break anyways if your config setting is wrong.
[20:51] <bollini> batch script need this information too
[20:51] <tdonohue> and if the goal of this "dspace version" is to help find areas where things "broke", then knowing whether the *config* setting is wrong is beneficial!
[20:51] <helix84> tdonohue: the direction we should be thinking is opposite - remove dspace.url from dspace.cfg and find it out in runtime from the webapp
[20:52] <helix84> bollini: good point
[20:52] <mhwood> OTOH the batch script could fish it out of the database....
[20:52] <bollini> but the webapp need to be started before the batch script can guess
[20:53] <tdonohue> helix84 : I'm perfectly fine with working towards that approach..but, that's a different discussion (it's unrelated to #232).
[20:53] <bollini> note that I'm not against found a smart way to autoconfigure the system (ask to the container the url) but IMHO this is a task much harder than how it looks
[20:53] <tdonohue> +1 bollini
[20:54] <bollini> most of our tomcat are setup to a localhost as virtual host
[20:54] <helix84> yes, it is a larger discussion. would it be better to have a separate ticket / a wiki page / a separate DevMtg for it?
[20:54] <bollini> the real host is in apache via modjk
[20:54] <tdonohue> bollini & I are in agreement here. I'm NOT arguing against autoconfiguring the system (I'd love to do that)... I was just pointing out that since we are not already doing it, a simple "ping" of URLs may be good enough for "dspace version"
[20:55] <mhwood> bollini: we also run behind HTTPD (using mod_proxy_ajp).
[20:55] <tdonohue> helix84: feel free to start up a discussion place...It is a worthwhile discussion, I just worry it is "clouding" our view of PR#232 (and the "dspace version" script usage)
[20:56] * awaterma_ (~awaterma@200.23.34.33) has left #duraspace
[20:56] * tdonohue plus it has taken up an entire meeting's worth of time already :)
[20:57] <tdonohue> So, before we all have to leave today, I do want to note that I'm going to be out next week (on vacation). So, I will not be around for the meeting on Weds, Sept 4. Is there anyone who'd like to volunteer to lead that meeting?
[20:58] <helix84> i'll most likely be here. any agenda topics?
[20:58] <tdonohue> As a sidenote: I'm out *all* week long, from Sept 2-6.. So, I'm not going to be responding via email and won't be on IRC. I'm taking the week away from technology...but will be back refreshed on Monday, Sept 9
[20:59] <bollini> we need to move fast on PR because we are collecting something that could produce conflict with other merge
[20:59] <tdonohue> helix84: no specific topics as of yet. But the ongoing topic is 4.0 (and anything related to that...any JIRA tickets or PRs that need reviews/eyes)
[20:59] <helix84> ok, so we can dedicate the whole meeting to PR reviews
[21:00] <bollini> I will send an email asking for fast review on some PR: solr4, advanced embargo on jspui, sherpa/romeo, upload ajax (coming soon), ...
[21:01] <helix84> were there some changes in jspui/embargo after keiji's original PR?
[21:01] <tdonohue> helix84: Yes, you could do that. Though you might want to set aside some time for folks to "bring specific PRs to the table" (i.e. split the meeting into doing some "PR backlog" reviews, and some reviews of PRs which people feel are high-priority)
[21:01] <bollini> no... I need to finalize it
[21:01] <hpottinger> bollini, I'm happy to help review
[21:02] <bollini> this is the most important one https://github.com/DSpace/DSpace/pull/289
[21:02] <kompewter> [ [DS-1623] Upgrade DSpace-SOLR to SOLR 4 by lap82 · Pull Request #289 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/289
[21:03] <helix84> bollini: what are you using for ajax upload? Did you notice DS-1641?
[21:03] <kompewter> [ https://jira.duraspace.org/browse/DS-1641 ] - [#DS-1641] Perform Batch Imports from Administrative UI - DuraSpace JIRA
[21:03] <bollini> helix84: I'm fighting against jquery-file-upload just now...
[21:04] <helix84> bollini: incidentally, me too. we can take a look together tomorrow.
[21:04] <bollini> helix84: I have implemented ajax progress bar two year ago using the iframe + server listner aproach
[21:04] <helix84> bollini: are you on skype?
[21:04] <bollini> yes
[21:05] <bollini> lookup using my office email address
[21:05] * tdonohue notes this is a "logged channel" :) Not sure you want to advertise your skype info there
[21:05] <bollini> tdonohue: thanks, but it is an official contact channel for me ;-)
[21:06] <helix84> bollini: sent request
[21:06] <tdonohue> yes, I just wanted to add the friendly reminder...since Google indexes our IRC logs pretty heavily :)
[21:06] <mhwood> I need to go, if there is nothing else for me right now?
[21:06] <hpottinger> fyi, many people in my organization would be really interested in DS-1641
[21:07] <kompewter> [ https://jira.duraspace.org/browse/DS-1641 ] - [#DS-1641] Perform Batch Imports from Administrative UI - DuraSpace JIRA
[21:07] <tdonohue> I think we're done with the meeting for today (as we've run out of time). I'll be around for some time to chat...but no more "official topics"
[21:07] <mhwood> 'bye, all. I will look in on the PR and issue discussions.
[21:07] * mhwood (mwood@mhw.ulib.iupui.edu) has left #duraspace
[21:08] <tdonohue> yes, DS-1641 is a often requested feature. I'd also love to see it happen (and might be able to chip in with testing, etc., as it also would be a benefit to DSpaceDirect)
[21:08] <kompewter> [ https://jira.duraspace.org/browse/DS-1641 ] - [#DS-1641] Perform Batch Imports from Administrative UI - DuraSpace JIRA
[21:08] <helix84> i just wanted to say that we would need the ajax-multiple-files-uploader-with-progressbar in multiple places:
[21:08] <bollini> I'm trying to find the time to contribute back also the submission step that enable lookup in bibliographic database shown in Canada
[21:08] <helix84> * batch imports, as mentioned in the jira issue
[21:08] <helix84> * submission process upload step
[21:09] <helix84> * edit item bitstream upload
[21:09] <helix84> all of the above for JSPUI and all XMLUI themes
[21:09] <bollini> I will be not able to use the full set of features for the 4.0 contribution
[21:09] <hpottinger> I'm available to help with batch import testing (1641), ajax-uploader, and bibliographic lookup bolini just mentioned
[21:09] <bollini> but the jquery-upload-file plugin has some very important features that we should implement: chucked upload, multiple file, directory drag&drop
[21:10] <hpottinger> I know that my boss would green-light any time I spend on those topics
[21:10] <helix84> bollini: the one thing I don't have working is chunked upload. I'm wondering if it's possible to use it for automatic retries (HTTP resume). From what I read it seems possible.
[21:11] <tdonohue> helix84: yep, I agree. Though I'd hope that there'd be some "commonality" amongst those various interfaces (or at least we could work towards making them similar) :) (Not necessarily saying the XMLUI & JSPUI versions would be identical..but if we could make each of the three XMLUI ones similar and each of the three JSPUI ones similar, that'd still help)
[21:12] <helix84> tdonohue: I think that should be our primary goal because not sharing as much code as possible will make maintenance and upgrades of this feature a PITA
[21:12] <tdonohue> yep, agreed
[21:13] <helix84> tdonohue: I like how the three of us just happened to work on the same problem using the same piece of software at the same time :)
[21:14] <tdonohue> helix84: I'm actually not "working on it", yet :) I just looked into it yesterday (as it's been a high priority request also for DSpaceDirect customers), and stumbled across "jQuery-File-Upload", which is why I created Ds-1641...I was hoping maybe someone else would have time to dig in even more
[21:15] <tdonohue> I'm not sure if I'll actually find time myself to do anything related to Ds-1641 before 4.0...but, I'd definitely be able to find a little time to help test something or review something...just not sure I'll have significant development time
[21:17] <helix84> I just finished the server-side support in Jython today. It's not DSpace specific, but my specialized use case will use it to upload bitstreams to DSpace.
[21:18] <hpottinger> Helix84, I'm not averse to Jython, share? :-) Please. :-)
[21:19] <helix84> I will make it a separate project and try to include it to upstream. Now I can send you the code with all the debug statements and comments.
[21:20] <hpottinger> sounds fine, I've borrowed plenty of code this way
[21:24] * l_a_p (~chatzilla@host195-221-dynamic.55-79-r.retail.telecomitalia.it) Quit (Quit: ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812])
[21:26] <hpottinger> gotta run, keep in touch y'all :-)
[21:26] * hpottinger (~hpottinge@mu-161244.dhcp.missouri.edu) has left #duraspace
[21:51] * helix84 (~a@ip4-95-82-147-170.cust.nbox.cz) has left #duraspace
[21:54] * bollini (~chatzilla@host241-193-dynamic.116-80-r.retail.telecomitalia.it) Quit (Ping timeout: 268 seconds)
[22:03] * tdonohue (~tdonohue@c-67-177-111-99.hsd1.il.comcast.net) has left #duraspace
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.