The Death of Server-Side Computing

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.

[Read More]

Implementing Thread-safe Access to the netCDF-C Library

This document proposes an architecture for implementing thread-safe access to the netcdf-c library. Here, the term "thread-safe" means that multiple threads can access the netcdf-c library safely (i.e. without interference or deadlock or race conditions). This does not mean that the library is itself multi-threaded. Rather, access to the library is serialized so that only one thread at a time is executing the library code.

[Read More]

Proposed Thredds Architecture Changes for OSGI/JigSaw

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

[Read More]

Plotting AWIPS Map Resources with Python

The python-awips package provides access to the entire AWIPS Maps Database for use in Python GIS applications. Map objects are returned as Shapely geometries (Polygon, Point, MultiLineString, etc.) and can be easily plotted by Matplotlib, Cartopy, MetPy, and other packages.

[Read More]

Unit Testing in the netCDF-c library using cmake

It appears to be the case that all current tests in the netcdf-c source tree are integration tests. That is they only access the library using calls to the externally visible API.

The DAP4 code testing is different in that it includes (for the first time) unit tests. These tests reference code that is considered internal to the library. For the library generated under autoconf, this is not a problem because those symbols are visible in the library: nothing is hidden.

[Read More]
Unidata Developer's Blog
A weblog about software development by Unidata developers*
Unidata Developer's Blog
A weblog about software development by Unidata developers*

Welcome

FAQs

News@Unidata blog

Take a poll!

What if we had an ongoing user poll in here?

Browse By Topic
Browse by Topic
« June 2017
SunMonTueWedThuFriSat
    
1
2
3
4
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
 
       
Today