Re: [netcdf-java] [thredds] Collection Specification

  • To: John Caron <caron@xxxxxxxxxxxxxxxx>
  • Subject: Re: [netcdf-java] [thredds] Collection Specification
  • From: James Gallagher <jhrg@xxxxxxx>
  • Date: Mon, 19 Dec 2011 13:43:04 -0700
On Dec 16, 2011, at 5:53 PM, John Caron wrote:

> On 12/16/2011 4:24 PM, Gallagher James wrote:
>> 
>> 
>> On Dec 16, 2011, at 3:21 PM, John Caron wrote:
>> 
>>> For the Collection Specification, Im thinking of using this when we start 
>>> using Java 7 (which will be in version 4.4):
>>> 
>>>    
>>> http://docs.oracle.com/javase/7/docs/api/java/nio/file/FileSystem.html#getPathMatcher(java.lang.String)
>>> 
>>> Comments on this decision would be welcome.
>> 
>> Question: Is this part of the aggregation work that you doing that will not 
>> use ncml?
> yes, at least it does not use NcML right now.

What was the reason for the non-ncml design?

> 
>> 
>> Comment: I really like these kinds of things in Java (e.g., their Date 
>> stuff) but for other languages they can be a pain. One way you can simplify 
>> implementations in other languages is to specify which parts you're actually 
>> going to use. Languages like C++ and Python can do this stuff - there's 
>> almost always a library out there - but it's nice to know how much users 
>> will need.
> 
> i agree. but the getPathMatcher() seems to have a clear spec, and at least it 
> would be a clear reference implementation if it had to be ported. However, I 
> need to study it closer.

What I'm thinking about is not so much that specs are not clear, but that they 
cover a wide spectrum of cases while our uses are (often) more focused. Without 
knowing the actual design's boundaries, it's hard to gauge what we really need 
to either build or grab from the net. I try to have little 'unused' code 
lurking in our server; our (in)famous security breech was enabled by unused 
features of the curl executable. While that case is not _exactly_ the same as 
having extra code in a library, it does illustrate that there is a cost 
associated with 'extra' code.

James

> 
> john
> 
> _______________________________________________
> netcdf-java mailing list
> netcdf-java@xxxxxxxxxxxxxxxx
> For list information or to unsubscribe, visit: 
> http://www.unidata.ucar.edu/mailing_lists/

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

  • 2011 messages navigation, sorted by:
    1. Thread
    2. Subject
    3. Author
    4. Date
    5. ↑ Table Of Contents
  • Search the netcdf-java archives: