Timestamps are in GMT/BST.
[6:30] -holmes.freenode.net- *** Looking up your hostname...
[6:30] -holmes.freenode.net- *** Checking Ident
[6:30] -holmes.freenode.net- *** Found your hostname
[6:30] -holmes.freenode.net- *** No Ident response
[6:30] * DuraLogBot (~PircBot@ec2-107-22-210-74.compute-1.amazonaws.com) has joined #duraspace
[6:30] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:30] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[8:20] * pbecker (~pbecker@ubwstmapc098.ub.tu-berlin.de) has joined #duraspace
[12:59] * tdonohue (~tdonohue@c-73-45-154-218.hsd1.il.comcast.net) has joined #duraspace
[13:01] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[13:32] * awoods (~awoods@c-67-165-245-76.hsd1.co.comcast.net) has joined #duraspace
[14:54] * cknowles (~cknowles@is-lac-maclap1.is.ed.ac.uk) has joined #duraspace
[14:54] * kohts (~kohts@195.68.180.4) has joined #duraspace
[14:56] <tdonohue> <5 minute warning...the DSpace Dev Mtg starts at the top of the hour
[14:57] <tdonohue> In the meantime, today's agenda is at: https://wiki.duraspace.org/display/DSPACE/DevMtg+2015-06-17
[14:57] <kompewter> [ DevMtg 2015-06-17 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2015-06-17
[14:58] <mhwood> Audio check: wondering yesterday why "export metadata" from an Item yields CSV instead of tag/value pair lines or some such, which would seem more immediately useful.
[14:59] <mhwood> Last night I wrote a tiny Ruby script to reformat these 2-line exports.
[15:00] <tdonohue> mhwood: pretty sure it exports CSV as that's the "Batch Metadata Editing" format
[15:01] <mhwood> Sensible.
[15:01] <tdonohue> In any case, it's DSpace Developer Meeting time. Agenda: https://wiki.duraspace.org/display/DSPACE/DevMtg+2015-06-17
[15:01] <kompewter> [ DevMtg 2015-06-17 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2015-06-17
[15:02] <tdonohue> So, as you all surely already know, last week was OR15. Lots happened. There's way too much to summarize ;)
[15:03] <tdonohue> I just sent (across lists) links to the DSpace Technology Roadmap talk (video & slides) for anyone who did NOT get to see it yet
[15:03] <tdonohue> They are also in the agenda
[15:03] <tdonohue> hpottinger also has a great summary of his "take aways" from OR15 which I'd encourage folks to read: http://lso.umsystem.edu/~pottingerhj/article/47/or-2015-recap
[15:03] * srobbins (~srobbins@libstfsdg02.library.illinois.edu) has joined #duraspace
[15:03] <kompewter> [ article: hardy@lso: OR 2015 Recap ] - http://lso.umsystem.edu/~pottingerhj/article/47/or-2015-recap
[15:03] <pbecker> tdonohue: can you (or someone else) summorize what features you expect for 6.0 after you talked to several probably contributors?
[15:04] <tdonohue> pbecker: excellent question :)
[15:05] <tdonohue> 6.0 still seems very much "up in the air" in terms of exact features. Admittedly, because of excitement around the Roadmap (7.0 and beyond), the amount of time spent on 6.0 was not ideal. So, https://wiki.duraspace.org/display/DSPACE/DSpace+Release+6.0+Status is still the best "list" we have, which leaves us with more work to do
[15:05] <kompewter> [ DSpace Release 6.0 Status - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DSpace+Release+6.0+Status
[15:07] <tdonohue> I will mention though that I have a call with @mire scheduled for tomorrow to talk about a possible contribution from them.... a "Services API + Hibernate", i.e. some low-level refactoring that might be of interest
[15:07] <cknowles> what can we do as prep for 7 that can go in 6?
[15:08] <pbecker> I'm highly interested in Hibernate, would be great to get some news about it asap.
[15:08] <tdonohue> I'll be talking with @mire about getting the code in our hands ASAP along with enough info to start to analyze it for possible addition in 6.0. It sounds like they may want to even potentially do a short presentation to Committers/developers on this refactoring idea
[15:08] <cknowles> would be good to get it in early
[15:09] <tdonohue> cknowles: This refactoring of the codebase from @mire *might* actually be beneficial to 7.0 (as it starts to "modularize" DSpace). But, I'll admit, I don't know enough *yet* to be certain
[15:10] <tdonohue> But, to cknowles point, I think there are also some "cleanup" tasks that we NEED to achieve in 6.0. First and foremost is finally *removing* support of Lucene search and DB-based browse (both have been deprecated since 4.x)
[15:10] <helix84> pbecker: it's mostly Kevin's work, this is the repo, though they may have something newer: https://github.com/KevinVdV/dspace-hibernate-datamodel
[15:10] <kompewter> [ KevinVdV/dspace-hibernate-datamodel · GitHub ] - https://github.com/KevinVdV/dspace-hibernate-datamodel
[15:10] <mhwood> I recall that near the end of 5.0 there were two offers of "author profiles" or something like it, and no time to evaluate or harmonize them. Maybe we can move that forward, if we start Really Soon Now?
[15:11] <tdonohue> helix84 & pbecker: there is newer code from KevinVdV's work to create a Service API & enable hibernate. This is the latest I'm aware of: https://github.com/KevinVdV/DSpace/tree/dspace-service-api
[15:11] <kompewter> [ KevinVdV/DSpace at dspace-service-api · GitHub ] - https://github.com/KevinVdV/DSpace/tree/dspace-service-api
[15:11] <pbecker> helix84: thanks, I know this one.
[15:12] <helix84> hold on to your hats :) 1,050 changed files with 8,490 additions and 12,479 deletions.
[15:12] <tdonohue> mhwood: while that's a nice idea, I worry that discussion of "Author Profiles" is destined to snowball into a larger argument of the DSpace data model (which dspace-cris changes in order to support their "author profiles"). I'm not sure it's achievable for 6.0 to be honest
[15:13] <mhwood> I mentioned to Bram at OR that this contribution seems to contain a number of features which might be easier to evaluate if they were disentangled.
[15:13] <mhwood> "profiles": well, with the recent surge of interest in ORCID, I thought I'd mention it.
[15:14] <helix84> mhwood: yes, it will make much more sense to work on both ORCID and author profiles when we have contributors as first-class entities in DSpace
[15:15] <tdonohue> mhwood: I agree, "profiles" are of very high interest. I just think the discussion may need to wait for "modularizing" DSpace (or at least a plan for how to do so), and possibly data model refactoring discussions (which helix84 also notes as "contributors as first-class entities"
[15:16] <mhwood> I agree that there may already be so much that we need to do in 6.0 that profiles may be too much to add. Then again, maybe not, if additional developers join in.
[15:17] <tdonohue> Another option for 6.0 which is not exactly "flashy" but could be highly beneficial.... actually starting to "tease apart" a business logic layer (to build new UIs on). It's unfortunately not a huge "feature" itself though it could add features to REST API (as there are gaps in what that REST API can do)
[15:18] <tdonohue> But, that is also another potentially larger "refactoring"...and we have @mire's refactoring to first review
[15:18] <mhwood> Is this actually a new layer, or just a more disciplined approach to whether code belongs in dspace-api or dspace-$UI?
[15:18] <tdonohue> (I just thought I'd throw that out there though, as it'd be highly beneficial to the roadmap)
[15:19] <cknowles> think ‘business logic layer’ and REST API work would be great for building UI demos on
[15:20] <tdonohue> mhwood: the latter. I'd hope it's *not* a new layer. One option is that it *could* be turning "dspace-rest" into a "dspace-web-api" (which can be called via either REST or Java). But, at the very least, it's trying to get code in the "right" place so logic isn't repeated in each UI layer
[15:21] <tdonohue> +1 cknowles. This refactoring would be highly beneficial to UI prototyping work. It may end up being necessitated by UI prototyping (at least to some extent)
[15:21] <mhwood> Looking at it from the other end, UI work can be used to drive common functions out of the existing UIs into dspace-api.
[15:22] <helix84> mhwood++
[15:24] <tdonohue> mhwood: yes, that's kinda what I'm referring too when I say "it may end up being necessitated by UI prototyping"....in that as UI prototypes get moving, they may need to move common functions elsewhere in order to avoid repeating them. But, we'd need to be *careful* that the UI prototypes don't just copy business logic into their new UI layer
[15:24] <cknowles> sorry got to go. Later meetings crazily are generally more convenient!
[15:24] <tdonohue> i.e. we don't want UI prototypes that just repeat this same bad design of business logic in the UI layer, just cause it's "easier for now"
[15:24] <helix84> i'll have to disappear soo, too
[15:25] <mhwood> Yes, exactly: if UI code is making policy decisions, for example, that's wrong.
[15:25] <tdonohue> hence, it might be nice to also think about *what we want* in a "business logic layer", so we have a vision towards moving there (even if it's gradual)
[15:27] <tdonohue> One option here is to *start* to get in front of the problem by moving "business logic" over to either 'dspace-api' AND/OR 'dspace-rest'. If more goes to "dspace-rest", it could be logically renamed the 'dspace-web-api' (and encouraging all UIs use that API either via Java calls or REST calls)
[15:28] <mhwood> I tend to think of dspace-rest as another UI -- a machine-to-machine UI.
[15:28] <pbecker> mhwood++
[15:28] <tdonohue> but again, this is a bigger refactoring project...and we might need more info on what @mire has already done to see if it is (a) acceptable, and (b) affects how we'd do business logic API work
[15:28] <pbecker> dspace-rest depends on dspace-api
[15:28] * cknowles (~cknowles@is-lac-maclap1.is.ed.ac.uk) Quit (Ping timeout: 250 seconds)
[15:29] <helix84> one example would be enforcing access policies solely at the API level, which we currently do with exceptions. See more in comments to DS-2588.
[15:29] <kompewter> [ https://jira.duraspace.org/browse/DS-2588 ] - [DS-2588] Remove or merge pre-3.0 Embargo functionality with new Embargo - DuraSpace JIRA
[15:29] <pbecker> if we start to put business logic into dspace-rest we loose any clear structure we might currently have
[15:29] <tdonohue> Not sure I agree with that limitation on 'dspace-rest', but maybe I'm just saying this differently. :)
[15:29] <mhwood> We have UIs that make DSpace look like SWORD, like PMH, like HTML, and now like REST.
[15:31] <tdonohue> In my mind, ideally we'd have one primary API which all Webapps would communicate with. That way we can actually run integration tests, unit tests at that API level.
[15:32] <pbecker> tdonohue++
[15:32] <pbecker> that is dspace-api
[15:32] <pbecker> and dspace-rest is just some kind of interface to that API.
[15:33] <pbecker> That's why I would prefer to see the business logic going to dspace-api instead of adding it to dspace-rest.
[15:33] <pbecker> dspace-sword uses dspace-api, dspace-oai uses dspace-api, so should dspace-rest.
[15:34] <tdonohue> I agree with that conceptually, pbecker. I just worry that has the potential to "overload" dspace-api (i.e. it's the "everything" API). Maybe that's "good enough" for now though
[15:34] <mhwood> I suppose it depends on what use you make of REST. To build a human UI on top of it, or to use it as an information utility (like the scripts I have that supplement statistical goop from Solr with things like names that aren't in Solr.)
[15:34] <tdonohue> When I was talking about a "dspace-web-api", I was meaning an "interface" to the lower level API that would be called by ALL WEBAPPS (and that'd mean refactoring OAI, SWORD, etc. to use it). But, maybe that's a "next step" after we clean up business logic in general
[15:35] <pbecker> dspace-rest is a wrapper for dspace-api.
[15:35] <pbecker> not less but also not more. If we talk about where to add more business logic, I wouldn't add it to the wrapper, I would add it to the api every dspace module (in the sense of our current modules) is using.
[15:36] <pbecker> tdonohue: I don't see any benefits, just much more work. Why shouldn't dspace-oai use dspace-api directly? What would you like to see in dspace-rest what shouldn't be part of dspace-api?
[15:37] <mhwood> If we get our layering right, people can build integrated *and* arm's-length human UIs, as appropriate.
[15:37] <helix84> Currently dspace-rest does make more than being just a wrapper in some places, for example it hides the concept of bundles, which should be done under the Java API.
[15:37] <tdonohue> pbecker: to that point, I'd actually argue that we may not WANT every dspace module to call 'dspace-api' (as that gives them 'free reign' to just repeat business logic into their UI layer, as they currently do). But, maybe this is a discussion to table for the future ;)
[15:38] <helix84> tdonohue: the idea was, assuming that we make dspace-rest only a thin wrapper on dspace-api, then you may freely implement your UI on either without duplication of business logic
[15:39] <pbecker> helix84: exactly, thanks.
[15:39] <tdonohue> I was conceptually thinking of a "business logic layer" as something *between* dspace-api and dspace-[UI] (which helps enforce that a UI cannot just have free-reign to add a ton of custom business logic). But, you are all correct that maybe that's not needed, and we could just treat "dspace-api" both as the API & Business logic layer
[15:39] <mhwood> Well, an integrated UI can always call into dspace-api. Only discipline will help.
[15:40] <mhwood> Business logic has to have an API or it has no function.
[15:41] <helix84> tdonohue: you are also right that in the future we may want to think of modularizing dspace-api into multiple java APIs, each dealing with a particular concern, like a workflow API, content API, user management API, but I think it's practical to push that back into the future and concentrate on getting business logic under current dspace-api
[15:42] <tdonohue> helix84: I can agree with that statement. Thanks for restating that in a different way, as it's essentially what I'm pointing at.... Overloading the "dspace-api" into an API "for all things/activities" is a bit problematic as we modularize DSpace
[15:42] <tdonohue> I do concede though that *for now*, the easiest route may be to move business logic into the dspace-api
[15:43] <mhwood> I think that the resistance here is not so much "dspace-api should have everything in it", but rather "the UIs should not have so much in them."
[15:43] <helix84> regarding dspace-rest, there's a slight problem we should address ASAP - lack of versioning. Not only is not dspace-rest stable across DSpace releases, it doesn't currently even let you find out the underlying DSpace version.
[15:44] <tdonohue> +1 to versioning dspace-rest. I'm going to admit here though that I don't know what's considered the "best practice" for REST versioning these days (as I know that has some controversy on the "best" way)
[15:44] <mhwood> Versioning REST: +1. DSpace version: does REST expose a Site endpoint? That's the place for DSpace's version.
[15:44] <pbecker> helix84: do we already have a ticket for this? Will we need a versioning for the rest api itself or can we reuse DSpace version numbers?
[15:45] <helix84> pbecker: not sure if we have a ticket. The later os an open question. Reusing DSpace version number is the bare minimum we can do. Ensuring REST API stability across version is the other extreme.
[15:45] <tdonohue> re-using DSpace version numbers might be an "easy way out" here. Though it might be more complex for folks dependent on REST, as they'll need to see if their REST-based code works across DSpace versions
[15:46] <helix84> sorry, gotta run, see you
[15:46] <pbecker> bye helix
[15:46] <mhwood> I think we should not re-use the DSpace version for an API version without trying to do something else.
[15:47] <tdonohue> Would someone be willing to create a ticket on the REST versioning for 6.0?
[15:47] <mhwood> I don't see any specific problems, but it smells of trouble down the road.
[15:48] <tdonohue> mhwood: yea, it's definitely not ideal, as it's the same as what we current "have" (in a way). DSpace 4.x REST is a different version from DSpace 5.x REST, with different endpoints
[15:48] <mhwood> I can write it up.
[15:48] <tdonohue> thanks, mhwood
[15:49] <tdonohue> So, back to our agenda (which we left some time ago). I wanted to touch briefly on some (relatively significant) bugs in 5.2, which may arguably warrant a small 5.3 to fix
[15:49] <tdonohue> DS-2602, DS-2593, DS-2603 all are arguably quite problematic for 5.x sites (all for different reasons, as they are unrelated)
[15:50] <kompewter> [ https://jira.duraspace.org/browse/DS-2602 ] - [DS-2602] Clicking on a letter when browsing by title does not work - DuraSpace JIRA
[15:50] <kompewter> [ https://jira.duraspace.org/browse/DS-2593 ] - [DS-2593] Withdrawn items remain in OAI-PMH until the next full re-import - DuraSpace JIRA
[15:50] <kompewter> [ https://jira.duraspace.org/browse/DS-2603 ] - [DS-2603] The citation_pdf_url metadata is null when it shouldn't - DuraSpace JIRA
[15:50] <tdonohue> Some of these seem like *very minor*, but highly important, bugs to resolve in 5.x.
[15:51] <tdonohue> But, I'd like feedback on this. Does it seem like we should do a (hopefully quick) 5.3 to you all? I'm worried about 2602 and 2603 (which affects Google Scholar indexing) sitting around in 5.x
[15:52] <tdonohue> 2593 is also something I've heard of from folks who use OAI-PMH...it's not ideal either
[15:52] <mhwood> 2603: what should it do if there is more than one ORIGINAL bitstream and none is primary? Just pick the first one returned? Something smarter?
[15:52] <mhwood> What would be smarter?
[15:53] <tdonohue> mhwood: there's a PR for that ;) DSPR#959
[15:53] <kompewter> [ https://github.com/DSpace/DSpace/pull/959 ] - DS-2603: now if the item doesn't have a primary bitstream the value o… by nicolasschwab · Pull Request #959 · DSpace/DSpace · GitHub
[15:53] <tdonohue> the PR grabs the first bitstream (in the display order) and puts it in citation_pdf_url (which is much better than 'null')
[15:54] <mhwood> Good, it just needs review.
[15:54] <tdonohue> yep, to be clear, both 2602 and 2603 have fixes ready to go
[15:54] <mhwood> Indexing by external services is kinda important.
[15:54] <tdonohue> 2593 (OAI-PMH issues) needs more analysis & work though
[15:55] <tdonohue> mhwood: yea, and Browse-by-Title is kinda important (2602) ;)
[15:56] <mhwood> I don't think we ought to let these linger until December/January. Even if I have to do some work myself. :-)
[15:56] <pbecker> tdonohue: I see that 2603 can be seen as urgent, but shouldn't we perhaps wait some weeks and see if more thinks comes up?
[15:56] <pbecker> the last release is not so far away...
[15:56] <tdonohue> I agree, mhwood. Which is why I wanted to bring up a 5.3 release
[15:56] <pbecker> and I hope that DS-2614 gets some attention as well...
[15:56] <kompewter> [ https://jira.duraspace.org/browse/DS-2614 ] - ('Unexpected error:', <type 'exceptions.AttributeError'>)
[15:57] <tdonohue> pbecker: in a way, I'd rather not spend much time on a 5.3 (as I worry that doing so would be detrimental to work on 6.0). So, I'd like to get 5.3 out quickly, even if it means it only fixes a handful of (very important) bugs.
[15:58] <tdonohue> If there are things that are nearing "ready to go" (or have someone willing to volunteer for them now), then we can wait around a few weeks. But, I hate to wait "indefinitely" for things that don't yet have volunteers
[15:58] <mhwood> If we say today, "we're doing a 5.3", that doesn't mean it will be released today, or by the end of next week for that matter.
[15:58] <pbecker> do we have a plan for 6.0? This may be helpful to determine the write time for a 5.3 (some weeks before we really start working on 6.0).
[15:59] <pbecker> (with working I mean before we start reviewing PR and not local work to preparate PRs of course)
[15:59] <mhwood> There should be no time when we are not reviewing PRs.
[15:59] <tdonohue> 6.0 needs a Release Team. We don't yet have one, so we don't yet have a full "plan" for 6.0. The only thing that is clear to me is that, unfortunately I'm unlikely to be able to do much with 6.0 if I'm going to be driving UI-prototyping / development.
[16:00] <mhwood> Did anyone actually talk to anyone at OR about being on the 6.0 RT?
[16:00] <tdonohue> 6.0 should be started *now* though. Stuff can get voted in and reviewed now, even without a Release Team. But, we do need to finalize the schedule for 6.0 soon
[16:01] <tdonohue> mhwood: I had some small side discussions to that effect, but most folks seem interested in the larger Roadmap (which I understand is exciting). My goal is to try to find folks who want things in 6.0 and get them to step up on the Release Team to make that happen
[16:02] <tdonohue> So, let this be the message: "If you want a particular feature/change in 6.0, we highly recommend you help on the Release Team."
[16:03] <tdonohue> And, I'll send a message to that effect to the Committers list (hopefully later today)
[16:05] <tdonohue> In the meantime, I think we are already accepting code into "master" for 6.0 (obviously needs committer approval though & should 'align' with the larger Roadmap).
[16:06] <tdonohue> In addition, I'd highly encourage folks to volunteer to help fix bugs in 5.x for a quick 5.3 release (in the near future -- likely sometime in July, but exact date is TBD). Some tickets of high interest include DS-2593 and DS-2614 (along with 2602 and 2603, which have fixes)
[16:06] <kompewter> [ https://jira.duraspace.org/browse/DS-2593 ] - [DS-2593] Withdrawn items remain in OAI-PMH until the next full re-import - DuraSpace JIRA
[16:06] <kompewter> [ https://jira.duraspace.org/browse/DS-2614 ] - ('Unexpected error:', <type 'exceptions.AttributeError'>)
[16:08] <tdonohue> As we are now "overtime", I think we'll close up the meeting for today. Thanks for the discussion! Please do get in touch about being on the 6.0 Release Team, if you have an interest. If anyone can stick around, we'll be doing some JIRA backlog reviews over in #dspace shortly
[16:09] * pbecker (~pbecker@ubwstmapc098.ub.tu-berlin.de) has left #duraspace
[16:10] * pbecker (~pbecker@ubwstmapc098.ub.tu-berlin.de) has joined #duraspace
[16:11] * jm__ (57c568d1@gateway/web/freenode/ip.87.197.104.209) has joined #duraspace
[16:33] * kohts (~kohts@195.68.180.4) Quit ()
[16:43] * pnbecker (~pbecker@ubwstmapc098.ub.tu-berlin.de) has joined #duraspace
[16:45] * pbecker (~pbecker@ubwstmapc098.ub.tu-berlin.de) Quit (*.net *.split)
[17:19] * pnbecker (~pbecker@ubwstmapc098.ub.tu-berlin.de) Quit (Quit: Leaving)
[18:50] * dyelar (~dyelar@31.158.45.66.cm.sunflower.com) has joined #duraspace
[19:48] * jm__ (57c568d1@gateway/web/freenode/ip.87.197.104.209) Quit (Quit: Page closed)
[21:03] * mhwood (mwood@mhw.ulib.iupui.edu) Quit (Remote host closed the connection)
[21:30] * tdonohue (~tdonohue@c-73-45-154-218.hsd1.il.comcast.net) has left #duraspace
[23:25] * dyelar (~dyelar@31.158.45.66.cm.sunflower.com) Quit (Quit: Leaving.)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.