1 (edited by clareblencowe 15-06-2021 15:02:16)

Topic: Recorder6 successor system – update on progress

Greetings Recorder6 users,

I know there’s a lot of interest in what the future holds for Recorder6, so here’s a quick update on where we’ve got to.

The Recorder6 Steering Group, using some of the funding from Recorder6 licence fee payments, has commissioned John van Breda (Biodiverse IT) to undertake a Feasibility Project, focused on development of a parallel / successor system to Recorder6. You can see the brief for the Feasibility Project here: https://nbn.org.uk/wp-content/uploads/2 … roject.pdf

Recorder6 Steering Group member Andy Foy, of Greenspace Information for Greater London, led on developing the brief for this work in collaboration with the Steering Group. (Thanks Andy and GiGL for the considerable time and thought that went into it!)

We’d be very interested to hear from Recorder6 users on the subject of developing a Recorder6 parallel / successor system. So do please read the brief and feel free to share thoughts, comments or relevant experience below.

John has already started reviewing potentially suitable programming languages and platforms. Most recently he’s been looking at Python as a language, with the Django framework, which looks promising. Is there anyone within our community who has experience with this, who might care to comment on Python’s suitability for this kind of project?

We’ll have to come up with a snappier name than “Recorder6 parallel / successor system” at some point, but still keeping our options open at this stage… (ideas welcome!)

If you’ve got any questions about the Feasibility Study, feel free to ask them here and we’ll do our best to respond. 

Clare Blencowe
On behalf of the Recorder 6 Steering Group

Clare Blencowe
Sussex Biodiversity Record Centre | Manager
Recorder 6 Steering Group | Chair

2

Re: Recorder6 successor system – update on progress

Adopting open source is a reasonable requirement, in contrast to keeping a proprietary Microsoft SQL Server database.

The Python programming language has become popular in recent years, so there should theoretically be a sizeable pool of people to maintain code. However, Python has what some programmers consider technical drawbacks, e.g. loose variable type definition and unconventional object orientation. That Python version 3 is incompatible with version 2 has caused problems and extra work. On the other hand, C, C++ or Java are more difficult and less popular languages.

There appears to be unrelated software called Recorder 7, so for the name, why not Recorder8 ?

3

Re: Recorder6 successor system – update on progress

Hi John, thanks for sharing your thoughts on this.

To answer your point about keeping a proprietary SQL Server database - we did discuss the merits of this among the Recorder 6 Steering Group and a key consideration was the nature of the Recorder 6 user base. Recorder 6 has a relatively large proportion of users who are based in local authorities and reliant on public sector IT departments for IT support and the consensus was that continuing with SQL Server was the most viable solution for them. We did discuss the possibility of going with an open source solution, e.g. PostgreSQL, but we thought it unlikely that public sector IT departments would all support it; and the two systems (SQL Server / PostgreSQL) are sufficiently different that we didn't think it would be feasible to develop a system that could work with both - we had to choose one or the other. So we chose SQLServer. As I understand it, there is a free version – SQL Server Express – which should work for small-scale users; so it shouldn’t be necessary for all users to get the paid-for SQL Server.

That's my non-technical understanding of the situation (not being a developer myself). I'm very open to being corrected if I've got any of that wrong.

Clare Blencowe
Sussex Biodiversity Record Centre | Manager
Recorder 6 Steering Group | Chair

4

Re: Recorder6 successor system – update on progress

Thanks for your feedback John. In my review, I did consider Python's typing an issue initially, but then found that the latest versions of Python do support type hints so we could well adopt that approach in the development. Also technically Python is technically a strictly typed language, not a loosely typed one, but the typing is dynamic rather than static. Looking at large projects developed on Python (of which there are lots) it seems that a robust set of unit tests reduces the chance of code-mess that a loose/dynamic typed language might otherwise allow.

In addition to Clare's comments above, the choice to keep the existing Microsoft SQL Server database also allows us to develop a useful partial replacement for Recorder 6 that can be used alongside the existing application. That makes the road-map a lot less onerous than having to commit to a complete replacement for all of Recorder 6's functionality, along with a data migration, before the new product can have any use. For example, I could imagine just developing a web-based reporting system for the existing Recorder 6 database as a really useful starting point. It would then be easier to evolve towards a complete product by adding new functionality as resources allow.

All the best
John

John van Breda
Biodiverse IT