Timestamps are in GMT/BST.
[6:55] -adams.freenode.net- *** Looking up your hostname...
[6:55] -adams.freenode.net- *** Checking Ident
[6:55] -adams.freenode.net- *** Found your hostname
[6:55] -adams.freenode.net- *** No Ident response
[6:55] * DuraLogBot (~PircBot@webster.duraspace.org) has joined #duraspace
[6:55] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:55] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[8:05] * philip (~philip@85.234.195.109.static.edpnet.net) has joined #duraspace
[8:29] * philip (~philip@85.234.195.109.static.edpnet.net) has left #duraspace
[9:00] * cknowles (uid98028@gateway/web/irccloud.com/x-npqdpnbdnzdpqwvw) has joined #duraspace
[9:27] * Disconnected.
[9:27] -verne.freenode.net- *** Looking up your hostname...
[9:27] -verne.freenode.net- *** Checking Ident
[9:27] -verne.freenode.net- *** Found your hostname
[9:27] -verne.freenode.net- *** No Ident response
[14:53] -weber.freenode.net- *** Looking up your hostname...
[14:53] -weber.freenode.net- *** Checking Ident
[14:53] -weber.freenode.net- *** Found your hostname
[14:53] -weber.freenode.net- *** No Ident response
[14:53] * DuraLogBot (~PircBot@webster.duraspace.org) has joined #duraspace
[14:53] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[14:53] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[14:56] * roeland (~roeland@85.234.195.109.static.edpnet.net) has joined #duraspace
[14:56] * roeland (~roeland@85.234.195.109.static.edpnet.net) Quit (Client Quit)
[14:57] * roeland (~roeland@85.234.195.109.static.edpnet.net) has joined #duraspace
[14:58] <peterdietz> hi all
[14:59] <mhwood> Howdy.
[15:00] <tdonohue> Hi all, it's time for our weekly DSpace DevMtg. Agenda is at: https://wiki.duraspace.org/display/DSPACE/DevMtg+2015-08-26
[15:00] <kompewter> [ DevMtg 2015-08-26 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2015-08-26
[15:01] <tdonohue> Before the meeting I heard from KevinVdV that he may be a few minutes late. Since he's not yet here, let's skip the Services API updates for now, and we'll loop back to them shortly
[15:02] <tdonohue> So, I'll kick things off with just some minor updates on the SourceForge migration. We are almost entirely off SourceForge at this time. The last thing that needs to move is the (massive) dspace-tech mailing list
[15:03] <tdonohue> And, as of this morning, I feel confident that dspace-tech will be fully migrated by tomorrow afternoon (well, afternoon for me). Likely around 19 UTC. I'll be sending an announcement to dspace-tech later today to notify everyone
[15:03] * tmtvl (d577a5df@gateway/web/freenode/ip.213.119.165.223) has joined #duraspace
[15:04] <tdonohue> So, as of late tomorrow we should be entirely off of SourceForge. All future releases will be posted to GitHub, and all mailing lists will be hosted at Google Groups.
[15:04] <tdonohue> Any questions or comments on any of that?
[15:05] <mhwood> I joined dspace-community using the GG web interface and wasn't getting any postings until I realized that the Join button left me in "no mail" state.
[15:05] * tdonohue did notice we got our first "spam" on the new dspace-community list today. I've banned that spammer.
[15:06] <tdonohue> mhwood: huh. Did you accidentally select the "no mail" option? Or did you never get that option?
[15:06] <peterdietz> It would be cool if someone wanted to volunteer to 100-per-day move old users to the new list. (I'm not volunteering). Just in case people ignore, ignore, ignore the "THE LIST IS MOVING" message
[15:06] <mhwood> I may have missed it. I never use the GG UI if I can help it, so I don't have the proper reflexes yet.
[15:06] <tdonohue> Looking at the dspace-community subscribers. There are some who are subscribed as "no mail". I had assumed that was their choice though, as others have "all mail" or various "digest" settings
[15:07] <tdonohue> Anyone else sign up for "dspace-community" and NOT yet see emails across that list? (there's only been 1-2 since migration, but you should have seen them)
[15:07] <peterdietz> Its not check marked by default. (assuming you'll use gg ui to interact). It does have a scary assumption email: 149 messages/day, since it all just imported
[15:08] <hpottinger> tdonohue: can you just paste the subscribe link here, on the off chance someone other than me has misplaced it? :-) Thanks!
[15:08] <pbecker> the best way is to subscribe by mail.
[15:08] <pbecker> That was easy and did what I expected.
[15:09] <tdonohue> For dspace-community you can subscribe via email by mailing dspace-community+subscribe@googlegroups.com Or just visit https://groups.google.com/forum/#!forum/dspace-community
[15:09] <kompewter> [ Google Groups ] - https://groups.google.com/forum/#!forum/dspace-community
[15:09] <tdonohue> I'm wondering if I should switch all these "no mail" folks to "all mail" on their behalf. Now that I look, there are quite a few.
[15:10] <mhwood> People who *like* GG may prefer to have the mail off.
[15:11] <mhwood> Those of us who ask, "how can I make this more like LISTSERV?" will want it set the other way.
[15:11] <tdonohue> possibly. It's just hard to tell here if it's accidental or not. :) I guess I'll leave it as-is, unless I get further complaints
[15:12] <pbecker> sending a mail to the list explaining the problem probably won't help if they don't receive the mail...
[15:12] <tdonohue> To what peterdietz says, I did do a full "dump" of all our mailing list subscribers from SourceForge, should anyone want to go back and subscribe them 100 per day. I just personally don't know that it's worth the effort.
[15:13] <tdonohue> pbecker: yea, that's the problem. I'll ask a few other folks (who I know) who are currently set to "no mail" and see if they did it on purpose. If they didn't, I'll reset everyone to "all mail" temporarily
[15:14] <hpottinger> heads up to committers: it looks like we're all admins of these groups, so, change settings with care :-)
[15:15] <tdonohue> Yes, I've made all Committers "Managers" of these lists. :) So, you can manage most of the settings yourselves. If you don't yet have "Manager" access, then you probably recently subscribed and I haven't added you yet :)
[15:15] <peterdietz> tdonohue: Send me the community list of subscribers, if there's any group that should atleast still get the flurry of messages its them. (i.e. DSpace 5 has major security flaw). I'll process that over the next 2 weeks
[15:16] <tdonohue> I think that's it for the mailing list topic. As mentioned, dspace-tech should be migrated tomorrow (announcement forthcoming)
[15:16] <tdonohue> peterdietz: OK, will do.
[15:17] <tdonohue> KevinVdV still hasn't joined us, but I think it's time to move on to the Services API topic nonetheless.... simply because it's high priority & we need to stay on top of it
[15:18] <tdonohue> So, regarding Services API refactoring... Does anyone have updates you wish to share, or difficulties you are encountering? Any rough timelines on when you see your work completing?
[15:19] <mhwood> I'm ready to see how many tests I broke in dspace-oai, but have run into a problem with the dspace-api test setup: it is looking for "#{dspace.dir}/config/hibernate.cfg.xml" (literally) and of course doesn't find it.
[15:20] <hpottinger> I think peterdietz had a question as to the "tao of -services refactoring"
[15:20] <mhwood> Hm, I guess I can suppress the testing when installing -api, but I wonder how I got into this state.
[15:21] <peterdietz> I got REST first pass completed. It boots, runs, has data. I'll need to run through some ad-hoc tests. Does /collections have same data as before, and all other endpoints. It would be great if I had a testing suite. I'm not sure how to do integration tests in DSpace.
[15:22] <mhwood> He and I both. We haven't worked out how to predict accurately where a method will be between FooService and FooDAO.
[15:22] <mhwood> Oh, and Foo.
[15:22] <hpottinger> When we decide the answer, do we need a "cheat sheet"?
[15:22] <peterdietz> Every once in a while, you'll find it actually live in BarService though
[15:23] <tdonohue> hmm... that is an interesting question regarding dspace-api test setup, mhwood. Not sure I know the answer either.
[15:23] <mhwood> I will report when I know more.
[15:23] <tdonohue> +1 for a cheat sheet. I was hoping these existing wiki pages could start to morph into a "cheat sheet" for hints/tips on using the new API. There's already a lot of great examples there, and I'd encourage adding more as you find them
[15:24] <peterdietz> https://wiki.duraspace.org/display/DSPACE/DSpace+service+based+api%3A+Porting+DSpace+modules
[15:24] <kompewter> [ DSpace service based api: Porting DSpace modules - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DSpace+service+based+api%3A+Porting+DSpace+modules
[15:25] <peterdietz> This one turned out to be my "bible" https://wiki.duraspace.org/display/DSPACE/DSpace+Service+based+api%3A+API+Changelist
[15:25] <kompewter> [ DSpace Service based api: API Changelist - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DSpace+Service+based+api%3A+API+Changelist
[15:25] <mhwood> Regarding integration testing: my gut says something involving Selenium would work well with REST but I don't have a specific recommendation.
[15:25] * KevinVdV (~KevinVdV@d54C5104D.access.telenet.be) has joined #duraspace
[15:25] <KevinVdV> Hi all
[15:25] <tdonohue> yep, each of those pages has some goood hints/examples already. It would be nice to "merge" them eventually into a "cheat sheet" (perhaps after the full refactor is done)
[15:26] <tmtvl> Dag Kevin.
[15:26] <tdonohue> hi KevinVdV. We just started talking Services API (about 5+ mins ago)
[15:26] <peterdietz> yeah, something like Travis . CI, but for building / maintaining / running a bunch of integration tests.. create some data, get some data, delete some data...
[15:26] <KevinVdV> Yeah currently reading up on things
[15:28] <mhwood> Google "java selenium" turns up some promising leads that I haven't followed.
[15:29] <mhwood> When I get a little time, I need to get back to work on setting up a separate integration testing phase.
[15:29] <tdonohue> KevinVdV, do you have any hints for why mhwood might be getting an error with dspace-api test setup: "it is looking for "#{dspace.dir}/config/hibernate.cfg.xml" (literally) and of course doesn't find it."
[15:30] <KevinVdV> Hmmm this is a first one ….
[15:30] <mhwood> Woops, that should be "$" not "#".
[15:31] <tdonohue> mhwood: is this issue occuring on your branch? Maybe it's something one of us could help debug by checking out your branch
[15:31] <roeland> seems like it is coming from dspace/config/spring/api/core-hibernate.xml
[15:31] <KevinVdV> Yeah it should come from that file that should be filtered on ant update
[15:31] <mhwood> Ah, well then I understand: I'm not installing this thing, just running 'mvn clean install'.
[15:32] <mhwood> Ant isn't involved.
[15:32] <mhwood> I'll need to look at how to remove the need to filter that.
[15:32] <KevinVdV> Ah ofc, but you will need to run ant update anyway to start indexing
[15:32] <hpottinger> oh, hey, mhwood, integration testing is near and dear to me, as well, and I might get some backing here to chase after it
[15:33] <mhwood> I haven't looked at the test classes yet, but real unit tests shouldn't be depending on having anything in the indexes.
[15:34] <mhwood> Okay, I know how to work on this now.
[15:34] <mhwood> Thanks!
[15:35] <tdonohue> +1 for someone (anyone) chasing integration testing :) It's been on my wishlist too, but I haven't had any time to devote towards it
[15:35] <mhwood> I have gone as far as getting Failsafe to run, but I get sidetracked by other issues.
[15:36] <mhwood> Anyway, general testing work is probably offtopic just now? Other Services talk?
[15:37] <tdonohue> Yes, any other question/comments regarding Service API refactor? I'm also interested in hearing everyone's estimated timelines...when do you feel you should be "done" (i.e. ready for review)?
[15:38] <pbecker> I hope to be done at the end of this week with RDF. But that is really just a small module.
[15:38] <mhwood> I'd like to finish up (to review status) this week, but that depends on how badly I broke stuff, which is why I want the tests to run. :-)
[15:38] <peterdietz> Services has been pretty great. One ideological question I have for KevinVdV is, should I have REST be defensive and have lots of logic that checks that the user doesn't try to do something they shouldn't, or rely on services to throw an exception when something shouldn't happen.
[15:39] <peterdietz> if(authorizationManager.isAllowToDoSomething(context, dso, action) { itemService.like(context, item) }
[15:39] <KevinVdV> Well that depends on the actions at the moment…. the service at THIS time doesn’t change the way it used to work. So at the moment you CAN request metadata from an item you don’t have rights to (like before). Although in theory it should be seomthing that the service SHOULD do.
[15:40] <peterdietz> or ... try { itemService.like(context, item); } catch (LikeException e) {...}
[15:40] <mhwood> If there's no good way for Services to diagnose a common problem, then heading it off in the UI makes sense. If you get good clear exceptions back from Services then I would just let Services do the work (so that the diagnosis is close to the failure, where much of the information is).
[15:42] <KevinVdV> So at the moment you should use: if(authorizationManager.isAllowToDoSomething(context, dso, action) { itemService.like(context, item) }
[15:42] <KevinVdV> Because that is how DSpace used to work & still does now. IF the “like” method doesn’t handle the checks
[15:42] <mhwood> Sometimes several layers need to decorate a packet of exceptions as it passes back up the call stack, each adding what it knows or can deduce. You sometimes get *very* good information that way.
[15:44] <KevinVdV> I would like to add that NEW service methods should check the authorizations themselves instead of relying on the UI to do it.
[15:44] <peterdietz> OK. I think currently, the most specific an error I might get from services is a SQLException, where as DSONotFoundException, or AuthorizeException might be what I actually want. So maybe a second phase on services refactor before that exists
[15:44] <mhwood> Maybe drop a // TODO on such places when you find them, so we can move that logic into the service later.
[15:44] <roeland> so kevin is saying the following, the authorization should be handeled by the service layer but isn’t
[15:45] <roeland> what mhwood said
[15:45] <peterdietz> ...but its too hard to change signatures of existing methods. New service methods will/should check. Existing methods, is undetermined, but probably did what it traditionally did, which might not be sufficient.
[15:45] <mhwood> Clearly, if the service doesn't know there is a problem then there won't be an Exception to tell you about it.
[15:46] <tdonohue> So, another quick question/comment. Regarding all these PRs that KevinVdV has created to patch small bugs in Services API... Are we waiting on thorough testing for each? Or should we just get them merged after a sanity check? I was leaning towards the latter since so much is in flux, and some of these bug fixes seem needed ASAP.
[15:47] <tdonohue> for reference see recent PRs from KevinVdV: https://github.com/DSpace/DSpace/pulls
[15:47] <kompewter> [ Pull Requests · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pulls
[15:47] <pbecker> tdononhue +1 (getting merge asap)
[15:48] <peterdietz> Kevin's PR's should probably get merged asap. I haven't seen these 4 until just now
[15:48] <tdonohue> I'll gladly give them all a "sanity check" today and go merge-crazy (if everyone is OK with that). I just may not have time to do a thorough test of each immediately
[15:48] <KevinVdV> Yeah these things came up when trying to test the regular workflow
[15:49] <mhwood> The three bug fixes should just go in if after a quick check.
[15:49] <KevinVdV> So I could migrate it to the xmlui
[15:50] <tdonohue> The only one likely needing a tad more verification may be DSPR#1029. Anyone have time to give that a quick test that it won't *break* Postgres and seems OK on Oracle?
[15:50] <kompewter> [ https://github.com/DSpace/DSpace/pull/1029 ] - [DS-2714] Oracle migration script for the service based api by KevinVdV
[15:50] <tdonohue> I'll do a "sanity check" of the 3 bug fixes and just merge them
[15:51] <mhwood> Sadly my Oracle test setup is broken at the moment.
[15:51] <roeland> I think the point is to retest postgres
[15:52] <tdonohue> yep. The more important point is to retest Postgres first (ensure no breakage). We can do a thorough Oracle test later if needed (though it'd be nice if someone did have an Oracle Test environment ready)
[15:53] <KevinVdV> For testing with oracle you can use: https://wiki.duraspace.org/display/DSPACE/DSpace+with+Oracle+DB+test+instance
[15:53] <kompewter> [ DSpace with Oracle DB test instance - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DSpace+with+Oracle+DB+test+instance
[15:53] <KevinVdV> (It is what I did)
[15:53] <hpottinger> I'd have to assume my Oracle test setup is broken as well... it's been a while, though it's possible it'll start right up. However, I can't commit to a test just yet, we just upgraded to 5, so there's lots of work piling up for me to do at the moment
[15:55] <peterdietz> Just to get an assessment. what is the overall status of services and everything? Is each webapp claimed? Is each webapp more-or-less almost done. Services is working for postgres, still some failing tests maybe, ... ?
[15:55] <peterdietz> (try to guage if resources need to be shifted around, or if people should just keep doing what their doing).
[15:56] <tdonohue> peterdietz: each webapp is "claimed". Most of the folks working on them are here today. The only exceptions are aschweer (who nearly has SWORD v1/v2 done), and abollini (who gave a status update on JSPUI to -devel recently)
[15:56] <KevinVdV> 2 tests are still failing
[15:57] <tdonohue> Each webapp also already has a PR with the exception of JSPUI (still waiting)
[15:57] <tdonohue> (but some PRs are still "work in progress" obviously)
[15:58] <tdonohue> So, I think JSPUI is the biggest question mark, but abollini seems to be working hard on it, and said he hoped to have something by the end of this week
[15:59] <hpottinger> that's an amazing body of work, folks
[15:59] <tdonohue> As soon as these Mailing List migrations are done (tomorrow), I plan to also dig in myself...more to help test things & do minor cleanup.
[15:59] <peterdietz> JSPUI / XMLUI is super humonguous... Crazy amounts of work. It would be nice to come up with find and replace scripts
[16:00] <tdonohue> Oh. I just looked at my calendar. I'm on vacation next week!
[16:00] <peterdietz> REST is about 20 classes. I did it manually
[16:00] <hpottinger> tdonohue: grats!
[16:00] <tdonohue> Dang... Um, anyone willing to lead this meeting next week? I just realized I'm off all week long :)
[16:00] <peterdietz> Vacation on the first week of school.. At university, you get shot for that
[16:00] <tdonohue> The main priority is obviously trying to finalize/finish up Services API
[16:01] <tdonohue> peterdietz: I don't work at a school...so ha :)
[16:01] <hpottinger> I went on vacation for a week prior to our scheduled upgrade to 5... I'm still amazed we pulled it off last week.
[16:02] <tdonohue> OK, no takers for calling this meeting next week @ 20UTC on Weds Sept 2? I suggest you all self-organize then and talk about Services API work
[16:03] <peterdietz> I can be the taker then
[16:03] <tdonohue> Thanks peterdietz, much appreciated.
[16:03] * roeland (~roeland@85.234.195.109.static.edpnet.net) has left #duraspace
[16:03] <KevinVdV> I should be on time next week btw ;)
[16:04] <hpottinger> it's easy to miss the meeting announcements part of the job, consider this the gentle reminder
[16:04] <tdonohue> Ok, as we are now over 1 hour...any final topics/questions? Or do we feel ready to continue tackling Services API, etc? (Obviously feel free to keep sending questions to dspace-devel, as they come up)
[16:04] <mhwood> Thanks for coming today.
[16:05] <mhwood> I know how I should proceed, for now.
[16:05] <tdonohue> hearing no final topics/questions, we'll close things up. As a last note, the DSpace UI Working Group did meet yesterday (notes linked in our agenda). Their next meeting is next Monday at 14:30 UTC (announcement forthcoming to lists)
[16:06] <peterdietz> I have a follow up question. Should REST continue to show/support legacyID, or should I switch to UUID?
[16:07] <mhwood> Switching should mean it's time to figure out API versioning.
[16:07] <pbecker> peterdietz: perhaps you can use the findByIdOrLegacyId(Context, String) methods to support both?
[16:07] * tdonohue is going to consider this the "after party". Official meeting is closed, but please do feel free to answer peterdietz's question, as it's a good one :)
[16:07] <peterdietz> It could be a breaking compatibility change. community/:id where :id is integer to community/:id where ID is String.. Or leave the existing int ID alone, and add a new field :uuid.
[16:07] <peterdietz> Yeah. It might be version time.
[16:08] <tdonohue> +1 version time sounds about right to me. But it would be nice to find a way to not fully *break* v1.0 of REST
[16:08] <KevinVdV> Well that depends, it could do both. The code to support legacy id isn’t going away. Just keep in mind that new objects will NOT receive a legacy id
[16:08] <KevinVdV> Personally I would keep support for both
[16:09] <pbecker> https://wiki.duraspace.org/display/DSPACE/DSpace+Service+based+api#DSpaceServicebasedapi-DSpaceObjectisaseparatedatabasetable(UUIDisnewidentifier) describes the findByIdOrLegacyId to support both.
[16:09] <kompewter> [ DSpace Service based api - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DSpace+Service+based+api#DSpaceServicebasedapi-DSpaceObjectisaseparatedatabasetable(UUIDisnewidentifier)
[16:10] <mhwood> So an existing repository will contain old objects that have integer IDs, and new objects that don't? Then we need ongoing support for integer IDs.
[16:10] <peterdietz> The safest route is to "be liberal in what you accept and conversative in what you send". So, I'd want to expose legacyID as it used to be exposed, and expose UUID as a new field. People can access a collection by the legacy ID or UUID.. I think it should be fine. I'll have to deal with the quirk of new DSO's not having legacyID, show those as a null ID, or
[16:10] <peterdietz> just not show that field? (I guess those are rest questions)
[16:10] <peterdietz> old objects have INT + UUID, new objects have UUID (but not int)
[16:11] <mhwood> If the value doesn't exist, just don't mention it.
[16:11] <peterdietz> I'm wondering if I allow /collection/1234-abcd-5678 or if we'll want a new endpoint /dspaceobject/1234-abcd-5678
[16:11] <pbecker> Or perhaps just not show old IDs at all, but accept them in requests?
[16:12] <peterdietz> I'm tempte to do that... But then that would be a breaking change I suppose.
[16:12] <peterdietz> if some client depended on old id existing, and being of type int
[16:12] <pbecker> Or deprecate them: showing them now, and telling everybody that we will remove them with DSpace 7....
[16:12] <peterdietz> what do we call new uuid's internally? UUID, ID, ?
[16:12] <peterdietz> how should i expose that via rest?
[16:13] <pbecker> that can't be exposed via rest, it would have to be written down in the documentation as we did with other features before.
[16:13] <pbecker> But it would mean to continue for one year with lagacy ids in REST (input + output)
[16:14] <pbecker> perhaps you can use a http 3xx code for some requests for old IDs?
[16:16] <mhwood> I just realized that we're going to have "old" and "new" objects represented in Solr too. I have some Perl code that will need tweaking.
[16:18] <mhwood> peterdietz: I'd say that UUIDs are a new field and need a new name, such as "UUID".
[16:19] <KevinVdV> <= needs to run, if more questions about the services popup feel free to email dspace-devel I’ll be on the lookout
[16:19] <peterdietz> I think we're post-meeting, so anything goes right? I propose that in some DSpace-next that we merge community and collection. I don't see any benefit to them being mutually exclusive in capabilities.
[16:19] * KevinVdV (~KevinVdV@d54C5104D.access.telenet.be) Quit (Quit: KevinVdV)
[16:19] <tdonohue> Internally, it looks like the DB column is called uuid. In the API level they are sometimes referenced as "id" but the type is still UUID, e.g. https://github.com/DSpace/DSpace/blob/DS-2701-service-api/dspace-api/src/main/java/org/dspace/content/service/DSpaceObjectService.java#L43
[16:19] <kompewter> [ DSpace/DSpaceObjectService.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/service/DSpaceObjectService.java#L43
[16:19] <kompewter> [ https://jira.duraspace.org/browse/DS-2701 ] - [DS-2701] Adopt Service-based API refactor of existing Java API - DuraSpace JIRA
[16:20] <peterdietz> yeah. I'll go the safe route until I make proper versions of resource representations
[16:20] * tmtvl (d577a5df@gateway/web/freenode/ip.213.119.165.223) has left #duraspace
[16:20] <tdonohue> peterdietz: that proposal to merge community/collection is already on the RoadMap https://wiki.duraspace.org/display/DSPACE/RoadMap It's under 7.0 Priority 1
[16:20] <mhwood> If it's called "ID", and some objects have an integer ID, what do you call the latter?
[16:20] <kompewter> [ RoadMap - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/RoadMap
[16:20] <pbecker> mhwood: legacyID
[16:21] <peterdietz> legacyID.. But they were there first
[16:21] <peterdietz> FirstNationID
[16:21] <mhwood> Then the name changed? That's a new version of the API, certainly.
[16:21] <tdonohue> I think we'd want a new version of the REST API anyhow if we are adding a new "UUID" field.
[16:22] <tdonohue> So, I don't think this is a question about versioning REST. I think we need to version the REST API. We just need to keep backwards compatibility with v1 of REST
[16:22] <mhwood> It could be a minor release, though, if it doesn't break existing code. Renaming ID breaks code.
[16:23] <peterdietz> v1 (current), will have to leave :id (int) and can freely add more data :uuid (string) without harming the representation/compatibility
[16:24] <peterdietz> v2 (non existant) could rename uuid to id, and drop the legacy id, and just document thats the way it is
[16:24] <tdonohue> seems like a plan
[16:24] <tdonohue> (i.e. sounds good)
[16:24] <mhwood> Is there a reason not to just drop :id in v2 and keep :uuid? Less breakage when upgrading tools.
[16:25] <peterdietz> yeah i guess that would be fine too. If there was a better name for the uuid, then we could name it that. dsoID ?
[16:26] <mhwood> What is wrong with "uuid"?
[16:26] <peterdietz> Are guid/uuid the same thing? What if we changed the implementation.. not really worth wasting breath about. uuid can be fine. I think that's what I've been thinking of it as
[16:27] <mhwood> GUID is Microsoft for UUID, I'm told.
[16:27] <tdonohue> either way is fine by me. I wasn't arguing against uuid as a name. I was just thinking we need to find a way to warn against using "id" (legacyID) in 6.0. It won't work for new objects. So, technically, v1 of REST API won't work entirely with 6.0...new objects won't appear unless you switch to using UUID
[16:28] <tdonohue> hence, we need to version the API
[16:28] <tdonohue> v1 is not entirely backwards compatible...it only works for *old* existing content
[16:28] <mhwood> Yes, "new objects won't appear" is one way of breaking. "Cracks wide open because it received a value it couldn't understand" is another and, IMO, worse way of breaking.
[16:30] <tdonohue> Yea, I agree. I was just making sure we understand there's no way for 100% backwards compatibility with 6.0
[16:30] <mhwood> We need to get the word out one way or another, that old code will start to fail (one way or the other), regardless. "Stop using ID and start using UUID" is simple. Renaming is confusing, at least to me.
[16:30] <tdonohue> And we'll need to make that clear in the docs, and recommend folks change their code to use UUIDs instead of old IDs
[16:32] <pbecker> If we break the code this way, we could even think about dropping support for legacy IDs in REST immediately.
[16:32] <tdonohue> I'll leave this up to peterdietz to propose a "REST way"..and then we can discuss that proposal more. I'm still not certain myself which was is less disruptive, so it might take some thought or looking at some sample client code
[16:32] <tdonohue> s/was/way/
[16:32] <kompewter> tdonohue meant to say: I'll leave this up to peterdietz to propose a "REST way"..and then we can discuss that proposal more. I'm still not certain myself which way is less disruptive, so it might take some thought or looking at some sample client code
[16:33] <mhwood> If people have recorded IDs then they need a way to translate them to UUIDs before we take IDs away. I'd suggest deprecation in 6 and removal in 7.
[16:37] <tdonohue> yep, I think that's what peterdietz recommended as well. I think the only outstanding question is whether it'd be less disruptive to keep things called "uuid" or if there's any argument to renaming to "id" in 7. That seems like a question we don't need to answer right now necessarily.
[16:39] <mhwood> True, it's not urgent. It would be nice to be able to document it in the roadmap soon, though, so that, come January or so, we simply read the roadmap and do what it says.
[16:39] <mhwood> That documentation doesn't have to be complete today, but it would be nice to reach consensus soon.
[16:44] <tdonohue> Honestly, I think the "default" will be that we retain the name "uuid" if that is what we are using in 6. If there's a good reason to move to "id" in 7, we can do that...but so far this all seems speculative, and we'd need to analyze any "good reasons" to do the rename.
[16:44] <hpottinger> I'm curious if we're going to sort the backlog today?
[16:44] <tdonohue> at this point, we've lost our backlog hour :)
[16:45] <hpottinger> OK by me, I've got things to keep me busy :-)
[16:45] <peterdietz> I've got a new rest PR that I'm suspending review of until services gets merged
[16:45] <peterdietz> (monika's)
[17:06] * hpottinger (~hpottinge@mu-160190.dhcp.missouri.edu) Quit (Quit: Leaving, later taterz!)
[18:37] * pbecker (~pbecker@ubwstmapc098.ub.tu-berlin.de) Quit (Quit: Leaving)
[19:39] * hpottinger (~hpottinge@mu-160190.dhcp.missouri.edu) has joined #duraspace
[20:43] * cknowles (uid98028@gateway/web/irccloud.com/x-dnlqrspkrjvrnpsr) Quit (Quit: Connection closed for inactivity)
[21:11] * mhwood (mwood@mhw.ulib.iupui.edu) has left #duraspace
[21:24] * tdonohue (~tdonohue@c-50-178-45-117.hsd1.il.comcast.net) Quit (Read error: Connection reset by peer)
[21:32] * tdonohue (~tdonohue@c-50-178-45-117.hsd1.il.comcast.net) has joined #duraspace
[21:47] * tdonohue (~tdonohue@c-50-178-45-117.hsd1.il.comcast.net) has left #duraspace
[21:58] * hpottinger (~hpottinge@mu-160190.dhcp.missouri.edu) Quit (Quit: Leaving, later taterz!)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.