NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
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) <http://docs.oracle.com/javase/7/docs/api/java/nio/file/FileSystem.html#getPathMatcher%28java.lang.String%29>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.
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.
john
thredds archives: