Page tree
Skip to end of metadata
Go to start of metadata


Angular meeting



Slack Logs (times are all CEST)

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

A few updates:

@wwelling added integration with Travis CI and Github.

Github will now make it clear if a PR breaks any tests.

@wwelling also has a PR that refactors the config to make use of OpaqueTokens:

The angular team recommends doing it that way, as it allows the GlobalConfig object to be injected.

This, among other things, makes it easier to mock config settings during tests.

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

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]

yes i can review it

Art Lowel [5:04 PM]
Thank you

Continuing: I've been working on handling relationships in the rest services.

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.

No PR yet

Angular 4 was released last Thursday. You can find an overview of what's new here:
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...

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

You can find a blogpost with a detailed explanation about the change here:
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)

The step between Angular 2 and 4 is a lot smaller than the step between 1 and 2.

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

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.

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.

I've created an issue about the upgrade:

@wwelling has started to list the things that we'll need to change in the issue.

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

ngrx and ng-bootstrap are the most notable

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.

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:

@wwelling noted that we made a lot of changes to universal-starter and suggested we look at this project instead:

However that project still comes across like a work in progress to me

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

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

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

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

Any help with that it would be appreciated.

Those were all the updates I had

Does anybody have any questions?

Matteo Perelli [5:11 PM]
so we take a look at 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

ok, I agree with you

Art Lowel [5:11 PM]

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

Art Lowel [5:12 PM]

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

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

as collections are paginated you can have the page 0 exposed with different self link

Art Lowel [5:15 PM]
I see

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

e.g. both `/bitstreams/5123` as well as `/items/8455/bitstreams/5123`

where the second link would appear in the _links section of an item for example

Andrea Bollini [5:17 PM]

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?

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

(the index allows you to find a UUID based on a self link)


For embedded resources I’m using the example in the hal-comparison repo

is that still accurate?


Andrea Bollini [5:21 PM]
yes it is

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

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]

Rest meeting



Slack Logs (times are all CEST)

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

Terry Brady [5:31 PM]

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

we have now some additional skeleton on the REST contract but we lack of contribution


@terrywbrady have proposed to move the repository under DSpace instead of DSapce-labs

this could help to get more attention

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

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

anyway, we can wait a few weeks and check when more people is in the meeting

on the rest contract we have two initial draft



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

(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

and as @terrywbrady says we also have a issue ticket to test the spring rest doc framework

that could bring in some autogenerated snipped and details


moving back to our rest contract draf pages

the first one
is also related to a PR


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


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?

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

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.

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

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]

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

Andrea Bollini [5:49 PM]
SOLR search ->

this is one of the issue that I like to ask for a volunteer

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

we only need to return the same json representation for an item

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

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

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

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 ... 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

I have only found a little bug to fix

Terry Brady [6:00 PM]

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

Mark Wood [6:01 PM]

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



in the PR we have some good conversation

I like to hear other about which approach we want to try to implement

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

ok, we will meet again next week. I will be not present as I will attend the duraspace summit

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]

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

Mark Wood [6:07 PM]