Tim Donohue [10:30 AM] @here: It's now time for DSpace 7 REST API updates, as part of our weekly checkin meeting [10:30] @bollini , I know you've been on holiday, but I'm not sure if there's anything specific you'd like to highlight yourself today?
Andrea Bollini [10:31 AM] I'm only aware about the activities in the REST contract
[10:31] (discovery) search: https://github.com/DSpace/Rest7Contract/pull/9
[10:32] authentication: https://github.com/DSpace/Rest7Contract/issues/10
Tim Donohue [10:32 AM] I believe that is the biggest effort currently, @tom_desair's search endpoint proposal (and I think Tom is on holiday himself this week) https://github.com/DSpace/Rest7Contract/pull/9
Andrea Bollini [10:33 AM] I think that we almost agree about the discovery search, so I will ask Tom if he want to make the change to the PR and we can proceed to merge
Tim Donohue [10:33 AM] Sounds good
Andrea Bollini [10:33 AM] as he will work also on the implementation no need to rush, we can wait for him
[10:34] authentication is more debate [10:35] probably it will be useful to make some experiments. I plan to play a bit with the support provided by Spring Security next week
[10:36] btw, spring security (should) make easy to implement oauth2/openid or "plan" JWT as well
Tim Donohue [10:36 AM] Yes, I suspect a basic proof of concept would help alleviate concerns & make it more "tangible". Currently, the idea seems "reasonable" to me, but I'm not sure if it's easily doable with our current AuthN/Z or if it'll result in a major overhaul (the latter of which may affect our development/release schedule)
Andrea Bollini [10:37 AM] I agree with you, I don't think that we have the resource to rework our AuthN/Z for DSpace 7
[10:38] so what I propose is *only* to have a standard layer to access our custom / current implementation Tim Donohue [10:39 AM] As a related sidenote, I've also been hearing some feedback (from a few folks) that there are users who are concerned about the DSpace 6 to 7 upgrade. I'm starting to feel that the less we change in the data model & configuration the better (as it'd be nice to say "your configs/data easily move forward"), and concentrate more heavily on just the UI
[10:40] (In other words, we shouldn't strive to do everything at once, as it also makes upgrades that much harder...we should consider keeping major API/data model/config changes for releases post-DSpace 7.)
Andrea Bollini [10:40 AM] we can provide automatic migration for configuration files where needed Mark Wood [10:41 AM] Figuring out how to bring forward our customizations using a completely new framework is going to be daunting enough.
Andrea Bollini [10:41 AM] this is why I saw that we should provide automatic migration in some case
[10:42] I don't expect that our item-submission.xml makes any sense in DSpace7
Tim Donohue [10:42 AM] I'm just saying I've been hearing concerns that we are potentially "pulling the rug out" and making an already hard upgrade much much harder. We need to avoid that perception and/or reality. It's still possible to tweak some configs (and auto migrate them forward), but we shouldn't tweak any configs that aren't "auto-migratable" (in some fashion) (edited)
Andrea Bollini [10:43 AM] BTW, I expect to hit soon these kind of issues because I need to work on expose the submission configuration over REST Tim Donohue [10:45 AM] Right, which is exactly why I bring them up. I fully realize the `item-submission.xml` and `input-forms.xml` are hard to support in that model (and actually may have outlived their welcome anyhow). But, if those configs are no longer used, it's important to find a way to auto-migrate changes folks made there [10:45] (and/or find a way to load configs from those files the first time you upgrade...and then ignore them afterwards) Andrea Bollini [10:45 AM] ok, we will have more to say on that next week. My expectation is that input-forms.xml will be supported /migrated [10:46] item-submission.xml will raise warning that need to be manually solved because it could involve custom classes Terry Brady [10:47 AM] Joining late... if auto-migrate is not possible then having a tool to validate compatibility between and old/new version may be useful. Tim Donohue [10:47 AM] @bollini: custom code is always an issue, so that's not an unreasonable warning. It's just avoiding warnings on small custom *config* changes I want to see (edited)
Andrea Bollini [10:48 AM] another thing that we can anticipate so to start to think about.... workflow [10:48] right now we have two different workflow engine Terry Brady [10:48 AM] It is definitely good to be thinking about this now. Perhaps another page should be added to the contract repo to document which configs will/will not be impacted Andrea Bollini [10:48 AM] do we need to support both? do we want to force the migration to the new one in dspace 7?
Mark Wood [10:49 AM] Dropping the fixed workflow is on the schedule for 7, no?
Terry Brady [10:49 AM] Since DSpace 6 changed the format of config files from DSpace 5, will we need to ask folks to upgrade to 6 and then to 7, or will we support 4->7 and 5->7 upgrades? Tim Donohue [10:51 AM] @terrywbrady : 4->7 and 5->7 upgrades are supported...they just need to realize there's a new config system in place (as of DSpace 6). So the upgrade process is similar to upgrading to 6 now with regards to configs (edited)
[10:52] With regards to Workflow, I think we can drop the fixed, traditional workflow in 7 if it makes our lives easier. It's already deprecated. So, if we want to simply support Configurable/XML Workflow that's fine.
Mark Wood [10:52 AM] Isn't that a roadmap item?
Andrea Bollini [10:52 AM] I'm trying to find the link...
Tim Donohue [10:53 AM] https://jira.duraspace.org/browse/DS-3041
[10:53] Yes, it's also listed on https://wiki.duraspace.org/display/DSPACE/RoadMap , but currently under "Post-7.0 Features"
Mark Wood [10:54 AM] Oh, sorry.
Tim Donohue [10:54 AM] We can move that up into 7.0 if it makes our lives easier. But, we don't *have* to do so
Terry Brady [10:54 AM] Would it make sense to advise folks to migrate to XML Workflow in 5/6 before attempting to upgrade to 7? (To simplify the migration process)
Tim Donohue [10:54 AM] Currently it's not in 7.0 Roadmap as we haven't discussed it in great detail, and what it'd mean to drop Traditional Workflow altogether
Mark Wood [10:54 AM] Whether you can migrate in 6 depends on what features you use and what UI you use. Each implements something that the other omits.
Andrea Bollini [10:55 AM] my understanding is that the issues with the xml workflow is that it is not wide used and tested
Tim Donohue [10:55 AM] @terrywbrady : XML Workflow in DSpace 5/6 is not fully featured. See the subtasks under https://jira.duraspace.org/browse/DS-3041 (XML Workflow doesn't work in JSPUI and doesn't support curation tasks currently) (edited)
Andrea Bollini [10:55 AM] and it is hard to support because it is only available for the xmlui
[10:56] but this can be solved in dspace 7
[10:56] I need to take some time to study in more detail the xml workflow but I guess that it will be easier to support just one in dspace 7
Terry Brady [10:56 AM] OK... just another tricky consideration for the upgrade
Mark Wood [10:57 AM] I would love to see the configurable workflow and curation issues sorted. Maybe I can contribute in those areas.
Tim Donohue [10:57 AM] I think the long term goal here is to have a *single workflow system*. If it makes DSpace 7 easier, we can make this step in DSpace 7. But, we need to (again) ideally ensure an auto-upgrade of workflow configs into DSpace 7
[10:58] Currently, I think the best candidate for that single workflow system (out of our two options) is the XML Workflow (as it's much more configurable and defaults to same settings as the traditional workflow). But, the final decision need not be that, as long as we have a way to move into it easily from both our existing workflow systems (edited)
Andrea Bollini [10:59 AM] wait wait :slightly_smiling_face: we don't have other candidate, we cannot develop a new workflow system for dspace 7
Mark Wood [10:59 AM] Please, no.
Tim Donohue [10:59 AM] I'm not saying we should. I'm just walking through the logic here. We need *one*, and XMLWorkflow is the best we have. So, we probably should use that as the one (if we are making that step in DSpace 7)
Mark Wood [11:00 AM] I mean: let's not do a third one.
[11:01] Configurable workflow needs curation support. Ripping out fixed workflow would make that a lot easier.
Andrea Bollini [11:01 AM] as you can imagine I'm not a fun of the XML Workflow (as I live happy with the jspui) but it has more (core) feature than JSPUI so yes, also my opinion here is that we should try to put effort in improving it instead to waste time keeping support for two in dspace 7 Tim Donohue [11:02 AM] yes, I'd rather fix the issues with XML Workflow. And for what it's worth, XML Workflow *didn't* have those major security issues we recently found in Traditional Workflow. So, it's "better" in that way too :wink: Andrea Bollini [11:02 AM] for the next meeting or the next I will try to put the contract for the workflow endpoint assuming that we will stay only with the XML Workflow
Tim Donohue [11:04 AM] Ok, so this has been a great discussion, but I'm realizing we are over time (by 4 minutes) Andrea Bollini [11:04 AM] ok, anyone else have plan for the REST API that can be shared?
Tim Donohue [11:05 AM] Yes, any last updates / questions to share?
Terry Brady [11:05 AM] I will start a page to document anticipated config changes related to the upgrade and add it to the Contract repo.
Andrea Bollini [11:06 AM] maybe, a wiki page could be a better location? [11:06] it will be easier to move in the documentation and it is not really related to the REST contract
Tim Donohue [11:06 AM] Yes, config changes can go on the wiki. It doesn't have anything to do with a REST contract
[11:06] We do have this page where notes could be started (even rough notes): https://wiki.duraspace.org/display/DSPACE/DSpace+Release+7.0+Status
Andrea Bollini [11:07 AM] anyway thanks @terrywbrady to volunteer for that!
Tim Donohue [11:07 AM] But, I'd caution against putting things up that are quite uncertain. So, we shouldn't promise something there until we have made a decision on which configs are changing & how they are changing
Terry Brady [11:07 AM] I can put it where you suggest. If the REST code will be reading the config and acting on it, then it is related to the code
Tim Donohue [11:08 AM] right, it may be related to REST *code*, but not the contract (the contract defines how the REST endpoints will respond when you query them)
Terry Brady [11:08 AM] @tdonohue , there where is the appropriate place to document a common understanding of what might need to change Tim Donohue [11:08 AM] And technically, REST is likely gonna grab configs via the Java API (so it's likely more related to the Java API anyhow)
Andrea Bollini [11:09 AM] maybe linked to the notes about the REST API Dev?
Tim Donohue [11:09 AM] @terrywbrady : if the docs you are talking about are brainstorms/questions...just create a subpage under our https://wiki.duraspace.org/display/DSPACE/DSpace+7+Working+Group
[11:09] Once the ideas are "finalized" (or nearly final) we can move them over to https://wiki.duraspace.org/display/DSPACE/DSpace+Release+7.0+Status [11:10] Ok, with that, let's close up today's meeting. We're already 10 mins over, and I don't want to steal anymore time from you all!
[11:11] I'll still be hanging around a bit though if further questions/comments come up. Just ping me on one of these channels
Andrea Bollini [11:11 AM] I agree, put a link also here https://wiki.duraspace.org/display/DSPACE/DSpace+7+REST%3A+Coding+DSpace+Objects as it should be the page where new JAVA developers start from for DSpace 7
[11:12] ok, thanks to all to join the conversation today! it is mid August!
Tim Donohue [11:12 AM] Thanks all! We'll talk again next week via Google Hangouts (Thurs, Aug 17 @ 15UTC)
Terry Brady [11:43 AM] I took a first pass at documenting config file change assumptions and placed it where Tim suggested: https://wiki.duraspace.org/display/DSPACE/Anticipated+Configuration+Changes+in+the+DSpace+7+Upgrade [11:43] If this looks useful, feel free to link to other spots.
|