Contribute to the DSpace Development Fund

The newly established DSpace Development Fund supports the development of new features prioritized by DSpace Governance. For a list of planned features see the fund wiki page.

Date

Angular meeting

Attendees

Notes

Slack Logs (times are all CDT)

Tim Donohue [9:52 AM]
@here: Reminder, at the top of the hour, our DSpace 7 Working Group meeting begins in Slack (#angular-ui and #rest-api). Today, we are going to keep the meeting _brief_, and concentrate on any final prep for OR2017 next week.


Tim Donohue [10:00 AM]
@here: Time to kickoff our DSpace 7 Working Group meeting. As noted above, let's keep this as brief as possible today (as I know everyone is busy prepping for OR2017), and just concentrate today on things still left to be done *prior to OR2017*.


[10:01]
@art-lowel do you want to give some brief updates on anything left on the Angular side?


Art Lowel [10:01 AM]
yes, thanks


[10:01]
I created a PR that combines the connection with the live rest api, with the DSO List, and a start at the browse component


[10:01]
(enough so we can browse from the homepage up to an item)


[10:01]
https://github.com/DSpace/dspace-angular/pull/117


Tim Donohue [10:02 AM]
Nice. Yes, I noticed it's a pretty massive PR. But that's ok :wink:


Art Lowel [10:02 AM]
You can see it in action at https://dspace7-demo.atmire.com


[10:02]
Yes it’s massive, my apologies, time pressure


Tim Donohue [10:02 AM]
Understandable


Art Lowel [10:03 AM]
Support for bitstreams as relations in an Item was added on Tuesday, but it worked a little different than I anticipated


Tim Donohue [10:03 AM]
Looking good though, based on the demo site


Art Lowel [10:03 AM]
Thanks


Andrea Bollini [10:03 AM]
yes, it is nice

Art Lowel [10:03 AM]
The links section contained a single URL to an endpoint where you can fetch the list of related bitstreams

[10:04]
instead of an array of the self urls of each individual bitstream (paginated)

[10:04]
Here’s an example of such a URL

[10:04]
http://dspace7.4science.it/dspace-spring-rest/#http://dspace7.4science.it/dspace-spring-rest/api/core/items/0ec7ff22-f211-40ab-a69e-c819b0b1f357/bitstreams

[10:05]
As a consequence, the embedded bitstreams in the response weren’t used, because there’s no way of knowing that those were indeed the exact same bitstreams that would be returned for the above URL

[10:05]
and opening a list of items was painfully slow (edited)

[10:05]
to fix that problem for OR, I made the assumption that the bitstreams embedded in an item response would be the bitstreams returned from that relation URL

[10:05]
We should probably revisit that assumption later

Tim Donohue [10:06 AM]
Could we simply create a ticket for that, for now?

[10:06]
(Just don't want it to be forgotten)

Art Lowel [10:06 AM]
Sure


Andrea Bollini [10:06 AM]
mmm... I have not understand the point but yes we can discuss that later :slightly_smiling_face:


Tim Donohue [10:07 AM]
Even just copying what you said above into a ticket is enough... I just know that you'll be traveling a bit, post-OR, @art-lowel, so we should track this somewhere :wink:

Art Lowel [10:07 AM]
The point is: if the _links section contains a single URL for a set of items

[10:07]
we can’t verify that the embedded items belong to that set, without doing an additonal request to that URL (edited)

[10:08]
we could, if it were to contain an array of self urls

Art Lowel [10:08 AM]
But I’ll create a ticket
1 reply 25 days ago View thread

Art Lowel [10:09 AM]
My PR also contains @atarix83 ‘s fix for images with broken URLs


Tim Donohue [10:09 AM]
ok, I thought I saw that in there too


Andrea Bollini [10:10 AM]
it is deeply nested so your assumption is always true, anyway we can talk more on that on the ticket and at OR (maybe at the workshop)


Art Lowel [10:10 AM]
sounds good


Tim Donohue [10:11 AM]
Ok, so, should we just merge this "as-is"? Is there any further testing you are looking for here, @art-lowel , or do you feel this is good enough (and won't break anything for the OR workshop or anything)


Art Lowel [10:11 AM]
I’ll leave it open until tomorrow, about this time


[10:11]
so if people want to test, or review they can


[10:11]
it would be appreciated :wink:


[10:11]
don’t want things breaking unexpectedly

Tim Donohue [10:13 AM]
Ok, sounds fine. I'll see if I can also fit in a quick test today (though other testers are more than welcome). Just an FYI, I won't be around tomorrow (as I'll be on my way to Australia)


[10:13]
Any other pre-OR2017 updates from you, @art-lowel ? Everything on the workshop side coming along OK?

Art Lowel [10:14 AM]
The unexpected effort to make the bitstreams work set me back a few hours more, but it’s coming along yes

Tim Donohue [10:15 AM]
Ok, sounds good. Just wanted to be sure there wasn't anything else you needed from us today

[10:16]
@bollini, shall we switch over to REST API updates now in #rest-api?

Andrea Bollini [10:16 AM]
ok, it is relevant for #angular-ui of couse


Tim Donohue [10:16 AM]
Ok, we can just stay here then...that's fine. Go ahead with your updates @bollini

Andrea Bollini [10:17 AM]
the current demo rest server has been updated including some not yet merged PR

[10:17]
https://github.com/DSpace/DSpace/pull/1778

[10:17]
https://github.com/DSpace/DSpace/pull/1783

[10:18]
the first one is related to the ability to embed collections of resources

[10:18]
such as the bitstreams in the item response

[10:19]
it is a large effort because on the backend it provides much more than what we actually see

[10:19]
it open the doar to lazy loading of embedded information

[10:19]
and actually there are some example in the comments that show how this work


[10:20]
for instance it is possible to include information about the first page of content when you ask for the configured browses


[10:21]
http://dspace7.4science.it/dspace-spring-rest/#http://dspace7.4science.it/dspace-spring-rest/api/core/items/9f3288b2-f2ad-454f-9f4c-70325646dcee


[10:22]
here you can see the list of bitstreams for this specific item but the same apply when you as for a list of items from the api/core/items endpoints or in future from /discover/browses etc.


[10:22]
right now embedded collections that has been already full retrieved are never paginated in the response


[10:22]
i.e. all the bitstreams of an item are included


Tim Donohue [10:23 AM]
very good


Andrea Bollini [10:23 AM]
but the format response is already structured for pagination, so it should be transparent to the client if we change that later


[10:24]
the 1778 pr requires lot of improvements but I think that can be merged and improved on the go

Tim Donohue [10:25 AM]
My only (tiny) note about 1778 is what I commented on in the PR. It seems to possibly need a rebase, as GitHub seems confused about the 1775 PR commits (which are already on master)


[10:25]
https://github.com/DSpace/DSpace/pull/1778#issuecomment-310081259

[10:25]
From what I can tell, 1778 is really just one commit (the last one)...but GitHub thinks it is 7 commits

Andrea Bollini [10:26 AM]
ok I will do the rebase


Tim Donohue [10:26 AM]
(the previous 6 commits were part of 1775, which was already merged) (edited)

Andrea Bollini [10:26 AM]
yes, I have made also a mistake when I pushed the commits

[10:26]
initiaally I have created the branch in the DSpace/DSpace repo, this could be the cause

[10:27]
anyway, I can do the rebase and check if it looks better

Tim Donohue [10:27 AM]
I suspect a simple rebase will solve those previous mistakes (as well), and get Travis to work properly again for this PR. Thanks!


Andrea Bollini [10:27 AM]
the 1783 pr instead is about the retrieve of the bitstream content. It is an early implementation just to have it in the OR demonstration so I will prefer to wait before merge


[10:28]
for instance we need at least to solve the reported issue by @art-lowel about the name of the file


Tim Donohue [10:28 AM]
That's fine. We can even wait until post-OR2017 to merge 1783


Art Lowel [10:28 AM]
@bollini I solved that issue on the demo server by adding a proxy for the rest backend


[10:29]
as long as the download links to the same host as the UI, you can fix that problem from the UI

[10:29]
so it’s not urgent

Andrea Bollini [10:29 AM]
ok

[10:30]
this was last update from me. Right now I'm working on build a more real test database but it is taking more time than expected

Tim Donohue [10:31 AM]
Ok, if you aren't able to achieve that in time for OR2017, that's OK. It'd be nice to have obviously, but we can simply state that we're working on loading more "real" content for post-OR.


Andrea Bollini [10:33 AM]
looking to our original priority list we have done the first 3 points


[10:33]
4. more real-like demo database
5. community from the collection
6. logo from community and collection


[10:34]
do you still want 5 and 6? or it is too late?


Art Lowel [10:34 AM]
I’d leave it at 4


Tim Donohue [10:34 AM]
A huge thanks to @art-lowel and @bollini for all your hard work leading up to OR2017 (and your continued hard work until next week)! A huge thanks also to everyone else who's been actively helping in code (@atarix83 , @lotte, @sourcedump, @alexm , @christian-scheible and anyone else I've forgotten)


[10:35]
I think we can leave it at 4 as well. This is "good enough" for OR2017. To be honest, with only a 1/2 hour update talk, I'm not sure how much of a live demo I'll be able to do. But, having the two demo sites up is a big bonus (and I'll promote & link to both), and it's great that we've gotten the basic browse functionality done for those demo sites (edited)

Art Lowel [10:36 AM]
Ok, thanks a lot to you as well @tdonohue


Andrea Bollini [10:38 AM]
ok, I will take a copy of the current state of the rest demo server safe. But I will try to switch to a real-look database until saturday

[10:38]
I will leave for Brisbane on Sunday

Art Lowel [10:39 AM]
Sounds good, I’ll see you all there


Tim Donohue [10:39 AM]
We'll stop there for today. Again, a big thanks to everyone. I think OR2017 is gonna be exciting, and I look forward to seeing others there (who can make it)! For those who won't be able to join us, there will obviously not be any meetings next week...but we'll touch base again on July 6 with updates from OR2017 (for those who are back)


[10:39]
I leave for Brisbane tomorrow, but arrive on Sunday mid-day (yikes, it's a lot of travel). See you there!


REST meeting

Attendees

Notes:

Slack Logs (times are all CDT)

(NOTE: REST updates were given as part of Angular updates. See above.)