Date

Angular meeting

Attendees

Notes

Art Lowel [5:00 PM]
@here: Alright, let's get started.

[5:00]
A few updates:

[5:00]
@wwelling added integration with Travis CI and Github.

[5:01]
Github will now make it clear if a PR breaks any tests.

[5:01]
@wwelling also has a PR that refactors the config to make use of OpaqueTokens: https://github.com/DSpace/dspace-angular/pull/82

[5:01]
The angular team recommends doing it that way, as it allows the GlobalConfig object to be injected.

[5:01]
This, among other things, makes it easier to mock config settings during tests.

[5:01]
I've reviewed this PR and it looks good. Can we get one more person to review it?

[5:01]
perhaps @atarix83, as I believe he wrote the original config.

Matteo Perelli [5:02 PM]
Hello everyone


Art Lowel [5:02 PM]
No takers?

Giuseppe Digilio [5:03 PM]
hi

[5:04]
yes i can review it


Art Lowel [5:04 PM]
Thank you


[5:04]
Continuing: I've been working on handling relationships in the rest services.

[5:04]
To ensure that related resources and embedded resources are all stored only once in the ngrx store, and that all other references to them use that same copy.

[5:04]
No PR yet

[5:05]
Angular 4 was released last Thursday. You can find an overview of what's new here: http://angularjs.blogspot.be/2017/03/angular-400-now-available.html
angularjs.blogspot.be
Angular 4.0.0 Now Available
Angular version 4.0.0 - invisible-makeover - is now available. This is a major release following our announced adoption of Semantic Ver...

[5:05]
It may be called Angular 4, but there never was an Angular 3. The convention for version numbers has changed.

[5:05]
You can find a blogpost with a detailed explanation about the change here: http://angularjs.blogspot.be/2016/12/ok-let-me-explain-its-going-to-be.html
angularjs.blogspot.be
Ok... let me explain: it's going to be Angular 4.0, or just Angular
This is a guest blog post by Juri Strumpflohner. Juri is a full-stack developer, architect and tech lead with a passion for frontend develop... (27KB)

[5:05]
The step between Angular 2 and 4 is a lot smaller than the step between 1 and 2.

[5:05]
However, for us there is an important breaking change: Angular Universal has moved from a standalone project in to the core.

[5:06]
So the universal packages are no longer necessary, a lot of universal-related things have been renamed or work slightly differently, and so the modules that bootstrap the app on the browser and in node will have major changes, as well as the express server that runs the server-side.

[5:06]
There will also be changes to the dspace specific code in the project, but those should mostly be things a find-and-replace can fix.

[5:06]
I've created an issue about the upgrade: https://github.com/DSpace/dspace-angular/issues/83

[5:06]
@wwelling has started to list the things that we'll need to change in the issue.

[5:06]
I did some tests and I found a few of the libraries we're using don't have a compatible version yet.

[5:06]
ngrx and ng-bootstrap are the most notable

[5:07]
It's possible that they still work, and simply produce warnings during build, but until they've released compatible versions, I'd rather not upgrade our master branch.


[5:07]
The universal-starter project (which is the project we started from) also doesn't have an up to date version yet, but there is an open issue: https://github.com/angular/universal-starter/issues/376

[5:07]
@wwelling noted that we made a lot of changes to universal-starter and suggested we look at this project instead: https://github.com/FrozenPandaz/ng-universal-demo

[5:07]
However that project still comes across like a work in progress to me

[5:07]
for example, the new view engine for express is part of the source, while that used to be a standalone package for angular 2.

[5:08]
I think an express engine for angular 4 will likely appear as a separate package again. (when universal-starter gets upgraded maybe?)

[5:08]
As the update will be a considerable amount of work, I'd prefer not to rush it, but wait a while for things to settle, to ensure we don't have to do half of it again a few weeks later


[5:08]
In any case it's a good idea to gather as much information as possible about the upgrade in the github issue

[5:09]
Any help with that it would be appreciated.

[5:10]
Those were all the updates I had

[5:10]
Does anybody have any questions?

Matteo Perelli [5:11 PM]
so we take a look at https://github.com/FrozenPandaz/ng-universal-demo but for now we stay still

Art Lowel [5:11 PM]
That’s what I suggest yes

Matteo Perelli [5:11 PM]
We gather information for now

[5:11]
ok, I agree with you

Art Lowel [5:11 PM]
great

Matteo Perelli [5:12 PM]
hopefully the situation will be more "stable" in a short time

Art Lowel [5:12 PM]
indeed

Matteo Perelli [5:12 PM]
thanks for the updates anyway

Art Lowel [5:13 PM]
I do have a question for @bollini or someone from the rest team, to help with the relations in the rest services


[5:13]
will a resource always have the exact same self link? (no matter how you got it)

Andrea Bollini [5:14 PM]
yes, it could be different for collections of resources

[5:14]
as collections are paginated you can have the page 0 exposed with different self link

Art Lowel [5:15 PM]
I see

[5:15]
and is it possible to have two different links to the same (single) resource, in the _links section of a related resource?

[5:16]
e.g. both `/bitstreams/5123` as well as `/items/8455/bitstreams/5123`

[5:16]
where the second link would appear in the _links section of an item for example

Andrea Bollini [5:17 PM]
no

[5:17]
you should alway have /bitstreams/5123

Art Lowel [5:17 PM]
so that self link, is in practice, a kind of identifier for the resource?

[5:18]
I’m currently creating an self-link index, because objects are stored by uuid in our redux store

Andrea Bollini [5:18 PM]
yes, this is my understanding and this is way I propose to avoid to include the uuid as an attribute

Art Lowel [5:18 PM]
but it could be worth storing them by self-link instead, and leaving out the additional step of the index


[5:19]
(the index allows you to find a UUID based on a self link)

[5:19]
Thanks

[5:20]
For embedded resources I’m using the example in the hal-comparison repo

[5:20]
is that still accurate?

[5:21]
https://github.com/DSpace-Labs/hal-jsonapi-comparison/blob/master/hal/generated/bitstreams.json#L36

Andrea Bollini [5:21 PM]
yes it is


Art Lowel [5:22 PM]
Does anybody else have something they’d like to discuss?

[5:24]
In that case I’ll see you next time, or in the rest meeting in a few minutes

Matteo Perelli [5:24 PM]
thanks Art, see you soon

Giuseppe Digilio [5:24 PM]
thanks, bye

Art Lowel [5:24 PM]
bye

Rest meeting

Attendees

Notes

Andrea Bollini [5:30 PM]
@here this is the bi-weekly slack update meeting for the REST API

Terry Brady [5:31 PM]
Hello

Andrea Bollini [5:31 PM]
since our hangout call we have done some progress merging the PR that was approved

[5:31]
we have now some additional skeleton on the REST contract but we lack of contribution

[5:31]
https://github.com/DSpace-Labs/Rest7Contract

[5:32]
@terrywbrady have proposed to move the repository under DSpace instead of DSapce-labs

[5:32]
this could help to get more attention

[5:33]
how many people are around?


Terry Brady [5:34 PM]
It would allow us to keep code and documentation in sync by merging in a single PR... of course it could also entangle code and documentation changes.

Andrea Bollini [5:34 PM]
oh so you mean to have the contract in the DSpace/DSpace repository ?

Terry Brady [5:35 PM]
Yes. In the code directory.

Andrea Bollini [5:35 PM]
I'm not convinced that it is the right approach

[5:35]
we are still unsure about the final form that our rest contract needs to have

Terry Brady [5:36 PM]
OK. I am fine to leave it where it is

Andrea Bollini [5:36 PM]
I'm just proposing to promote the rest7contract from a repository in DSpace-Labs to a repository in DSpace

[5:37]
anyway, we can wait a few weeks and check when more people is in the meeting

[5:37]
on the rest contract we have two initial draft

[5:38]
https://github.com/DSpace-Labs/Rest7Contract/blob/master/search-rels.md

[5:38]
https://github.com/DSpace-Labs/Rest7Contract/blob/master/projections.md

Mark Wood [5:38 PM]
Ultimately the contract should go into the documentation, not the code. So a separate DSpace/Rest7Contract makes sense to me.

Terry Brady [5:38 PM]
Or it should be generated ultimately


[5:39]
(from code)

Andrea Bollini [5:39 PM]
yes, just for the archive... I have started to play a bit with rst for docuemntation for another project and it could be an option

[5:39]
and as @terrywbrady says we also have a issue ticket to test the spring rest doc framework

[5:40]
that could bring in some autogenerated snipped and details

[5:40]
https://jira.duraspace.org/browse/DS-3484

[5:40]
moving back to our rest contract draf pages

[5:41]
the first one
https://github.com/DSpace-Labs/Rest7Contract/blob/master/search-rels.md
is also related to a PR

[5:41]
https://github.com/DSpace/DSpace/pull/1686

[5:41]
I have just added few comments to it

Terry Brady [5:41 PM]
I closed this one in favor of the one with the projection

[5:41]
https://github.com/DSpace/DSpace/pull/1688

Andrea Bollini [5:42 PM]
we should keep them separate to speed up inclusion

Terry Brady [5:43 PM]
OK. I will re-open 1686

Andrea Bollini [5:43 PM]
do you have time to work on the search-rel issue? in the next week?

[5:44]
if so, I will spent some time today or tomorrow at late to provide you direction from the spring-data-rest project

[5:45]
or do you prefer to work on the projection issue?

Terry Brady [5:45 PM]
I can spend more time this week. I need some guidance on what else is needed immediately for this PR. I created a stub of the annotation.

[5:46]
Either is good for me, but I need some more details of your direction. I have been working to keep the PR's small and focused.

Andrea Bollini [5:47 PM]
my suggestion is to implement the search endpoint in a generic way so that we can fastly add new query for any objects

[5:47]
ok we can discuss further the details at the end of this meeting and on the PR

Terry Brady [5:48 PM]
SOLR search is different from an object specific search like top communities...

Andrea Bollini [5:48 PM]
yes

Terry Brady [5:48 PM]
Moving the discussion to the PR makes sense

Andrea Bollini [5:49 PM]
SOLR search -> https://jira.duraspace.org/browse/DS-3489

[5:49]
this is one of the issue that I like to ask for a volunteer

[5:50]
I think that we should start to figure out how our discovery-search and browse endpoints will work and how the returned objects are structured


Mark Wood [5:50 PM]
The ticket looks like we have a volunteer but he wants some guidance to start.

Andrea Bollini [5:51 PM]
we already have agreed with the #angular-ui team that we want to return the same object whetever strategy we use (solr or db)

Terry Brady [5:52 PM]
Is that feasible? Will that perform properly?

Andrea Bollini [5:52 PM]
but we will probably need a wrapper that add to our object additional information specific of SOLR (like the score, highlighting, etc)

Terry Brady [5:52 PM]
If we need to visit the database for every SOLR hit, the response could be slow

Andrea Bollini [5:53 PM]
no we don't need to do s

[5:53]
we only need to return the same json representation for an item


[5:53]
in both case, if retrieved from solr or from the db

Terry Brady [5:53 PM]
A useful thing to note in the contract documentation


Art Lowel [5:54 PM]
If certain fields are missing, because it came from solr, instead of the db that isn’t a big problem

Andrea Bollini [5:54 PM]
exactly, and this is more true if we wrap our object in a new entity

[5:54]
solrresultobject that have a dspaceojbect inside

Terry Brady [5:55 PM]
The metadata population will be interesting to see since it will be readily available from solr.

Andrea Bollini [5:55 PM]
this because the hal specification say that if you embed an object you are not required to return the full object

Terry Brady [5:56 PM]
As we think about projections, some projections could be satisfied by either method of population

Andrea Bollini [5:57 PM]
this is interesting ... and complex

Terry Brady [5:57 PM]
If you find a volunteer for this task, I would be happy to brainstorm methods with the person

[5:57]
It will be good to get some form of solr interaction working

Andrea Bollini [5:58 PM]
we can start drafting the endpoint and the wrapper object in the rest contract

[5:59]
once we have decided the endpoint an initial implementation should be enough fast, I can make it in the 2nd-3rd week of April

Terry Brady [5:59 PM]
Before we close, could we get a resolution on https://github.com/DSpace/DSpace/pull/1680 ... it is not that significant, but I would prefer to see it either merged or closed.

Andrea Bollini [6:00 PM]
I think it is ok to merge

[6:00]
I have only found a little bug to fix

Terry Brady [6:00 PM]
thanks

Andrea Bollini [6:01 PM]
once it is fixed I will merge

Mark Wood [6:01 PM]
Good

Andrea Bollini [6:01 PM]
we hit the end of the meeting

Terry Brady [6:01 PM]
I assume you will add a review comment (or a commit)

Andrea Bollini [6:01 PM]
but I want to highlight that the work on the projection is started

[6:01]
https://github.com/DSpace-Labs/Rest7Contract/blob/master/projections.md

[6:02]
https://github.com/DSpace/DSpace/pull/1688

[6:02]
in the PR we have some good conversation


[6:02]
I like to hear other about which approach we want to try to implement

[6:03]
any other aspects that we want to discuss as part of the meeting (we are over time)? (edited)

[6:05]
ok, we will meet again next week. I will be not present as I will attend the duraspace summit

[6:05]
anyone want to lead the rest api discussion to provide an update?

Terry Brady [6:05 PM]
I can

Andrea Bollini [6:06 PM]
ok, see you all next time

Art Lowel [6:06 PM]
bye

Terry Brady [6:07 PM]
Have a good week

Mark Wood [6:07 PM]
'bye