+1 for the abstract class. I don't think I'm with Chris on his suggested name for the class, though. Why not DataStoreProvider?
Joe On Jun 6, 2013, at 9:17 PM, "Mattmann, Chris A (398J)" <[email protected]> wrote: > 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 > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > >
