Timestamps are in GMT/BST.
[6:49] -morgan.freenode.net- *** Looking up your hostname...
[6:49] -morgan.freenode.net- *** Checking Ident
[6:49] -morgan.freenode.net- *** Couldn't look up your hostname
[6:50] -morgan.freenode.net- *** No Ident response
[6:50] * DuraLogBot (~PircBot@184.73.169.236) has joined #duraspace
[6:50] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:50] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[10:45] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[15:38] * barmintor (~ba2213@franklin.cul.columbia.edu) has joined #duraspace
[17:50] * helix84 (~a@ip4-95-82-147-170.cust.nbox.cz) has joined #duraspace
[18:26] * misilot (~misilot@p-body.lib.fit.edu) Quit (Read error: Connection reset by peer)
[18:28] * misilot (~misilot@p-body.lib.fit.edu) has joined #duraspace
[19:02] * hpottinger (~hpottinge@mu-161244.dhcp.missouri.edu) has joined #duraspace
[19:44] * l_a_p (~chatzilla@host88-237-dynamic.12-79-r.retail.telecomitalia.it) has joined #duraspace
[20:00] * bollini (~chatzilla@host159-219-dynamic.55-82-r.retail.telecomitalia.it) has joined #duraspace
[20:03] <helix84> Hello everyone, it's time for our developer's meeting. Since Tim is not here today, I'll be a substitute for today.
[20:03] <helix84> There are no special items on our agenda, so I'd like to give you a minute to raise any points we need to discuss, especially things concerning the 4.0 release.
[20:04] <helix84> If there aren't any or after we're done discussing them, we can take the rest of the meeting to catch up on our GitGub pull request review backlog.
[20:05] <hpottinger> I'm curious to hear if anyone has tried out vagrant-dspace?
[20:06] <helix84> hpottinger: I didn't. Not recently.
[20:08] <hpottinger> I'm working on DS-1660, which will make configuring things more straightforward, and am aiming to use the new configs to drive some other features we want to add (like Pull Request testing)
[20:08] <kompewter> [ https://jira.duraspace.org/browse/DS-1660 ] - [#DS-1660] Utilize Hiera for configuration of Vagrant-DSpace - DuraSpace JIRA
[20:09] <helix84> One piece of news I can think of is that I sent the call to REST developers as we agreed. Neither Wijiti nor Jorum/Hedtek replied, but there was some buzz in our REST API working group and some activity on their Jersey implementation. There's little chance that Jersey would be anything beyond alpha in time for 4.0, but they're trying to cover at least the most important REST endpoints.
[20:10] <helix84> thanks for the progress report hardy
[20:10] <mhwood> What chance of a PR for any REST impl by end of next week?
[20:11] <hpottinger> I'm thinking the Jersey REST-API may be a bit more stable than Alpha, though mhwood makes a good point, end of next week is the target isn't it?
[20:12] * PeterDietz (~peterdiet@dietz72m1.lib.ohio-state.edu) has joined #duraspace
[20:12] <helix84> mhwood: Both of them are pretty close, but I personally don't think their developers will finish it and file a PR in time. But if you feel like trying...
[20:13] <helix84> There doesn't seem to be any discussion going on, so we can move to pull requests. If you do remember anything to discuss during the meeting, please speak up and we can interrupt the review.
[20:13] <helix84> https://github.com/DSpace/DSpace/pulls?direction=asc&page=1&sort=created&state=open
[20:13] <kompewter> [ Pull Requests · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pulls?direction=asc&page=1&sort=created&state=open
[20:13] <helix84> we'll start with PR#291: https://github.com/DSpace/DSpace/pull/291
[20:13] <kompewter> [ See https://jira.duraspace.org/browse/DS-1644 by terrywbrady · Pull Request #291 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/291
[20:13] <helix84> DS-1644
[20:14] <kompewter> [ https://jira.duraspace.org/browse/DS-1644 ] - [#DS-1644] xmlui.force.ssl ignored if authenticated user switches from https to http - DuraSpace JIRA
[20:14] <PeterDietz> Hi All, I missed the start of the meeting. I've got some basically functional /communities/ /collections/, and /items/
[20:16] <PeterDietz> I'm not sure what dspace.current.user.id is compared to dspace.user.effective
[20:16] <helix84> Hi Peter. I suggest you put your Jersey implementation up on demo.dspace.org, too. Next week will be our last DevMtg before the PR dealine, so we could play with it.
[20:18] <PeterDietz> Umm. So to get that code up there, I've got to get it somehow merged in.. Would there be some type of all-potential-features branch? that I should merge it into...?
[20:18] <mhwood> I'd rather like to see something ship out with 4.0, if it's ready enough for people to play with and comment.
[20:19] <helix84> PeterDietz: So it's not a separate webapp? Are modifications required to other DSpace webapps in order for your webapp to work?
[20:19] <PeterDietz> Pulling it into master now, and then yanking it out at last minute should be avoided.
[20:19] <PeterDietz> It is a seperate webapp, but not a seperate module any more. Its in [dspace-source]/dspace-rest, and ought to get deployed to /rest webapp
[20:20] <mhwood> That sounds like the right way.
[20:20] <PeterDietz> Code is up at: https://github.com/peterdietz/DSpace/tree/rest-jersey/dspace-rest
[20:20] <kompewter> [ DSpace/dspace-rest at rest-jersey · peterdietz/DSpace · GitHub ] - https://github.com/peterdietz/DSpace/tree/rest-jersey/dspace-rest
[20:20] <mhwood> If it touches other modules, I would suppose that those changes would be more broadly useful and not too extensive, but I should read the code....
[20:21] <PeterDietz> I've stopped myself from altering any of the other modules, though I'm tempted. i.e. one could potentially replace /xmlui/community-list with on-demand calls to REST to fetch more data
[20:21] <mhwood> Meanwhile, dspace-xmlui reads dspace.current.user.id but does not set it.
[20:21] <helix84> PeterDietz: I noticed you commited something concerning rest-jersey to DSpace/DSpace, but then I couldn't find anything. Was that a mistake you then pulled out?
[20:22] <mhwood> dspace-jspui sets and gets dspace.current.user.id.
[20:22] <PeterDietz> Yeah, I accidentally had DSpace/DSpace set as git remote origin. I did git push origin, and boom, rest-jersey went in. I then did git push origin :rest-jersey to pop it out, and then followed up with pushing it to my peterdietz/DSpace repor
[20:23] <helix84> PeterDietz: oh, ok. It got me confused :)
[20:24] <helix84> Peter: If you have any generic improvement to other modules, you can also file them separately from your REST implementation.
[20:25] <helix84> One question I wanted to ask is whether you tried to reuse the tests from Hedtek REST API for Jersey REST
[20:25] <mhwood> It looks like rest-jersey touches existing code very lightly. Looks like a good start.
[20:26] <hpottinger> helix84: I'm thinking about trying to borrow the Hedtek tests for the new API
[20:26] <PeterDietz> There's things that need to improved within DSpace. i.e. item.getMetadata(), returns you DCValue[], which is deprecated. I don't know how to replace that to the better way. So I'm just going to use that...
[20:27] <PeterDietz> I haven't dug into the Tests. I'm plowing ahead full-steam, and things could change quickly, so I haven't worked on the tests.. They are important things to get to...
[20:27] <helix84> PeterDietz: I agree you shouldn't try any heroic changes that could complicate merging. Those can be dealt with later.
[20:28] <helix84> seems like Hardy could help out?
[20:29] <hpottinger> gosh, I hear that a lot :-)
[20:29] <mhwood> dspace.user.effective is used only in dspace-xmlui. It's done with a manifest constant so it could just have its value changed and that one literal replaced.
[20:29] <helix84> on a completely unrelated note, I wanted to let the release team know that I should have some last-minute LDAP improvements
[20:30] <hpottinger> noted, though I think we already inducted you last week, didn't' we?
[20:31] <helix84> to the RT? nope, I passed :p
[20:31] <hpottinger> :-)
[20:32] <helix84> mhwood: so what should we do with PR#291?
[20:34] <mhwood> 291 looks to me like a correct fix. But I'd like to see it use the manifest constant like AuthenticationUtil does. At some point someone could change the value of AuthenticationUtil.EFFECTIVE_USER_ID to match what jspui uses, removing a possible point of confusion, but that's for later.
[20:34] * barmintor (~ba2213@franklin.cul.columbia.edu) has left #duraspace
[20:35] <helix84> mhwood: would you please comment to that effect in the PR or issue?
[20:35] <mhwood> WIll do.
[20:36] <helix84> next up: https://github.com/DSpace/DSpace/pull/294 DS-1647
[20:36] <kompewter> [ [DS-1647] Adds MetadataWebService curation task by richardrodgers · Pull Request #294 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/294
[20:36] <kompewter> [ https://jira.duraspace.org/browse/DS-1647 ] - [#DS-1647] Curation Task for Consuming Web Services - DuraSpace JIRA
[20:37] <mhwood> That sounds useful.
[20:37] <hpottinger> Another handy curation task for our stable of handy curation tasks? I have no objection, +1
[20:37] <helix84> bollini: Do you have any comments on this? Esp. regarding your RoMEO callback in submission forms?
[20:38] <bollini> it is a different use case
[20:38] <bollini> the richard PR is to allow enrichment of item metadata looking to external datasource
[20:39] <hpottinger> this green button looks tempting
[20:39] <bollini> my sherpa romeo integration is to show the publisher policy in the upload step so that the user can peek the appropriate file (pre-print, postprint, etc.)
[20:39] <helix84> I also have no objection against more curation tasks, any potential breakage should be constrained to the task itself.
[20:39] <bollini> I have read the documentation on the richard git repo and it looks good. I have only a concern
[20:40] <helix84> it adds some dependencies, but they should be apache-licensed.
[20:40] <bollini> it is about the dependencies to httpcommon we need to check if there are any conflict with solrj 4.4
[20:40] <mhwood> It draws in Apache HTTPComponents v4. We use v3 somewhere. I don't think they'll clash.
[20:41] <bollini> as I want to merge the solr4 pr tomorrow, I suggest to wait at least to have solr4 in and after fast recheck and merge the richard pr
[20:42] <mhwood> bollini: that seems reasonable.
[20:42] <helix84> Sounds good. Should I add you as a reviewer, or an assignee to Ds-1647?
[20:42] <PeterDietz> I'm curious as to how the webservice task is able to deal with either xml or json response, and how complex the mappings between it all is.
[20:43] <helix84> PeterDietz: I think it doesn only XML
[20:43] <bollini> helix84: ok, I will do a fast check if no blocking issue I will merge
[20:44] <helix84> bollini: thanks. next up: https://github.com/DSpace/DSpace/pull/295 DS-1637
[20:44] <kompewter> [ DS-1637 Support running handle server and application container on separate machines (2nd version) by tuub · Pull Request #295 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/295
[20:44] <kompewter> [ https://jira.duraspace.org/browse/DS-1637 ] - [#DS-1637] Support running handle server and application container on seperate machines - DuraSpace JIRA
[20:44] <PeterDietz> OK, I did see the XPATH in the code somewhere, and Accept header is set to text/xml. I think that is pretty straight forward then. If exists or is needed, then a different one for other data formats to be built later
[20:46] <mhwood> Conflict!
[20:46] <bollini> we should start to use this architecture in production in the next 1-2 weeks
[20:47] <hpottinger> no green button makes Max sad
[20:47] <bollini> it should be easy to me fix the conflict
[20:47] <PeterDietz> OK, so the multi-DSpace handle resolver. I'm not sure I understand the architecture yet...
[20:48] <bollini> the main question is if we agree about have this in the main codebase
[20:48] <helix84> I, personally would be happy to have it
[20:48] <PeterDietz> One handle-daemon, two DSpace servers. Get DSpace to return the yes/no and URL to resolution of handle over JSON?
[20:48] <bollini> 1 handle server many dspace repository distributed over different node
[20:48] <bollini> PeterDietz: yes
[20:49] <PeterDietz> So, the handle-daemon is a single/static machine. Are the DSpace instances replicas / i.e. load-balanced clones. Or are they different instance with different data
[20:50] <bollini> different instance with different data (and customers in our case)
[20:51] <PeterDietz> I guess this isn't the code for the handle daemon, but then I'm wondering what the updated handle daemon code looks like, to query all the nodes to get responses
[20:51] <PeterDietz> ...but I'm guessing the handle-daemon<-->DSpaceInstance contract doesn't require us to know what its like under the hood
[20:51] <bollini> no, it query only the repository that say to be able to answer for one or more prefix
[20:52] <mhwood> Given the requirements it seems reasonable.
[20:53] <bollini> the only thing that could be improved in my opinion is that this code is in part for the handle server not for dspace so it will be better if we produce a single jar to place in the handle-server lib
[20:53] <helix84> Okay, Andrea seems to have this covered (thanks again!). We have 8 minutes, shall we try one more simple PR? https://github.com/DSpace/DSpace/pull/296 DS-1422
[20:53] <kompewter> [ DS-1422 surround the file name with quotes by ottenhoff · Pull Request #296 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/296
[20:53] <kompewter> [ https://jira.duraspace.org/browse/DS-1422 ] - [#DS-1422] Duplicate Headers when bitstream has a comma in the title (Chrome) - DuraSpace JIRA
[20:53] <bollini> but this is already the case of our current handleplugin... ok go ahead
[20:54] <helix84> sorry, I didn't mean to interrupt
[20:55] <mhwood> Ds-1422: looks right.
[20:55] <PeterDietz> I'm wondering if we want to surround filename with quotes, or use some type of StringUtils . escapeSomething(...)
[20:55] <helix84> Ds-1422 seems to have 2 non-commiter confirmations. Do we still want to confirm it ourselves?
[20:56] <mhwood> Looks like the MIME spec should tell us what to do here?
[20:56] <PeterDietz> It looks like a pretty standard fix though
[20:58] <helix84> Seems like we'll be better off than we were if we accept it (it's mentioned that Moodle solves it this way). If there are more concerns about a generic solution, we could then revisit it.
[20:58] <PeterDietz> I'm fine with this as-is
[20:58] <bollini> +1 too
[20:59] <helix84> ok, I'll go ahead and push the button
[21:00] <helix84> That should be all for the official meeting, but feel free to stick around. Some interesting discussions were Vagrant and REST API.
[21:01] <bollini> Ok, I need to leave for today. See you next time
[21:01] * bollini (~chatzilla@host159-219-dynamic.55-82-r.retail.telecomitalia.it) Quit (Quit: ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812])
[21:04] <helix84> good night
[21:04] * helix84 (~a@ip4-95-82-147-170.cust.nbox.cz) Quit (Quit: helix84)
[21:04] <mhwood> I have to leave too. 'bye.
[21:05] * mhwood (mwood@mhw.ulib.iupui.edu) Quit (Remote host closed the connection)
[21:07] * hpottinger (~hpottinge@mu-161244.dhcp.missouri.edu) has left #duraspace
[21:09] * l_a_p (~chatzilla@host88-237-dynamic.12-79-r.retail.telecomitalia.it) Quit (Quit: ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812])
[21:31] * PeterDietz (~peterdiet@dietz72m1.lib.ohio-state.edu) Quit (Ping timeout: 240 seconds)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.