Timestamps are in GMT/BST.
[6:35] -calvino.freenode.net- *** Looking up your hostname...
[6:35] -calvino.freenode.net- *** Checking Ident
[6:35] -calvino.freenode.net- *** Found your hostname
[6:35] -calvino.freenode.net- *** No Ident response
[6:35] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:35] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:35] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[8:13] * grahamtriggs (~Graham@host213-123-239-134.in-addr.btopenworld.com) has joined #duraspace
[12:05] * mhwood (~mhwood@2001:18e8:3:10ab:21e:4fff:feba:a425) has joined #duraspace
[13:27] * tdonohue (~tdonohue@c-98-228-58-145.hsd1.il.comcast.net) has joined #duraspace
[16:14] * grahamtriggs (~Graham@host213-123-239-134.in-addr.btopenworld.com) has left #duraspace
[18:57] * vhollister (48c88f7e@gateway/web/freenode/ip.72.200.143.126) has joined #duraspace
[19:00] * hpottinger (80cea2c6@gateway/web/freenode/ip.128.206.162.198) has joined #duraspace
[19:47] * KevinVdV (~KevinVdV@d54C14B16.access.telenet.be) has joined #duraspace
[19:48] * grahamtriggs (~Graham@cpc2-stev6-2-0-cust333.9-2.cable.virginmedia.com) has joined #duraspace
[19:50] * robint (5229fe9f@gateway/web/freenode/ip.82.41.254.159) has joined #duraspace
[19:53] <tdonohue> hi all, reminder our DSpace Devel meeting starts here at the top of the hour. Agenda: https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-08-17
[19:53] <kompewter> [ DevMtg 2011-08-17 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-08-17
[20:00] <tdonohue> Hi all, today's DSpace Developers meeting is going to concentrate entirely on 1.8.0, since our feature freeze is on Friday.
[20:00] <tdonohue> So, because of that, I'm going to hand the reigns over to robint, to let him lead
[20:01] <robint> I'm officially Tim for one hour.
[20:01] <tdonohue> haha :) any of you are welcome to lead whenever you want to (no one ever seems to volunteer for that role though)
[20:01] <robint> Hardy has a change request that he would like to get in so perhaps we could start with a very quick review of DS-994
[20:01] <kompewter> [ https://jira.duraspace.org/browse/DS-994 ] - [#DS-994] Add allow/deny rules for self-registration in the simple password authentication module - DuraSpace JIRA
[20:03] * richardrodgers (~richardro@18.111.77.194) has joined #duraspace
[20:03] * mdiggory (~mdiggory@rrcs-74-87-47-114.west.biz.rr.com) has joined #duraspace
[20:04] <tdonohue> DS-994 sounds reasonable enough to me.
[20:04] <kompewter> [ https://jira.duraspace.org/browse/DS-994 ] - [#DS-994] Add allow/deny rules for self-registration in the simple password authentication module - DuraSpace JIRA
[20:04] <robint> Any objections ? If not I'll help out with testing and we can try and get it in for Friday.
[20:05] <robint> Ok lets move on
[20:05] <robint> grahamtriggs also contacted about a bug/issue
[20:05] <robint> Are you there graham ?
[20:06] <robint> Seems not
[20:06] <robint> Ok well lets move on to Tim's agenda
[20:07] <tdonohue> yea, we can always step back to graham, once he gets back :)
[20:07] <robint> Are there any obvious ommissions or errors in Tim's list for 1.8 ?
[20:08] <tdonohue> here's the list: https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-08-17
[20:08] <robint> The one I notice is the CC rewrite
[20:08] <kompewter> [ DevMtg 2011-08-17 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-08-17
[20:08] <richardrodgers> well, maybe cc rewrite as improvement
[20:08] <grahamtriggs> yeah, I'm here
[20:08] <robint> Aha grahamtriggs !
[20:09] <robint> Do you want to bring up that issue at the moment ?
[20:09] * sandsfish (~sandsfish@18.111.65.163) has joined #duraspace
[20:09] <grahamtriggs> seems to be mid-conversation... maybe wait a few minutes
[20:10] <robint> ok we can come back to it later
[20:10] <grahamtriggs> If anyone wants to have the source code open, they can play along later :
[20:10] <KevinVdV> About the list: An improved discovery search page will be committed tomorrow
[20:10] <grahamtriggs> .. :)
[20:11] <robint> richardrodgers: How close is the CC rewrite to being ready ?
[20:11] <robint> * thanks KevinVdV *
[20:11] <richardrodgers> I think Wendy just emailed you, but isn't it really done, with exception of a small design issue?
[20:12] <robint> I'll check my email
[20:12] <tdonohue> cool, so it should make the Feature Freeze then, richardrodgers?
[20:12] <richardrodgers> don't see why not
[20:13] <tdonohue> excellent
[20:13] <robint> Sounds good
[20:13] <robint> Perhaps I shouldn't say this but...
[20:14] <robint> I think we should be sensible about the feature freeze
[20:14] <robint> and if a day or two will allow a significant feature to be included then some flexibility should be allowed
[20:15] <tdonohue> sensible? us? (joking) :)
[20:15] <tdonohue> sounds reasonable to me as well..
[20:15] <robint> Bribes gratefully accepted
[20:15] <richardrodgers> +1 also
[20:15] <hpottinger> +1 (bribes, too)
[20:15] <mhwood> Quite reasonable, and anyway the freeze date is up to the RC, yes?
[20:16] <robint> Anyone got anything that they are struggling with and would like help with ?
[20:16] <KevinVdV> Well..... since you mention a more flexible deadline robint..... I plan to write a UI without the need of a shell script for https://jira.duraspace.org/browse/DS-749 in the weekend (It might be a good feature for Dspace 1.8)
[20:16] <kompewter> [ https://jira.duraspace.org/browse/DS-749 ] - [#DS-749] allow for bitstream display order to be changed - DuraSpace JIRA
[20:16] <kompewter> [ [#DS-749] allow for bitstream display order to be changed - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS-749
[20:17] <KevinVdV> *Is willing to bribe somebody for it*
[20:18] <hpottinger> +1 for that interface, KevinVdV, that's on my list from my community managers
[20:18] <tdonohue> oh wow. Ds-749 would be awesome to get into 1.8.0 (in my personal opinion), if it works out. I know DCAT is very excited about that (see comments in that issue)
[20:18] <KevinVdV> Well I have nothing scheduled for my weekend & create a UI for XMLUI & JSPUI
[20:18] <robint> Yeah there has been lots of Jira activity around it.
[20:19] <mdiggory> I think that KevinVdV and I could work out getting the api in by the friday cutoff, if no one objected with getting the UI work in afterwards?
[20:19] <robint> +1 from me
[20:19] <richardrodgers> I have not looked at DS-749 - does it alter the semantics of sequenceID?
[20:19] <kompewter> [ https://jira.duraspace.org/browse/DS-749 ] - [#DS-749] allow for bitstream display order to be changed - DuraSpace JIRA
[20:19] <KevinVdV> It shouldn't
[20:20] <mdiggory> no
[20:20] <tdonohue> +1 I'd have no objections for Ds-749
[20:20] <mdiggory> likewise, with my recommendations, it shifts the api changes away from bitstream and makes them a characteristic of the Bundle Container
[20:20] <richardrodgers> ok, cool that is a perennial concern of mine...
[20:21] <mdiggory> the provided solution requires adding a "order" property to the Bitstream and sorting on it
[20:21] <sandsfish> +1 i see it adds a "display_order" column to accomplish its goal.
[20:21] <robint> KevinVdV: I hope your boss will give you some time off later if you work the weekend?
[20:21] <mdiggory> my recommendations are that bundle2bitstream.order would place it into the Bundle and not require Bitstream updates to change ordering
[20:22] <mdiggory> ;-)
[20:22] <KevinVdV> robint: going to do this in my free time so don't think my boss will object
[20:23] <tdonohue> reading through mdiggory's approach (described in comments of Ds-749), it sounds right to me as well
[20:24] <mdiggory> we do this kinda stuff for the fun of it ;-)
[20:24] <mdiggory> KevinVdV: <-- geek
[20:24] <robint> :)
[20:24] <tdonohue> :)
[20:25] <mdiggory> mdiggory: <-- geek
[20:25] <KevinVdV> You don't know the half of it ;)
[20:25] <robint> Anything else ? I'll touch base with the Stuart, Kim, and Andrea to see if they are all happy
[20:25] <mdiggory> I've got another patch....
[20:26] <mdiggory> https://jira.duraspace.org/browse/DS-845
[20:26] <kompewter> [ https://jira.duraspace.org/browse/DS-845 ] - [#DS-845] Support for DSpace Domain Model Interfaces - DuraSpace JIRA
[20:26] <kompewter> [ [#DS-845] Support for DSpace Domain Model Interfaces - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS-845
[20:26] <mdiggory> this one is even more "simplified"
[20:26] <mdiggory> API interfaces are just in dspace-services-api
[20:26] <mdiggory> only class signatures change in dspace-api
[20:27] <mdiggory> all MetadataValue / DCValue enhancements are dropped
[20:27] <mdiggory> goal is to just get signatures into place so iterative work on addons can be done against 1.8.x
[20:27] <mdiggory> as addons
[20:29] <mdiggory> Because we are only talking about adding interfaces to the DSpace class signatures, the behavior of dspace is unchanges
[20:30] <tdonohue> I'll admit, this is an area I, personally, start to get a little wary just before a feature freeze. It *sounds* reasonable enough to me, but I really don't know if it will cause instability issues elsewhere that we haven't foreseen.
[20:31] <tdonohue> (I know, mdiggory, that's not what you want to hear -- I know this is an area you are definitely passionate about, and have been for a while)
[20:31] <tdonohue> what do others think here? objections? concerns?
[20:31] <sandsfish> this is where unit test coverage comes in handy.
[20:31] <mdiggory> Only cases that should encounter any work during migration are those projects that have manipulated the dspace-api classes directly and overriden them on the classpath. They would be needing to address other changes anyhow.
[20:32] <grahamtriggs> imho, it doesn't really do anything useful. You are still bounded by whatever is exposed in the interface signatures, and so still have the same 'issues' if you need to change those signatures between releases (which, ultimately, you may well do)
[20:32] <mdiggory> the unit test coverage is in dspace-api and passes same as always
[20:33] <richardrodgers> I haven't looked at the revised patch, but I also have concerns about late-stage changes...
[20:33] <mdiggory> IT separates the interface signatures from the release, so that we can write code in addons against dspace-services-api only.
[20:33] <mdiggory> and an addon can be utilized across releases
[20:33] <richardrodgers> only if api doesn't change...
[20:33] <mdiggory> perhaps if there is concern about late stage changes we should do the freeze today and not allow further work to go into the trunk?
[20:34] <sandsfish> i'm thinking that'll trample on quite a few people's plans.
[20:34] <mdiggory> other changes could possibly be even more destabilizing than this
[20:34] <grahamtriggs> I already maintain an addon that works for all versions of DSpace 1.5.0 through DSpace 1.7.2. Zero code modifications to DSpace. Same artifact and pom.xml (with range version dependency).
[20:34] <mhwood> What would allay those concerns about adding a bunch of "implements"es?
[20:36] <tdonohue> we could always do a quick +1/0/-1 vote on adding DS-845 to 1.8.0, if that helps.
[20:36] <kompewter> [ https://jira.duraspace.org/browse/DS-845 ] - [#DS-845] Support for DSpace Domain Model Interfaces - DuraSpace JIRA
[20:37] <tdonohue> I'll admit, I'm probably a 0. I'm not strongly against, but I'm also not strongly for either
[20:37] <sandsfish> since it would affect instances where people have overridden dspace-api classes, would it make sense to ask for any quick comments on the dev list?
[20:38] <sandsfish> and perhaps get a better idea of what its impact might be?
[20:38] <mdiggory> WE've been over this for about a year or more now, In both the devel list and here
[20:38] <robint> This does seem similar to a previous discussion we had
[20:38] <richardrodgers> another concern is this - we are now binding to a set of interfaces that isn't even in our trunk code?
[20:38] <mdiggory> I do not believe we need to rehash the topic int he devel list
[20:39] <mdiggory> the dspace-services will be distributed as source with the dspace-release-src for 1.8.0 if the build modifications are worked out
[20:39] <mdiggory> tdonohue, richardrodgers and myself have been through that topic in skype dialogs
[20:40] <mdiggory> WE've also worked on cleaning out /svn/repo/modules to be only those modules that are "endorsed" or "dependended" on and discussed limiting commit rights there
[20:40] <mhwood> Depends on how you look at it. If you're committed to the Services model then Services is the innermost part of DSpace, always there and always considered. If not, then this might seem like putting them off in a dimly-lit corner.
[20:40] <mdiggory> you guys got to get your heads out of the trunk
[20:41] <robint> The problem is thaat this is a step towards async releases and not all are convinced of the benefit of async releases
[20:41] <mhwood> We have a whole herd of trunks now....
[20:41] <tdonohue> To be honest, if we don't have a stream of +1's here, I'm assuming that most folks either (a) don't fully understand this change or (b) don't fully agree with this change. Either way, I'd unfortunately lean towards waiting -- cause obviously we are not all on the same page here
[20:42] <grahamtriggs> This close to a feature freeze, I would be inclined to be -1, because I don't believe the arguments for having these interfaces stand up... it's already possible to do addons that work across multiple versions, and the interfaces don't address any issues of when they might need to change.
[20:43] * tdonohue notes the conversation has been sidetracked a bit. Should we loop back around to other 1.8.0 stuff?
[20:43] <mdiggory> https://jira.duraspace.org/browse/DS-989
[20:43] <kompewter> [ https://jira.duraspace.org/browse/DS-989 ] - [#DS-989] Module directory maven property support - DuraSpace JIRA
[20:44] <kompewter> [ [#DS-989] Module directory maven property support - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS-989
[20:44] <mdiggory> We should consider discussing this
[20:45] <mdiggory> support is needed for filtering configuration in modules same as it originally was supported on a single dspace.cfg
[20:46] <richardrodgers> I might not have understood this originally - this is all just maven-driven filtering?
[20:46] <KevinVdV> Yes
[20:47] <richardrodgers> (because there is also ant filtering, and configManager filtering.....)
[20:47] <KevinVdV> This is purely maven the thing is the dspace.cfg already supports this
[20:47] <mdiggory> config manager is interpolation
[20:48] <richardrodgers> So +1 from me
[20:48] <tdonohue> seems fine to me
[20:48] <mhwood> +1
[20:48] <hpottinger> +1
[20:48] <mdiggory> maven filtering is used to build staging profiles and produce builds without requireing separate cfg files for each build. we use this with every client we work with
[20:48] <mdiggory> +1
[20:49] <tdonohue> 1.8 question: what ever happened to those extra Curation Tasks that Kim & Stuart were working on? The "link checker" and similar? I hadn't heard much since OR11...are they "in" or "out"?
[20:49] <sandsfish> +1
[20:49] <robint> tdonohue: I'll email them
[20:49] <mhwood> (Maven doc.s seem to use "filter" and "interpolate" interchangeably. Too bad, because it's confusing *and* I don't think "interpolation" really fits what Maven is doing.)
[20:49] <robint> +1 for 989
[20:50] <hpottinger> mdiggory: I'd like to see a writeup of how you're doing that for staging/production , I'm using profiles for that right now
[20:50] <robint> hpottinger: me too. I'm looking for better ideas in that area
[20:51] <tdonohue> so, anything else people have to discuss for 1.8.0? Or questions/concerns, etc?
[20:52] <robint> grahamtriggs: if you want to raise your issue now is the time ?
[20:52] <grahamtriggs> ahh... zee event dispatcher....
[20:53] <grahamtriggs> it's all a bit... well....
[20:54] <grahamtriggs> anyone got their IDEs fired up to play along? (not entirely sure how up to date the code I'm looking at is, my line numbers may be teeny bit off)
[20:54] <grahamtriggs> (note, this is just because I'm using a different machine to the one I was looking at the issue earlier)
[20:54] <mdiggory> another issue https://jira.duraspace.org/browse/DS-680
[20:54] <kompewter> [ https://jira.duraspace.org/browse/DS-680 ] - [#DS-680] invalid input syntax for type timestamp in db query for stat-initial utility - DuraSpace JIRA
[20:54] <kompewter> [ [#DS-680] invalid input syntax for type timestamp in db query for stat-initial utility - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS-680
[20:55] <mdiggory> have needed to patch this a couple times now for clients
[20:56] <grahamtriggs> So, Context.... in commit() (line 319 ish), if there are events, it gets the dispatcher (BasicDispatcher), commits the current connection, and then calls dispatch() with the current context.
[20:57] <robint> (mdiggory: bug fixes are allowed after the feature freeze so we have some room there)
[20:57] <mdiggory> ok
[20:57] <grahamtriggs> So, BasicDispatcher.... dispatch() (line 71 ish onwards). First of all, it gets the event list from the context, and passes it to Collections.synchronizedList(). Anyone want to take a stab at what the effect of this is?
[20:57] <mhwood> Ds680...grrr, testing...got bogged down...will take another look.
[20:59] * stuartlewis (~stuartlew@s-lewis.itss.auckland.ac.nz) has joined #duraspace
[21:00] <richardrodgers> grahamtriggs: is there a threading issue?
[21:00] <grahamtriggs> Ooo.... richardrodgers is getting warm
[21:00] <robint> Hi stuartlewis. Graham is in the middle of explaining something but I'll pester you in a moment if I may
[21:00] <tdonohue> grahamtriggs -- we're running short of time here, might just want to give us a hint, or the answer :)
[21:01] <mdiggory> grahamtriggs isn't in the middle, he still seems to be at the beginning
[21:01] <grahamtriggs> Ok, here's a hint.... Collections.synchronizedList().... the net effect in this context, is.... naff all
[21:01] <robint> Explain
[21:01] <richardrodgers> Ah, it's Mr Efficiency!
[21:02] <grahamtriggs> Thing is, the list that is taken from the Context, is the actual, modifiable list.... and although synchronizedList creates a wrapper, it's still backed by that modifiable list of Context.
[21:04] <grahamtriggs> So, within that method, the synchronization wrapper makes no difference. But if any of the events fired by the dispatcher causes an event to be created, then it is added to the event list of the Context, which you are iterating via a wrapper (as it's backed to the same list), and hence causes a ConcurrentModificationException
[21:04] <grahamtriggs> That's not all that's a bit screwed up though.
[21:05] <richardrodgers> but grahamtriggs: it is a violation for dispatcher to fire new events
[21:07] <mdiggory> oh here we go again...
[21:07] <mdiggory> infinite loop paranoia
[21:08] <tdonohue> running over time here folks...we probably should try "wrap this up" and perhaps bring this to JIRA? It sounds like this wouldn't be constrained by the Feature Freeze anyways, as it'd be considered a bug? so, we should have plenty more time to figure this out?
[21:08] <mdiggory> oh no, I'm having a flashback to the little office in cubespace.... sandsfish, richardrodgers and LCS..... aaaggghhhhhhh
[21:08] <grahamtriggs> richardrodgers: technically, it isn't. It just isn't recommended. Partly because, as mdiggory points out, it could end up in an infinite loop - but that can be avoided, and could even be guarded against in the dispatcher
[21:08] <robint> Aside: for those who have no interest in this particular issue, thanks for attending
[21:09] <robint> tdonohue: Whilst I have enjoyed being Tim for an hour I'll hand the microphone back to you, cheers
[21:10] <mdiggory> robint: great work being tdonohue
[21:10] <mdiggory> next week you can steal is IRC handle
[21:10] <tdonohue> ok, i'll stick around for more of this. As robint says, you all are free to filter out as you need to (If you have anything else about 1.8.0 to discuss, bring it to dspace-devel or RobinT directly)
[21:11] <tdonohue> haha...nope, you cannot steal my IRC handle, unless you have the proper password ;)
[21:11] <richardrodgers> I can stay for a little bit more..
[21:11] <robint> Darn!
[21:11] <robint> I'll hang around too
[21:12] <hpottinger> sticking around a bit
[21:12] <robint> grahamtriggs: Could you document some of this in Jira ?
[21:12] <PeterDietz> robint: any hot issues in jira that your looking at, and need to politely poke the assigned-to person?
[21:12] <sandsfish> i've got to run. thanks everyone.
[21:12] * sandsfish (~sandsfish@18.111.65.163) Quit (Quit: sandsfish)
[21:12] <robint> Thanks PeterDietz but I don't think so
[21:12] <mdiggory> didn't we make it so that the dbconnection was released by the time you got into EventManager?
[21:13] <richardrodgers> grahamtriggs: one could copy the event list to avoid this, but 'well-behaved' consumers don't do it - and there is (albeit) small overhead in the copy...
[21:13] <robint> I'm wondering if stuartlewis is listening in ?
[21:13] <mdiggory> so that the Context was basically useless at that point
[21:13] <stuartlewis> robint: Hello! :)
[21:14] <mdiggory> welll accept for delivering the events and user details
[21:14] <richardrodgers> not useless mdiggory - the cache is still there, so consumers don't need to hit the DB again....
[21:14] <mdiggory> ok, well, almost useless ;-)
[21:15] <robint> stuartlewis: Got any 1.8 concerns etc ?
[21:16] <stuartlewis> Not really.
[21:16] <stuartlewis> Should I> ;)
[21:16] <stuartlewis> Should I? ;)
[21:16] <robint> Hope not :)
[21:17] <KevinVdV> Got to run cya
[21:17] <robint> tdonohue asked earlier about some curation tasks you hoped to get in ?
[21:17] * KevinVdV (~KevinVdV@d54C14B16.access.telenet.be) Quit (Quit: KevinVdV)
[21:17] <stuartlewis> To be completely honest I've not been able to dedicate so much time to DSpace over the past few months.
[21:17] <tdonohue> stuartlewis: I was asking about the new curation tasks that you & Kim were developing (link checker, etc). Are those still coming in 1.8? (Just curious)
[21:17] <mhwood> Must go. 'bye all.
[21:17] * mhwood (~mhwood@2001:18e8:3:10ab:21e:4fff:feba:a425) has left #duraspace
[21:17] <stuartlewis> kshepherd is our curation guru - he'd have a better idea about what general tasks we have that we might want to donate.
[21:18] <grahamtriggs> richardrodgers: yes, you can copy the list. ideally, you would flatten it in the context, allow new events to build up, and loop back over them if necessary. There is an interesting discussion about 'well-behaved' consumers though....
[21:18] <stuartlewis> Yes - I have a half written link checker - works fine, but ideally requires a small bit of re-engineering.
[21:18] <richardrodgers> stuartlewis: if not Dspace, anything fun?
[21:18] <robint> Ok thanks, I'll maybe drop you both an email just to get an update
[21:18] <stuartlewis> define: fun! :)
[21:18] <robint> fun = well paid
[21:19] <stuartlewis> Mainly preparing our systems (Symplectic + DSpace) for our up-coming national research assessment exercise (equivalent of RAE / REF in the UK)
[21:19] <grahamtriggs> my consumer does (or rather can, if necessary) make changes to the item, if it detects that it is in a certain state. The way I now have it is both safe in terms of infinite loop, and with respect to the concurrentmodificationexception.
[21:20] <stuartlewis> The main feature I have waiting for a bit of TLC before comitting it is the enhancements to batch metadata editing to i) improve error messages, and ii) add 'actions' such as withdraw / reinstate / delete.
[21:20] <tdonohue> grahamtriggs: are you planning to post that up to JIRA as a patch? so we can get a closer look at what you have done?
[21:20] <richardrodgers> grahamtriggs: I don't deny one can do it - but there is also the interesting question of transactional closure - you are creating a new tx
[21:21] <grahamtriggs> tdonohue: I haven't done anything to DSpace (yet). I've worked around the known issues in the consumer, I'm just pointing out the problems exist.
[21:22] <tdonohue> grahamtriggs: sorry, misunderstood. I realized that right after I posted that last message.
[21:23] <richardrodgers> Our initial hope was that documentation would keep consumer writers out of trouble - but I'd also be interested in programmatic solutions (and examining their costs....)
[21:24] <grahamtriggs> richardrodgers: I'm not particularly bothered about transactional windows in this instance (as in, I can live with this happening in a separate transaction). What's more important is being able to hang code off of things happening within the repository without modifying the core code.
[21:27] <richardrodgers> So then you would accept if an event-triggered tx is rolled back, but the preceding tx commits? That bothers me a bit
[21:28] <richardrodgers> since one logically depends on the other....
[21:31] <richardrodgers> but I completely agree with the importance of staying out of core code.
[21:32] <grahamtriggs> in this case, yes, it's ok. in some cases, it may not be... but then I've long advocated 'immediate', or pre-commit, events
[21:33] <grahamtriggs> (as an additional feature, alongside the post-commit events)
[21:34] <richardrodgers> One line of development that we never had time to pursue in this area is 'in-process/in memory' but asynchronous event handling - it might have allowed more flexibility in this area without sacrificing performance (like a real JMS-type solution might)
[21:35] <kshepherd> to whoever is still around: sorry i keep missing meetings, too early for me! would love some feedback on the latest DS-768 stuff if anyone has time to check before Friday
[21:35] <kompewter> [ https://jira.duraspace.org/browse/DS-768 ] - [#DS-768] All XMLUI Error Pages respond with 200 OK, instead of 404 Not Found - DuraSpace JIRA
[21:37] <richardrodgers> the idea is that your consumer could post to some queue or other that lived in a different DB context - so no infinite loops, etc
[21:37] <hpottinger> kshepherd I plan to play around with the Ds-768 patch, as soon as I've got Ds-994 confirmed working
[21:39] <grahamtriggs> richardrodgers: in itself, that wouldn't stop infinite loops - if the consumer causes an event, which the consumer responds to and then causes an event, etc..... that cycle still goes on forever without a little engineering to stop it.
[21:39] <tdonohue> kshepherd: note, Ds-768 is a bug -- so, it can also be fixed after Feature Freeze on Friday. Feature Freeze is only the deadline for new features & new improvements. Bugs can be fixed all the way up to the final release (though, obviously the sooner the better).
[21:40] <grahamtriggs> in essence, what we have is already asynchronous... all that it's really missing is to 'snapshot' the current events before iterating them, and at the end re-iterate over any newly generated events, until there are no events left.
[21:41] <richardrodgers> but even that is no cure for loops, right?
[21:42] <grahamtriggs> btw, I already stop 'infinite loops' quite effectively. How? In my consumer, I record the identity of the context object. I 'fail quick' on a consume if I've already logged that context identity, and the end removes the context identity.
[21:43] * mdiggory (~mdiggory@rrcs-74-87-47-114.west.biz.rr.com) has left #duraspace
[21:43] <richardrodgers> well, then you are burdening the consumer with being stateful, which we tried to avoid...
[21:43] <grahamtriggs> the simplest solution would be to have a base consumer class that all consumers extend (to hold the identity logging), or it could go into the dispatcher (probably more accurately, the consumerprofile)
[21:43] <kshepherd> tdonohue: true..
[21:45] <tdonohue> kshepherd -- I would be willing to help test. Not sure if I'll get to it before Friday though (I may, we'll see).
[21:46] <tdonohue> kshepherd : I had asked stuart about this as well. I recall mention at OR11 that you might be submitting some new Curation Tasks for 1.8.0? I was just curious if that's still the plan, or if it's not as likely after all (I hadn't heard anything since then).
[21:47] <kshepherd> robint: i'll get some curation tasks together incase you want to include some more examples in org.dspace.curate... I still haven't had any really good ideas for alternative distribution of curation tasks but it feels slightly odd to have them sitting where they are. Perhaps we could at least move them to org.dspace.curate.examples or org.dspace.curate.tasks for 1.8
[21:47] <kshepherd> tdonohue: snap :)
[21:47] <tdonohue> haha :)
[21:47] <kshepherd> let's see...
[21:49] <robint> Hi kshepherd: Sorry, I've just got to head off. I'll drop you an email just to catch up on 1.8 and anything else I can think of :)
[21:49] <robint> Cheers all
[21:49] <kshepherd> we've got linkchecker, google translate, microsoft translate, a URI 'regenerator' (for handle changes), exif metadata extraction, ingest bitstream from filesystem path (specified in metadata)
[21:49] * robint (5229fe9f@gateway/web/freenode/ip.82.41.254.159) has left #duraspace
[21:49] <kshepherd> that's probably the stuff that's generic-enough to suit other users
[21:51] <richardrodgers> sounds great kshepherd - I'm peddling the idea of task bundles that folks can pick up async, but it's (*cough*) a controversial approach ATM
[21:51] <kshepherd> ;)
[21:51] <richardrodgers> but the important thing is to get it out somehow
[21:52] <tdonohue> I'd call richardrodgers approach more of a "extension" or "addon" approach (not to be confused with mdiggory's "async" ideas).
[21:52] <tdonohue> (async is becoming a bit of a "loaded" term)
[21:52] <kshepherd> i want to make a customised dspace repo full of curation tasks, but i keep getting stuck when thinking about peer review, quality/safety (if shipping as compiled jars), dspace version compatibility (if shipping compiled jars), or making them easy to install (if shipping as mvn projects)
[21:53] <richardrodgers> I will also soon have some added services in curation framework (hopefully 1.8) like automatically clearing context objects for you, etc
[21:53] <hpottinger> demo was made for this kind of thing, yes?
[21:53] <kshepherd> so far, i've encouraged others that want to use curation tasks to set up a tiny maven project just for that, with dspace-api as a dependency
[21:54] <kshepherd> hpottinger: none of the actual content is demo would be considered 'real' or persistent or safe ;)
[21:54] <richardrodgers> yes kshepherd - that's how we've done it as well
[21:54] <kshepherd> richardrodgers: automatic context clearing sounds nice :)
[21:55] * kshepherd has to run to a tutorial now
[21:56] <tdonohue> yea, demo is not to be assumed "persistent". It's more for demonstrating how DSpace works (and for testathons). I'd be concerned about making it a repo for "addons" (or curation tasks), cause we give away full admin rights to everyone ;)
[21:57] <richardrodgers> I have to run also, but I'm eagerly looking forward to a design from grahamtriggs on 'smart dispatching' ;)
[21:58] * richardrodgers (~richardro@18.111.77.194) Quit (Quit: richardrodgers)
[22:00] <hpottinger> tdonohue: I was mostly thinking of, wherever the tasks live, you could run them on demo, or a copy of demo.
[22:02] <tdonohue> oh, so "demo" them on demo.dspace.org? Yea, we could do that for curation tasks. We'd just need to make it clear how to obtain those tasks (so that people realized they were not out-of-the-box), where they are documented, how supported, etc
[22:02] * hpottinger is being kicked out, summer hours at the library, later!
[22:03] * hpottinger (80cea2c6@gateway/web/freenode/ip.128.206.162.198) Quit (Quit: Page closed)
[22:08] * tdonohue (~tdonohue@c-98-228-58-145.hsd1.il.comcast.net) has left #duraspace
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.