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/storage/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".
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).
Any opinion about "DataStore interface + AbstractDataStore abstract
class" versus "only DataStore abstract class"?
Martin
