Tim Donohue [10:31 AM]
Hi all, we began today's DSpace 7 Developer meeting over in #angular-ui ... so, see that channel for brief updates from OR2017, and updates on Angular UI work this week (edited)
Now, moving on to REST API updates in this channel. @bollini, anything to add here for this week?
Andrea Bollini [10:32 AM]
we have two PRs that are already in the demo rest installation but not yet merged
Tim Donohue [10:34 AM]
1778: I suggested rebasing this PR against latest `master` in order to try and work out the Travis problems (as Travis is confused about the current branch status, as you noted). A simple rebase should fix this, I believe
After that, it looks fine to merge (to me). But, it'd be nice to get Travis to approve it fully
Andrea Bollini [10:35 AM]
ok so I will rebase 1778 and open a new PR that could be merged soon if travis give green light
Tim Donohue [10:35 AM]
Sounds good. You might be able to simply rebase in the existing PR (and do a `git push --force`). But if that doesn't work, a new PR is also fine)
Andrea Bollini [10:36 AM]
instead 1783 have two things that I don't like so far
Tim Donohue [10:36 AM]
I haven't had a chance to look at 1783...but, I'm perfect OK with going ahead and merging this to sync up `master` with the demo site...as it's shown to work on `master`
Andrea Bollini [10:37 AM]
1) I'm not sure that /retrieve is the right name for the endpoint as it is a verb
Tim Donohue [10:38 AM]
Yes, maybe `/retrieve` should be something like `/content`
Andrea Bollini [10:38 AM]
I have initially proposed it or /content and with @art-lowel we have decided for the first... but now I have changed my mind... so just want to check other opinion
Tim Donohue [10:39 AM]
I think I'd have a slight preference for /content myself
Andrea Bollini [10:39 AM]
2) the HEAD method is not yet implemented
two options here: we can merge as it is now and open issues to discuss/improve or we can wait
Tim Donohue [10:40 AM]
Despite all this, is it worth merging 1783 as-is (to sync it up with the demo site), and creating a new ticket/PR for the enhancements you want to make?
I think I lean towards merging as-is... otherwise the demo site is "out of sync" with master...and I'd rather the two be mostly "in sync"
Andrea Bollini [10:41 AM]
ok, if we merge 1783 now we will get also the 1778 in
Mark Wood [10:41 AM]
How long would it take to change the endpoint name? Changing names after exposing code is troublesome.
Andrea Bollini [10:41 AM]
it is a line change on the rest side
and it could require no changes on the angular side if it has been implemented following the "link"
but I'm not sure about that, maybe @atarix83 can help me tomorrow to check that
(the current angular demo shows the logo for the communities and collections)
Tim Donohue [10:43 AM]
Good question... yes, if it doesn't affect the Angular UI side, then maybe simply changing that name is worth doing now
Andrea Bollini [10:44 AM]
ok, we will check that tomorrow and change or not the endpoint name depending on the result. After that the 1783 will be merged
the HEAD stuff will go in a future issue
Tim Donohue [10:44 AM]
Andrea Bollini [10:45 AM]
ok, my plan for next week is to align the REST contract with the last developments
and if possible finalize the search endpoints (findTopCommunities, etc.) https://github.com/DSpace/DSpace/pull/1726
Tim Donohue [10:47 AM]
Andrea Bollini [10:47 AM]
once we have that I want to start to investigate on the authentication and the "creation" part so that we can work concretely on the submission and workflow
Tim Donohue [10:48 AM]
That makes sense as a next step. Authorization needs to fit in there somewhere as well, eventually
Andrea Bollini [10:49 AM]
yes but authorization is just a deal for the rest part. Authentication is more tricky for the interaction between angular and rest
so we want to have it soon
Mark Wood [10:50 AM]
authNZ should go in early. The longer you wait, the harder to get it right.
Tim Donohue [10:51 AM]
Yes, I'm more worried about putting AuthZ in later (as @mwood notes). I think AuthN comes first, yes (as it will be tricky). But, we need to start laying the groundwork for AuthZ early on as well, otherwise, it may turn out to be tricky if we don't know how it will be achieved at the REST API layer.
That said, I'm OK with starting submission/wokflow around or at the same time as AuthZ. I don't want to hold up the submission/workflow work
But, I don't want to delay AuthZ until the "end" :wink:
Andrea Bollini [10:52 AM]
oh well, yes we need to think about it. But... we already have AuthZ as it is embedded in the dspace-api (JAVA)
Mark Wood [10:53 AM]
And that is where it belongs. Current UIs do far too much of this themselves.
Tim Donohue [10:53 AM]
AuthZ is not entirely in the dspace-api right now...it mostly is... but there's some decisions being made at the UI level that need to now be in the *REST* level (or pushed down into dspace-api).
Andrea Bollini [10:54 AM]
so the question here is... are we able to improve AuthZ for dspace7 (I will be very happy to see work on this area but we need more people on board for that - maybe after dspace 6.1)
Mark Wood [10:54 AM]
That is the sort of thing which appeals to me. And I think that @hpottinger may be interested as well.
Tim Donohue [10:55 AM]
My suspicion is that improving AuthZ for DSpace 7 will require a team working hard on it. If folks like @mwood and @hpottinger are interested and have time to devote to it (i.e. their bosses agree to this), then it's doable. But, if not, we may have to stick with "what we have" for now.
So, I'd like to see specific time devoted towards this for DSpace 7....otherwise, I worry we could be taking on more than we should (as if specific time isn't devoted, and folks get busy, it could delay AuthZ work indefinitely)
And delaying AuthZ work until the end is a bad thing (as we already noted above) :wink: So, I'd like to see us avoid that risk, even if it means we have to decide to "go with the clunky AuthZ we currently have"
Just my opinion here
Mark Wood [10:57 AM]
Tim Donohue [10:58 AM]
But once @hpottinger returns from his travels, and @mwood and he have a chance to talk to their bosses, maybe we'll get a better sense of whether this is doable for DSpace 7
Thanks for expressing interest here @mwood!
We are now at the top of the hour (wow, it turned out to be a rather full meeting!)
Any last thoughts/comments/questions?
Andrea Bollini [10:59 AM]
Tim Donohue [11:00 AM]
no problem...it's good to discuss all of this :wink:
Mark Wood [11:00 AM]
No further thoughts here.
Andrea Bollini [11:00 AM]
next week we should have an hangout call
I will be on the train at this time, so I could eventually join a slack chat
but not an hangout call
just to let you know
Tim Donohue [11:01 AM]
So, are you asking for a Slack chat next week?
Andrea Bollini [11:02 AM]
if all you don't mind I will try to attend (not sure as it depends on the connectivity)
but if we have a good number of participant to the hangout it could be nice too
Tim Donohue [11:02 AM]
I'll try and touch base with others. We could just do another Slack chat next week if most folks are still traveling (as I know Art is out for several weeks anyhow)
So, I'll let you all know... once everyone is back in the office, we'll get back to our schedule of alternating weeks between Slack & Google Hangouts. But, I know a good number of folks are traveling or on holiday this month
Thanks all for the updates, and we'll talk more on Slack during the week as necessary. I'll ping everyone on the meeting location for next week!