I’m for alternative 1 thanks Martin

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Chief Architect
Instrument Software and Science Data Systems Section (398)
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 168-519, Mailstop: 168-527
Email: [email protected]
WWW:  http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Director, Information Retrieval and Data Science Group (IRDS)
Adjunct Associate Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
WWW: http://irds.usc.edu/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++










On 4/5/16, 12:34 PM, "Martin Desruisseaux" <[email protected]> 
wrote:

>Hello all
>
>With Johann working on the GPX format, a question is which (if any)
>naming convention to use for storage modules (i.e. modules that read and
>write some file formats). Currently there is none; the only stores are:
>
>Names alternative 1:
>  * sis-netcdf
>  * sis-shapefile
>
>We could prefix with "sis-store-" like below:
>
>Names alternative 2:
>  * sis-store-netcdf
>  * sis-store-shapefile
>
>We could also be more specific by separating the store in 3 categories:
>those reading features ("sis-feature-"), those reading coverages
>("sis-coverage-"), and those that get the data from a distant machine
>through web services ("sis-client-"):
>
>Names alternative 3:
>  * sis-coverage-netcdf
>  * sis-feature-shapefile
>
>However one issue with alternative 3 is that some formats does not fit
>entirely in any category. For example NetCDF can be used for both
>coverages and features.
>
>Alternatives 2 and 3 would impacts users of those modules since they
>would need to change their dependency in the pom.xml file.
>
>Does anyone has a preference for the module naming convention? (for now
>my own personal preference would be alternative 2, but I'm not sure)
>
>    Martin
>

Reply via email to