Timestamps are in GMT/BST.
[6:52] -sendak.freenode.net- *** Looking up your hostname...
[6:52] -sendak.freenode.net- *** Checking Ident
[6:52] -sendak.freenode.net- *** Found your hostname
[6:52] -sendak.freenode.net- *** No Ident response
[6:52] * DuraLogBot (~PircBot@ec2-107-22-210-74.compute-1.amazonaws.com) has joined #duraspace
[6:52] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:52] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[7:03] * cknowles (uid98028@gateway/web/irccloud.com/x-gplpduhvbwnchcyo) has joined #duraspace
[10:06] * Disconnected.
[10:06] -sendak.freenode.net- *** Looking up your hostname...
[10:06] -sendak.freenode.net- *** Checking Ident
[10:06] -sendak.freenode.net- *** Found your hostname
[10:06] -sendak.freenode.net- *** No Ident response
[16:29] -wolfe.freenode.net- *** Looking up your hostname...
[16:29] -wolfe.freenode.net- *** Checking Ident
[16:29] -wolfe.freenode.net- *** Found your hostname
[16:29] -wolfe.freenode.net- *** No Ident response
[16:29] * DuraLogBot (~PircBot@webster.duraspace.org) has joined #duraspace
[16:29] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[16:29] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[16:40] <tdonohue> testing duralogbot is working right (it crashed on us again)
[17:38] * pbecker (~pbecker@ubwstmapc098.ub.tu-berlin.de) Quit (Quit: Leaving)
[19:29] * hpottinger (~hpottinge@mu-160190.dhcp.missouri.edu) Quit (Quit: Leaving, later taterz!)
[19:35] * Guest81316 (84cb82b6@gateway/web/freenode/ip.132.203.130.182) Quit (Ping timeout: 246 seconds)
[19:54] * KevinVdV (~KevinVdV@d54C5104D.access.telenet.be) has joined #duraspace
[20:00] <tdonohue> Hi all, welcome, it's time for our weekly DSpace DevMtg. Agenda: https://wiki.duraspace.org/display/DSPACE/DevMtg+2015-08-19
[20:01] <kompewter> [ DevMtg 2015-08-19 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2015-08-19
[20:01] <tdonohue> The obvious "hot topic" for this week is the Services API refactor kicking off: https://wiki.duraspace.org/display/DSPACE/DSpace+Service+based+api
[20:01] <kompewter> [ DSpace Service based api - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DSpace+Service+based+api
[20:02] <tdonohue> The initial PR was supplied by KevinVdV and it's already been merged into our feature branch (along with some quick bug fixes by mhwood): https://github.com/DSpace/DSpace/tree/DS-2701-service-api
[20:02] <kompewter> [ DSpace/DSpace at DS-2701-service-api · GitHub ] - https://github.com/DSpace/DSpace/tree/DS-2701-service-api
[20:02] <kompewter> [ https://jira.duraspace.org/browse/DS-2701 ] - [DS-2701] Adopt Service-based API refactor of existing Java API - DuraSpace JIRA
[20:03] <mhwood> I've taken dspace-oai as far as clearing up the simple stuff (to the point that it compiles). Not visible on GitHub yet.
[20:03] <tdonohue> KevinVdV has also created some subtickets of DS-2701 for some "known issues" that already exist in this feature branch
[20:03] <kompewter> [ https://jira.duraspace.org/browse/DS-2701 ] - [DS-2701] Adopt Service-based API refactor of existing Java API - DuraSpace JIRA
[20:03] <KevinVdV> For which he has my thanks, didn’t know I missed some heades
[20:03] <mhwood> Excuse me: *would* compile but for the not-so-simple stuff.
[20:04] <tdonohue> So, it seems like we are at a state where everyone can begin to help in the refactor (and I know mhwood has already gotten started on that). I wonder if there's any immediate questions anyone would like to pose for feedback from KevinVdV and others?
[20:04] <mhwood> Should we have an issue for each of the app.s?
[20:04] <mhwood> Or how are we going to organize the work w.r.t. the tools?
[20:06] <tdonohue> which "tools" do you mean? We could create sub-tickets for each app, but I wasn't sure if they were needed, since we already have each app "assigned" to someone. If those subtickets were useful for other means (e.g. discussions of issues/status), then maybe it would make sense to have them
[20:06] <tdonohue> So, if I were to turn it around, do you see an immediate *need* for creating one subticket per webapp?
[20:07] <mhwood> Well, today I worked on a small fix to dspace-api and started on a more involved one to dspace-oai. I'm trying to figure out how to juggle all that. Typically I name my own branches after the Jira ticket ID. But I can come up with some other approach.
[20:09] <KevinVdV> Does the OAI need API changes ?
[20:09] <KevinVdV> Just curious
[20:10] <mhwood> Hard to say at the moment. But I needed the license headers fixed so that I could get past dspace-api and have Maven even attempt dspace-oai.
[20:10] <mhwood> If we hadn't had really rapid turnaround on that PR, I would have needed two branches, to keep things separate.
[20:12] <tdonohue> Regarding the subtickets per webapp, I wasn't sure if they'd be as useful as creating subtickets for more specific issues (i.e. bugs/blockers). If folks want a subticket to work from though, feel free to just create one. I don't mind it, I just wasn't rushing to create 10 more subtickets :)
[20:12] <tdonohue> Are there any specific issues you have run into with OAI though mhwood, that we all need to be aware of, or that you need feedback on?
[20:13] <mhwood> I do have some questions about how to handle complex DB queries from the UIs. Is ItemService really going to wind up with 30,000 methods, one for each possible query?
[20:14] <KevinVdV> Yeah I did notice that the OAI has some query contatination in there.
[20:14] <KevinVdV> But is this not for an optional DB based OAI ?
[20:14] <tdonohue> OAI should be refactored to just use Solr as part of this (or at least I thought that was the plan here)?
[20:15] <mhwood> SELECT item_id FROM item WHERE (in_archive=TRUE OR withdrawn=TRUE) AND discoverable=TRUE AND last_modified > ?
[20:15] <mhwood> That stuff is all in Solr somewhere?
[20:15] <KevinVdV> I think that this is just an “optional” DB backend which can replace solr
[20:15] <tdonohue> no, that one might be used to *populate* Solr, actually. You still will need *some DB stuff* in OAI
[20:16] <mhwood> That SELECT is from XOAI.java.
[20:16] <tdonohue> there are DB scripts in OAI that populate Solr indexes...so, it depends on what you are looking at
[20:16] <KevinVdV> Yeah, but you could make the in_archive, withdran, discoverable, …. parameters in a service method
[20:16] <KevinVdV> & you COULD set them to NULL
[20:17] <KevinVdV> That way the method can reused
[20:17] <mhwood> So it has a dozen parameters, and NULL means don't-care.
[20:17] <tdonohue> The XOAI class is the one used to populate Solr indexes..so, yes, that DB method would still be needed: https://github.com/DSpace/DSpace/blob/master/dspace-oai/src/main/java/org/dspace/xoai/app/XOAI.java#L193
[20:17] <kompewter> [ DSpace/XOAI.java at master · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/blob/master/dspace-oai/src/main/java/org/dspace/xoai/app/XOAI.java#L193
[20:18] <mhwood> Anyway, I'm just trying to make it compile right now, and since DatabaseManager and TableRowIterator are no more, I have to figure out how to replace what's being done with them.
[20:19] <KevinVdV> If the tableRowIterator contains items, you need an Iterator<Item>
[20:19] <KevinVdV> https://github.com/DSpace/DSpace/blob/DS-2701-service-api/dspace-api/src/main/java/org/dspace/content/dao/impl/ItemDAOImpl.java#L40
[20:19] <kompewter> [ DSpace/ItemDAOImpl.java at DS-2701-service-api · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/blob/DS-2701-service-api/dspace-api/src/main/java/org/dspace/content/dao/impl/ItemDAOImpl.java#L40
[20:19] <mhwood> I also need something that produces an Iterator<Item> which generates the results I need.
[20:19] <kompewter> [ https://jira.duraspace.org/browse/DS-2701 ] - [DS-2701] Adopt Service-based API refactor of existing Java API - DuraSpace JIRA
[20:20] <KevinVdV> So the call from above could be altered to also take additional arguments
[20:20] <KevinVdV> & then you just need a service method above it & it should work :)
[20:20] <KevinVdV> Just pass it down to a DAO, create an HQL query (or use the criteria) & return result
[20:21] <mhwood> So the way we do things now is to create a method in e.g. ItemService, which wraps something in ItemDAO.
[20:22] <KevinVdV> Well IF a database query is needed to retrieve something yes you pass it on to the DAO
[20:23] <mhwood> But I can't talk to the DAO directly, from UI code.
[20:23] * shepherdk (~kim@ec2-184-73-177-234.compute-1.amazonaws.com) has joined #duraspace
[20:23] <KevinVdV> THat is why you need to pass through the services
[20:23] <KevinVdV> Becauses sometimes there is a need for additional “business” logic
[20:24] <tdonohue> At the ItemService level, it seems like it might be a good idea to find a better "name" for what that OAI result set is. So, e.g. there's "findAll()" "findBySubmitter()" already.... this OAI query looks like a "findDiscoverable()" plus a "findWithdrawn()"
[20:24] <mhwood> And the service shouldn't offer something such as findMany().
[20:25] <tdonohue> The OAI query is almost a "findDiscoverableOrWithdrawn()" method. Though, not sure if it's even possible to just tease that apart into two methods
[20:25] <KevinVdV> More like findArchivedOrWithdrawnAndDiscoverable with an optional date modified
[20:26] <KevinVdV> But you COULD create a service method which delegates to the DAO for that
[20:26] <tdonohue> I don't think we should have a generic "findMany(in_archive,withdrawn,discoverable,date)" method...as I worry about UIs making different "decisions" on what "in_archive" vs "withdrawn" vs "discoverable" flags "mean"
[20:26] <shepherdk> hi all, what are we talking about?
[20:26] <mhwood> Actually findMany takes a JPQL argument. Even worse than you thought. :-)
[20:27] <tdonohue> shepherdk: we're a bit on a tangent regarding how to refactor OAI to support Services API... since mhwood is the first to "jump in" and is starting with OAI
[20:28] <shepherdk> ah
[20:28] <tdonohue> mhwood: my point though is that ItemService probably shouldn't give a public method that lets UIs decide the meaning of "in_archive", "withdrawn" and "discoverable" (by passing in whatever values they think is "best" for the UI). Instead, we should wrap those descisions into the ItemService method itself. Does that make sense? (or am I missing something myself)
[20:28] <mhwood> Well, actually I think it's not a tangent; I think many of us are going to run into complex queries up near the user and we will need to know the rules for doing them in the new model.
[20:30] <mhwood> Yes I think that makes sense. I also think the services are going to bristle with identical-sounding methods that will take some time to sort through every time one wants to do something. That's what happens when you replace a language with methods embodying specific sentences of the language.
[20:30] <mhwood> Notice I didn't say that's bad. Probably it just takes some getting used to.
[20:31] <tdonohue> Right, I agree, there may be some of that...but we'll just have to see how many methods we truly *do need* across all these UIs...I'm hoping that it'll be a smaller set than we may think right now
[20:31] <tdonohue> So, it sounds like we have a general direction for OAI? Is there more feedback needed here, mhwood?
[20:32] <KevinVdV> The databaseManager calls are limited from the UI
[20:32] <KevinVdV> I only think the rest api & oai query the item
[20:32] <mhwood> No, that's enough for me to get into trouble and ask more specific questions.
[20:33] <tdonohue> mhwood: feel free to ask more questions as you go. I think it helps us all learn this & come up with common "best practices" to strive for
[20:33] <KevinVdV> Agreed
[20:34] <KevinVdV> FYI: For now I created the methods I need on the services, but the easy thing about having it in a service is that IF we get our single UI up & running we should be easily able to see which methods aren’t used anymore
[20:34] <tdonohue> So, are there other questions/thoughts to share on the Services API stuff? Or do we all just start digging in & asking questions?
[20:34] <mhwood> OK, I will just keep inventing new methods to encapsulate these queries. Perhaps patterns will emerge.
[20:34] <shepherdk> mhwood: is there a github branch some of us can follow your work on to help people jumping into other modules later?
[20:34] <mhwood> Not yet shepherdk but I should do that next.
[20:35] <mhwood> Making a mess and asking questions is my usual approach. :-)
[20:35] <tdonohue> shepherdk: we are all obviously going to be merging to the shared feature branch, so once mhwood is "done" his work will show up there. But, in the meantime, yea, there's not as much visibility yet.
[20:35] <shepherdk> mhwood++
[20:35] <tdonohue> here's that shared feature branch again: https://github.com/DSpace/DSpace/tree/DS-2701-service-api
[20:35] <kompewter> [ DSpace/DSpace at DS-2701-service-api · GitHub ] - https://github.com/DSpace/DSpace/tree/DS-2701-service-api
[20:35] <kompewter> [ https://jira.duraspace.org/browse/DS-2701 ] - [DS-2701] Adopt Service-based API refactor of existing Java API - DuraSpace JIRA
[20:36] <mhwood> I will make my current mess visible tonight or tomorrow.
[20:36] <shepherdk> tdonohue: right.. i just meant a branch in his own github for WIP stuff..
[20:36] <KevinVdV> @ sheperdk: & some more docs are also available: https://wiki.duraspace.org/display/DSPACE/DSpace+service+based+api%3A+Porting+DSpace+modules, https://wiki.duraspace.org/display/DSPACE/DSpace+Service+based+api%3A+API+Changelist
[20:36] <kompewter> [ DSpace Service based api: API Changelist - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DSpace+Service+based+api%3A+API+Changelist
[20:37] <shepherdk> my lucene deprecation WIP is sitting in a kshepherd looking sad and lonely, waiting to be rewritten after all the big merging to master
[20:37] <KevinVdV> You could try & achieve it against the service api
[20:38] <tdonohue> In general, I think it might be a good idea for folks who are *actively working* on Services API stuff to jump into #dspace while they are doing so. That way we can collaborate more directly and get more immediate answers. (Obviously though this is all timezone permitting, etc)
[20:39] <shepherdk> well.. it's spread over all the modules, so yeah that's possible, will just take time and coordination
[20:40] <tdonohue> Is there anything more we wish to discuss about Services API refactoring? (I'll admit, I haven't had a chance to get started myself yet, but plan to do so later this week)
[20:41] <KevinVdV> One more remark: If you are really stuck on something please send it to an email
[20:41] <KevinVdV> Because I’m not in the US timezone sadly
[20:41] <mhwood> Will do.
[20:42] <tdonohue> KevinVdV: sounds good. I'd just recommend copying in -devel on any emails, so we can all learn :)
[20:42] <KevinVdV> Ofc !
[20:42] <KevinVdV> I’ll keep an eye out for emails so I can help where I can
[20:43] <tdonohue> Sounds great. Thanks again KevinVdV. Oh, and by the way, don't forget to "check off" any modules you feel are "done" on our to-do list: https://wiki.duraspace.org/display/DSPACE/DSpace+Service+based+api
[20:43] <kompewter> [ DSpace Service based api - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DSpace+Service+based+api
[20:44] <tdonohue> Moving along for now... next topic is mostly just an FYI on mailing list migrations to Google Groups
[20:45] * dyelar (~dyelar@31.158.45.66.cm.sunflower.com) has joined #duraspace
[20:45] <tdonohue> Behind the scenes, as many will have noticed, i'm migrating mailing lists this week. 3 of 6 are complete. dspace-devel is in progress now (and should be done by Fri). dspace-tech & dspace-general will be moved next week
[20:46] <tdonohue> It's a bit of a slow and slightly painful process, but it'll be better once it's all done
[20:46] <shepherdk> i have to get over to the office now, cheers all (happy to help with the mailing list migrations where i can tdonohue, just email/irc me later if you want)
[20:47] <tdonohue> If anyone wants to chip in, I might be looking for volunteers next week to help me move over "subscribers" for -tech and -general (as both are massive lists). It's not a fun task, but it'd save people having to sign up again
[20:47] <shepherdk> kshepherd: you stay here
[20:47] * shepherdk (~kim@ec2-184-73-177-234.compute-1.amazonaws.com) Quit (Quit: bye)
[20:48] <tdonohue> Unfortunately, one account can only (seemingly) move over 100 subscribers a day. Hence, I would need *many* (14) accounts to move over all 1,400+ subscribers in a day. :)
[20:49] <mhwood> I could probably take a hundred. I don't have any idea how it's done, though.
[20:49] <tdonohue> I actually have a good 4-5 accounts I can use myself (and can create more dummy ones if I need to). But if others want to help out, I can hand you 100 emails to paste in when the time is right
[20:50] <terry-b> I can take 100 as well
[20:50] <tdonohue> mhwood: I can send you the instructions. It's not hard, just a bit time-consuming... adding all 100 will probably take ~10-15mins
[20:50] <mhwood> OK.
[20:50] <KevinVdV> <= needs to run ….all work & no sleep makes Kevin a dull boy
[20:50] * KevinVdV (~KevinVdV@d54C5104D.access.telenet.be) Quit (Quit: KevinVdV)
[20:51] <tdonohue> Ok. Thanks though mhwood & terry-b. I'll loop you in when I need you. Unfortunately though, I *have* to migrate the full archives of each list *first*. So, the timeline will be next week sometime (likely mid-to-late next week, but I'll let you know)
[20:51] <tdonohue> And I'll likely ping others on #dspace that day as well :)
[20:52] <tdonohue> The last announcement for today is just a reminder of the next DSpace UI Working Group meeting. It's next Tues, at 15UTC. Reminder will also be sent across mailing lists later this week.
[20:52] <tdonohue> Beyond that, I didn't have any further topics to bring up. Anyone have something to discuss or questions?
[20:54] <mhwood> I now have a DS-2701-oai-main branch that should contain the current state of my work.
[20:54] <kompewter> [ https://jira.duraspace.org/browse/DS-2701 ] - [DS-2701] Adopt Service-based API refactor of existing Java API - DuraSpace JIRA
[20:55] <tdonohue> Thanks mhwood! Want to paste the full link in here (for anyone not aware of your GitHub id)
[20:55] <mhwood> https://github.com/mwoodiupui/DSpace/tree/DS-2701-oai-main
[20:55] <kompewter> [ mwoodiupui/DSpace at DS-2701-oai-main · GitHub ] - https://github.com/mwoodiupui/DSpace/tree/DS-2701-oai-main
[20:56] <kompewter> [ https://jira.duraspace.org/browse/DS-2701 ] - [DS-2701] Adopt Service-based API refactor of existing Java API - DuraSpace JIRA
[20:57] <tdonohue> As I'm not hearing any other discussion topics, we'll close the meeting early today. Those of you who have volunteered for the Service API refactor, please do let us know if you hit any issues & ask questions! Hopefully we'll have many modules fixed by next week's meeting!
[21:12] * mhwood (mwood@mhw.ulib.iupui.edu) Quit (Remote host closed the connection)
[21:41] * tdonohue (~tdonohue@c-50-178-45-117.hsd1.il.comcast.net) has left #duraspace
[23:03] * cknowles (uid98028@gateway/web/irccloud.com/x-gplpduhvbwnchcyo) Quit (Quit: Connection closed for inactivity)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.