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.

This post provides some preliminary ideas on the consequences of moving TDS to use OSGI or JigSaw.

The Thredds Data server (TDS) was designed to operate in a client-server architecture. Recently, Unidata has moved TDS into the cloud using its existing architecture.

There seems to be agreement inside Unidata that we need to begin rethinking that architecture to adapt to the realities of the cloud.

For version 5.0.0, it is possible to configure TDS to support the uploading and downloading of files into the local file system using the "/thredds/download" url path. This is primarily intended to support local File materialization for server-side computing. The idea is that a component such asJupyter can materialize files from TDS to make them available to code being run in Jupyter. Additionally, any final output from the code execution can be uploaded to a specific location in the TDS catalog to make it available externally.