There was a lot of testing going on in the last 2 months, and I forgot all about writing blog entries.

The first stage of testing was to go through the Greenstone tutorials on Windows (Vista), Linux (Ubuntu) and Mac (Leopard). Some bugs were discovered and fixed, and after that RC1 of GS2.85 could be released.

Thereafter, further tests were conducted on all three OS: testing out combinations of the 3 indexers and 3 database types, processing of a range of file types including the use of Greenstone’s PDFBox and OpenOffice extensions, filenames with different encodings and HTML files that interlink with each other using different encodings, the remote Greenstone server and the GLI applet were tested out, as well as spaces in the filepath for Windows. This time, the tests were conducted on Windows XP, Linux CentOS as well as Mac Leopard again. A lot of bugs had still got through the net after the first stage of testing, but were caught this time around and fixed for the release of GS2.85 RC2.

Greenstone 2.85 RC2 was finally released on Wednesday 26 October 2011. The Greenstone Team invites all those interested to please test the new release binaries out, which can be obtained from http://www.greenstone.org/snapshots, and write back on any bugs or issues encountered. The updated release notes are at http://wiki.greenstone.org/wiki/index.php/2.85_Release_Notes

The release notes already contain instructions on a patch for a minor issue that Diego discovered in the earlier release and which had persisted into the current one.

Progress on the Document Structure Editor (the name is still undecided) is going well. It now actually makes the changes and then builds the collection, which results in the changes actually showing up in the documents, which is quite satisfying to see!

The building process takes a reasonable amount of time (especially if multiple collections need to be built) so we needed a way to inform the user of what is currently happening on the server. We originally had the code to trigger the collection building on the server, as it made sense to build the collections straight after the archive files had been modified (which is essentially what this system does). This approach hit a road-block however as it has difficulty if multiple collections are to be built sequentially and we want to be able to inform the user of what’s happening on the web interface. Basically once each build is complete the collection must be activated (the building -> index step you may know about if you’ve ever build a collection using the command line rather than GLI) and these things became very tricky to order correctly without requiring a lot more code. So we decided to make the process simpler and move the code that decides when and what collections to build to the client-side.

This week I will be continuing to work on this system, most likely focusing on editing metadata or document text.

This week work has continued on the Document Basket/Document Maker/Document Structure Editor (we’re still deciding on the final name). The move and duplicate operations have been implemented and are successfully being mirrored on the server, so it is now very easy to move sections around and duplicate them. Unfortunately these changes do not yet show up in the regular interface as the collection will need to be built after each save and this has yet to be implemented.

I have also been able to get the undo functionality up and running. So now you will be able to undo all your operations up until the point where you choose to save. The client-side interface keeps a list of all the transactions you have made (moves, duplicate, create, delete etc.) and is able to undo any operations you make on the client by removing them from the list of transactions (and updating the interface), once you choose to save however the list of transactions is sent to the server to be executed so undoing is no longer as simple to implement. It may be implemented some time in the future but at this stage it would take more time than we can spare for something that is not essential.

We have also begun implementing a way to modify metadata (such as document/section title, author or subject metadata) as part of the system. Allowing a way to modify metadata more directly instead of having to use GLI, which collection designers may find quite useful. At the moment it is only working on the client-side and we have yet to connect it back to the server.

Next week I will continue to connect the missing operations to the server and add collection building as part of the save feature so the changes can be viewed.

Those who are eagerly awaiting the release of the final version of 2.85 will not have to wait much longer. Anu has been working hard testing it on each of the platforms we support and for the most part things are looking good. Any assistance in testing is always greatly appreciated and if you would like to help us out then please download the 2.85 release candidate which is available here. If you find any problems then join the mailing list to email us at <greenstone-users @ list.waikato.ac.nz> and let us know. The more you can tell us about the issue the better.

Work on the Document Basket functionality continues to go well. I am in the initial stages of connecting the front-end Javascript to the Java back-end. To transmit the operations we are using JSON (rather than XML) as it is a very simple to write in Javascript and we have found a good Java library (gson) that converts JSON back into an object. So hopefully this week we will start seeing some promising results.