2017-05-11 DSpace 7 UI Working Group Meeting notes

Art Lowel [5:03 PM]

@here alright, let’s get started

[5:03]
Tim is travelling this week, and said he likely won’t be joining us

[5:03]
Let’s start with the PRs

[5:03]
did anybody get a chance to look at them?

[5:04]
Rest relationships: https://github.com/DSpace/dspace-angular/pull/87

[5:04]
Item Page: https://github.com/DSpace/dspace-angular/pull/88

[5:04]
Then, as discussed last time, I’ll merge the relationships PR after this meeting

[5:05]
I’ll leave the Item Page PR open a while longer, as it was opened later than expected

[5:05]
it should also be easier to grasp, so I encourage you to take a look at it

[5:06]
I had a look at the Rest API demo instance and it turns out the HTTP access control (CORS) settings aren’t configured yet

[5:06]
As a consequence, a browser will refuse to fetch data from that server using javascript

[5:07]
HTTP access control is a security mechanism built in to browsers to ensure that you have explicit permission before you can access a server on a different domain using javascript

[5:07]
For a rest api you generally want to allow access to everyone

[5:07]
I informed @bollini on slack, and created a Jira ticket for the issue:

[5:07]
https://jira.duraspace.org/browse/DS-3588

[5:08]
We _could_ bypass the issue with a proxy server, which is what we did with the prototype

[5:08]
but as we have enough other things to do, and this shouldn’t be too hard to fix, I haven’t spent time on workarounds

Andrea Bollini [5:08 PM]
it will be fixed by the start of next week

Art Lowel [5:08 PM]
great

[5:09]
I did notice that the rest responses on the demo don’t contain UUIDs, is that on purpose?

[5:10]
If not, could they be added, we rely on those for a number of things in the current UI code

[5:11]
I’ll bring it up again during the rest meeting later

[5:11]
Currently I’m working on including support for communities in the rest services

[5:12]
That isn’t a lot of work, I expect to have a PR ready by tomorrow

Andrea Bollini [5:12 PM]
it is by design

Art Lowel [5:12 PM]
could you explain the reasoning behind it?

Andrea Bollini [5:13 PM]
I was looking to find an issue where we have already some notes

[5:13]
anyway, the self link should be all you need

[5:13]
the uuid is just redundant

[5:14]
BTW, include it is as easy as remove a jsonignore annotation

Art Lowel [5:14 PM]
not really, I can’t use the entire self link in the URL e.g. https://ui.url.com/items/https://rest.url.com/items/some-uuid

[5:14]
so then we’d have to start parsing it

[5:14]
it = the self link

[5:15]
I’d rather avoid that if possible

[5:15]
So if redundancy is the only objection, I’d prefer if you put it back in

Andrea Bollini [5:15 PM]
oh I see (edited)

[5:16]
you need the uuid to build the URL of "your" page, not to follow a link right? (edited)

Art Lowel [5:16 PM]
among other things yes

[5:17]
UUIDs are also used to refer to objects at the moment

[5:17]
but I agree that that could be replaced by self links

Andrea Bollini [5:17 PM]
ok

[5:18]
I'm going to create an issue to include the UUID in the json representation to avoid to forget about that

Art Lowel [5:18 PM]
Thank you

[5:19]
I also created a few additional tasks

[5:19]
I’ll ask lotte to work on one of those as well

[5:19]
Those were my updates

[5:19]
Does anybody else have something they’d like to discuss?

[5:20]
Ok, see you all next time!

Andrea Bollini [5:21 PM]
I have some questions that are cross rest-ui

[5:21]
if you stay around we can discuss in the rest channel in few minutes

Art Lowel [5:21 PM]
I will

Andrea Bollini [5:30 PM]
Hi all

Terry Brady [5:30 PM]
I have another meeting today, so I cannot attend. Unfortunately, I have been focused on 6x this week and have not made any progress on 7.

Andrea Bollini [5:31 PM]
ok @terrywbrady , do you plan to spend more time on dspace 7 in the next weeks?

Terry Brady [5:32 PM]
I imagine it will take a couple of weeks to finish what I am working on

Andrea Bollini [5:32 PM]
ok, thanks for your work on dspace 6

[5:32]
it is not easy to have two big task going on in parallel

[5:33]
Unfortunately I need to say that I haven't done much progress since last week too

[5:33]
I was at the annual coar meeting this week so...

[5:34]
so what is going on is

[5:35]
- browse endpoints: I have almost completed the implementation, so we should have a PR really soon

[5:36]
- generic search endpoints for resource filtering: I'm spending some time learning the low implementation done in the spring-data-rest project and the springmvc project

[5:36]
so some time could be necessary before to have a good generic solution in place

[5:37]
- cors header: as said in the angular meeting we need to support CORS. We look lucky as spring boot make that very easy, we will have that in place by the start of next week

[5:38]
- discovery search: I loss contact with @luizsan, so I don't know exactly if he makes any progress on that

[5:39]
I haven't other high level update to share. Anyone have comments, update to share?

[5:41]
I want to start the discussion around a general issue that we have about the UI and the REST API

[5:42]
the REST API in some way is a different representation of the UI

[5:43]
it should be needed to link a rest api endpoint with a UI URL or viceversa

[5:43]
for the UI it should be "easy" or at least possible to know about the REST endpoint, but the opposite is not necessary true

[5:44]
for instance the handle need to be resolved to an UI URL so the API needs to know about the UI URL structure

Art Lowel [5:45 PM]
does it? I didn’t think the rest api would resolve that for us

[5:46]
and putting information specificly about this UI in the rest api doesn’t seem like a good separation of concerns

[5:47]
unless it’s on an endpoint designed for sharing UI settings for example

Andrea Bollini [5:47 PM]
I agree but I worry that we have some needs in this direction

[5:48]
the current dspace-api know about the URL structure, as the handleresolver is in the dspace-api

Art Lowel [5:49 PM]
either in the angular prototype, or in the ember prototype I wrote a way to resolve handles from the UI, and that wasn’t too difficult

[5:49]
besides, if we have a handle endpoint on the rest api, that will make it even easier

Andrea Bollini [5:49 PM]
other than the handle resolution, I'm also thinking about the implementation of content-negotiation principle

Art Lowel [5:49 PM]
we just ask the handle endpoint for the self link

Andrea Bollini [5:50 PM]
it will be nice if one requesting an UI URL with format json will be redirected on the REST API

[5:50]
and viceversa... if you ask for a html representation of a REST API endpoint

Art Lowel [5:50 PM]
I don’t know if that will always be possible

[5:51]
even with embedded objects there will be UI pages that consist of a combination of multiple rest resources

Andrea Bollini [5:52 PM]
yes but we could imagine a mapping for the "main pages"... I guess

Art Lowel [5:52 PM]
we could

[5:52]
but I also like the idea of having something like the current hal browser, as the HTML version of the rest endpoints

[5:53]
I think it’s more useful if you’re trying to make some other app against our rest api

Andrea Bollini [5:53 PM]
it is not a html representation of the rest endpoint

[5:53]
it is only a client

[5:54]
useful for testing and documentation, but it doesn't provide html for rest endpoint (it is actually a javascript)

Art Lowel [5:54 PM]
I did say something like :wink:

[5:55]
what does e.g. spring-data-rest do if you ask a rest endpoint for html? (edited)

Andrea Bollini [5:55 PM]
nothing out-of-box

[5:56]
but my concerns come from the implementation of the signposting patterns for instance https://jira.duraspace.org/browse/DS-3589

[5:56]
where we should implement these kind of functionalities? in the UI or in the REST API?

Art Lowel [5:57 PM]
I’ll have to do some reading first, I hadn’t heard of that

Andrea Bollini [5:58 PM]
essentially it requires that when you serve an item page you add some HTTP header to link to specific content in the page

[5:58]
the URL of the author (on ORCID), the URL to download the bitstreams

[5:59]
it is useful to provide an easy path for harvester to access your repository without the need to parse the html

Art Lowel [5:59 PM]
So that’s quite similar to what we’re doing for google scholar then?

Andrea Bollini [5:59 PM]
yes but as HTTP Header insted of metatags

Art Lowel [5:59 PM]
I see

Andrea Bollini [6:00 PM]
but also google scholar is a good example of my concerns

[6:00]
where we should implement the functionality?

Art Lowel [6:00 PM]
I had also assumed that that would be the UI

Andrea Bollini [6:01 PM]
I have just realized that the UI is more than a view layer on top of the REST API

[6:02]
not necessary a bad thing... just it wasn't evident to me

Art Lowel [6:02 PM]
I think it could be, but then the Rest API would have to become very large and contain lots of redundant ways to show the same info, and I don’t think that would be a good thing

Andrea Bollini [6:04 PM]
ok... as said I just need to think on that from a different perspective but it is something that we should keep in mind. It will be useful to repost similar question on each feature that is "borderline"

Art Lowel [6:04 PM]
I agree

Andrea Bollini [6:05 PM]
ok, we are out our meeting time. Are there anything else that you want to discuss?

Art Lowel [6:05 PM]
not at the moment

Andrea Bollini [6:06 PM]
I guess that we can close the meeting. See all of you on hangout next week

Art Lowel [6:06 PM]
Bye