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
|