I agree with both, they sound like good ideas.

Another idea is whether it is possible that part of any dictionary updates it then automatically rebuilds the indexes rather than the user having to do this manually each time, or at least to just have one button to rebuild all indexes in one go.

Brian

Now that broadband is pretty much everywhere, I don't see a 7MB download as too egregious. I believe Firefox downloads a large .exe every time it updates (although this might have changed).

As a stop-gap for a more integrated solution, something simple like an RSS feed (that could also be subscribed to via email) announcing updates would be handy. But I do agree, "automatic" updates for both the application and the dictionaries would be very nice, particularly for individuals and less experienced users.

OFF TOPIC: Charles, I notice your post count has dropped to 8. Just wondering.

Back on topic - a while ago we discussed with JNCC the possibility of changing the way that Recorder is built to use a bunch of external dlls (the Delphi package library for those interested), rather than to be built with all required code integrated in one exe. Unfortunately it didn't come out at top priority at the time. This change would open the doors to converting some other parts of the code into dlls which would reduce the size of the core executable file considerably.

Dave, you are correct in that Recorder.exe is just a splash screen which loads the RecorderApp.exe, done this way to make the splash screen appear quickly. It would indeed be possible to make this application check an online repository for updates and if one is available, give the option to download and apply the updates. However this facility would not be advisable for people without local machine admin rights so we would disable it for others.

Question for Sarah - as to the dictionary updates, is there any possibility you could embed the changes to the INDEX_TAXON... tables in the updates so that there is no need to do a manual update?

Hi

Dynamic updates would be great but not sure it is really cost effective to develop this- an RSS feed (as suggested by Charles) seems like sensible middle ground.

We would also be worried about the updates becoming too dynamic and particularly the idea of breaking into separate dlls. This may create more problems than it solves, particularly when you consider that some updates involve changes to the database too. The thought of unpicking problems where the dlls and database have diverged is a little frightening.

Ultimately cost is a major barrier to more frequent updates for two reasons:

- We have a limited budget every year, certainly not enough to have a full support contract with Dorset Software (where they would rapidly fix any bugs that appear). As a result we have to schedule the time when we fix them. The main risk with scheduling a number of releases within the year is that if we use money early in the year fixing non-critical bugs, by the end of the year there may not be enough to fix more critical problems.

- In addition, we currently carry out approximately 6 weeks of testing before rolling out a version. One option would be cutting this down but that again might cause more problems than it solves.

However, we're open to ideas on how to improve this situation bearing in mind the above.

Our strategy from here is to let this next version bed in a little and focus on fixing any bugs (rather than enhancements to functionality), which should mean that you see quicker resolutions for the critical bugs reported over the next year.

In terms of the dictionary, we’ll look into the possibility of including updates to the index_taxon tables within the scripts we provide.

Best wishes,