Hey Martin,
-----Original Message----- From: Martin Desruisseaux <[email protected]> Organization: Geomatys Reply-To: "[email protected]" <[email protected]> Date: Thursday, June 6, 2013 7:49 AM To: Apache SIS <[email protected]> Subject: Base storage classes, and 2 open questions >Hello all > >The org.apache.sis.storage package now contains some classes proposed as >the basis of all SIS storage objects. The NetcdfStore implementation is >ready for testing purpose, ShapefileStore would tentatively be >refactored later if peoples agree. > >https://builds.apache.org/job/sis-trunk/site/apidocs/org/apache/sis/storag >e/package-summary.html > >DataStore is the main interface. For now its only useful method is >'getMetadata()', together with a pair of methods for adding/removing >warning listeners. > >Different DataStore implementations will want different kind of >input/output objects: File, URL, InputStream, ReadableChannel, >datastore-specific object (e.g. ucar.nc2.NetcdfFile), JDBC Connection, >etc. The problem is that we don't know which kind of object to accept >before we find which DataStore implementation to use. For this reason, >an arbitrary java.lang.Object is encapsulated in DataStoreConnection, >which tries to open the object in various ways (as ImageInputStream, as >ByteBuffer, etc.) depending on DataStore needs. Future versions may >contain additional information like login/password. This >DataStoreConnection is used only for the "discovery" phase, and >discarded once the actual DataStore has been created. > >The two open questions are: > >1) Does anyone has a better idea for a "DataStoreConnection" class name? >The idea is "Provides various ways to open an arbitrary Object until we >have found which DataStore can decode the bytes provided by that Object". What about DataSerDeChooser (for "data serializer/deserializer" chooser?) > >2) For now, DataStore is an interface and AbstractDataStore provides a >skeleton implementation. However I'm tempted to simplify by providing >only a DataStore abstract class, without interface. The rational are: > > * Looking at Geotk code, I didn't found a class not extending > AbstractDataStore in practice. > * Abstract classes are a little bit easier than interfaces to make > evolve without breaking code. > * Forcing all implementations to extend a simple class opens some > opportunities for some internal mechanics shared by everyone. > * Interfaces are usually either for transversal aspects (Comparable, > Cloneable, Serializable, basically anything ending with "able"), for > standard API to be implemented by different vendors (JDBC, > tentatively GeoAPI), or for services to be implemented by reflection > (RMI). They don't seem to be the DataStore case. > * It would be a slight simplification of SIS API (one less type). +1 to use an abstract class. > > >Any opinion about "DataStore interface + AbstractDataStore abstract >class" versus "only DataStore abstract class"? Only DataStore abstract class :) Cheers, Chris ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: [email protected] WWW: http://sunset.usc.edu/~mattmann/ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
