[thredds] TDS, edal-java, ncwms

• To: "thredds@xxxxxxxxxxxxxxxx" <thredds@xxxxxxxxxxxxxxxx>
• Subject: [thredds] TDS, edal-java, ncwms
• From: Adam Steer <Adam.Steer@xxxxxxxxxx>
• Date: Tue, 23 May 2017 05:34:34 +0000
• Authentication-results: unidata.ucar.edu; dkim=none (message not signed) header.d=none;unidata.ucar.edu; dmarc=none action=none header.from=anu.edu.au;
• Spamdiagnosticmetadata: NSPM
• Spamdiagnosticoutput: 1:99

Hi THREDDS people

I’m looking for a bit of future certainty/unpicking the relationship between 
TDS, ncWMS and edal-java. In particular, I need to know if:

a. TDS uses edal-java for it’s ncWMS handling
b. if so, is TDS using current versions of edal-java

Why? Because of the issue raised here: 
https://github.com/Reading-eScience-Centre/edal-java/issues/69

In short, we have user demand to serve both large, high resolution rasters that 
suit a scanline read mode, and other data which is happily handled in memory 
all at once. At present we use two slightly different TDS servers. Ideally we 
would reduce our management load a bit and serve both from a standardised TDS 
installation.

(realising that I also have a touch of homework to do on the edal-java issue 
listed above)

if there’s a way to clarify the pipeline between ncwms/edal-java changes and 
incorporation into TDS, it would be great to hear about it. I’m not a java 
developer by any stretch of the imagination, I dive into the TDS codebase and 
get thoroughly lost!

Thanks,

Adam

• Follow-Ups:
  • Re: [thredds] TDS, edal-java, ncwms
    • From: Sean Arms

• References:
  • [thredds] Hardware characteristics for Thredds server
    • From: David Gil
  • Re: [thredds] Hardware characteristics for Thredds server
    • From: Antonio S . Cofiño