<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
</div>
<div class="elementToProof"><span>Hi,</span></div>
<div><br>
</div>
<div>During the spring semester, we spent a lot of effort on improving the Noark 5 API spec. Right before the summer, we launched a 1.1 version of the specification. That work was very enjoyable, and it highlighted the importance of getting nikita up to speed
with the specification. </div>
<div><br>
</div>
<div class="elementToProof">Working on the nikita implementation to ensure we can be seen as a reference implementation is something I want to get into. There is not that much left to do for nikita to be a reference implementation, but I think the work is nitty-gritty
work that is time-consuming. I have also been thinking about what nikita needs going forward, and there is scope for some work to be done on the codebase. The most pressing task so far has been to get nikita up to Spring boot 3. We had some issues with the
hibernate descriptions (inheritance) that was preventing us from being a<span> </span><span style="display:inline">Spring boot 3</span><span> </span>application. These issues (expectedly) went away with the 3.1.1 version of<span> </span><span style="display:inline">Spring
boot </span>so we are good to go.</div>
<div><br>
</div>
<div>Spring security in Spring boot 3 is updated and forces us to rethink our implementation of security. I think we were due a revisit of this topic anyway, so it was coming, but we were forced to deal with it in the <span style="display:inline">Spring boot
3 upgrade branch. We are moving to using keycloak as an SSO service for nikita. I think that is fine for anyone that wants to run nikita as a web-based service, but we see the scope and need for nikita to be able to run as a stand-alone system for an individual
that want to be in control of their own record-keeping. I am not happy with the keycloak requirement and will look closer at how we can also run nikita without keycloak.</span></div>
<div><span style="display:inline"><br>
</span></div>
<div><span style="display:inline">Looking at these issues makes me want to refactor the codebase a bit. I think the codebase is overly complex and could be tidied to make it easier for anyone else wanting to explore/understand the codebase. I'd guess there
are some redundant classes and code in there now as well.</span></div>
<div><span style="display:inline"><br>
</span></div>
<div>Going forward, I think we need to revisit the concept of DTO (data transfer object) that can give more control on what is returned to a client. We do not really have screening implemented properly in nikita. But to get that done properly, we likely need
to have a better understanding of roles. In general, the concept of screening deserves its own research project to explore and understand what it entails.</div>
<div><br>
</div>
<div>I also think the import issue really should be dealt with. Being able to import data preserving the original systemID and timestamps is important. It is more a limitation of Noark rather than nikita, but just, in general, lacks being explored.</div>
<div><br>
</div>
<div>As always, your opinions and thoughts are welcome on #nikita on oftc. </div>
<div><br>
</div>
<div>Thomas</div>
<span></span>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof ContentPasted3">
<br>
</div>
</body>
</html>