Unidata is looking for community contributions to the Jupyter Notebook service, which provides Jupyter Notebooks to facilitate accessing, exploring, and visualizing datasets in the TDS. Users who have written Notebooks that interface with TDS datasets (or Python scripts that can be converted) or are interested in creating one can contribute in one of two ways (or both!):

1. Contribute a generic viewer that would be a useful in a typical THREDDS Data server (see the GitHub issue here).
2. Contribute a viewer for a specific dataset, data type, or catalog included in the Unidata THREDDS Data Server (see GitHub issue here).

The issues above are eligible for Hacktoberfest: you get Hacktoberfest credit and help the Unidata community! For more information on contributing and some helpful links, visit the GitHub issues above.

Happy hacking!

Hailey Johnson

by Hailey Johnson
2018 Unidata summer intern

During my time here at Unidata, I’ve focused on extending the THREDDS Data Server (TDS) web interface and services. I spend the first few weeks of the summer redesigning the interface to be more intuitive to end users and implementing UI changes using Thymeleaf HTML templating. The new TDS catalog pages are designed with a “plug-and-play” structure, allowing users to override or insert their own contributed HTML, which is processed by a server-side Thymeleaf template resolver.

As we approach the first public beta of version 5.0 of the THREDDS Data Server (TDS), we have decided to revisit our software license. Currently, both NetCDF-Java and the TDS are released under the same license that the netCDF C library uses, which is a license that was "home grown" at UCAR. It's usually called an "MIT-style license," though it is perhaps more similar to the BSD-3 Clause license. Rather than continue to use the "home grown" license, we will be moving to a standard, off-the-shelf BSD-3 license, bringing the TDS and NetCDF-Java packages more in line with standard practice within the Open Source community.

Periodically some of the Thredds servers run by Unidata get seriously overloaded. One cause is because external users poll the Thredds server to see what has changed. If the polling rate is too high then the performance of the Thredds server can seriously deteriorate.

I am proposing here to mitigate this problem by allowing Thredds servers to generate events that signal changes that might be of interest to users. Then, instead of polling, these users can watch for specific changes events and use that information to update their local databases (or whatever).

For a number of years, the Unidata Thredds group has been in the process of "implementing" server-side computation Real-Soon-Now (as the saying goes).

Events have overtaken the previous notion of server-side computing and here we try to codify a replacement that uses a separate server model based on Jupyter (an offshoot of IPython).

From the point of view of Unidata, Jupyter provides a powerful alternative to roll-your-own server-side computing. It supports multiple, "real" programming languages. It is a server itself, so it can be co-located with an existing Thredds server. And, most importantly, it is designed to execute small programs written in any of its supported languages.

We are proposing to implement server-side computing for Thredds by using one or more co-located Jupyter servers. This document elaborates on the capabilities and required support infrastructure to make this proposal operational.