You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sis.apache.org by Martin Desruisseaux <ma...@geomatys.fr> on 2013/06/06 16:49:19 UTC
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/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
Re: Base storage classes, and 2 open questions
Posted by Joe White <wh...@gmail.com>.
+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)" <ch...@jpl.nasa.gov> wrote:
> Hey Martin,
>
>
>
> -----Original Message-----
> From: Martin Desruisseaux <ma...@geomatys.fr>
> Organization: Geomatys
> Reply-To: "dev@sis.apache.org" <de...@sis.apache.org>
> Date: Thursday, June 6, 2013 7:49 AM
> To: Apache SIS <de...@sis.apache.org>
> 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: chris.a.mattmann@nasa.gov
> WWW: http://sunset.usc.edu/~mattmann/
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Adjunct Assistant Professor, Computer Science Department
> University of Southern California, Los Angeles, CA 90089 USA
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
>
>
Re: Base storage classes, and 2 open questions
Posted by Joe White <wh...@gmail.com>.
StorageConnector works for me…
Joe
On Jun 7, 2013, at 10:55 AM, Martin Desruisseaux <ma...@geomatys.fr> wrote:
> Le 07/06/13 16:35, Mattmann, Chris A (398J) a écrit :
>> Got it. Maybe: StorageConnector?
>
> I like that name :-). While wait a little bit for feedback, and if no-one object I will rename.
>
> Thanks for the suggestion
>
> Martin
>
Re: Base storage classes, and 2 open questions
Posted by Martin Desruisseaux <ma...@geomatys.fr>.
Le 07/06/13 16:35, Mattmann, Chris A (398J) a écrit :
> Got it. Maybe: StorageConnector?
I like that name :-). While wait a little bit for feedback, and if
no-one object I will rename.
Thanks for the suggestion
Martin
Re: Base storage classes, and 2 open questions
Posted by "Mattmann, Chris A (398J)" <ch...@jpl.nasa.gov>.
Hey Martin,
-----Original Message-----
From: Martin Desruisseaux <ma...@geomatys.fr>
Organization: Geomatys
Reply-To: "dev@sis.apache.org" <de...@sis.apache.org>
Date: Friday, June 7, 2013 6:07 AM
To: "dev@sis.apache.org" <de...@sis.apache.org>
Subject: Re: Base storage classes, and 2 open questions
>Hello Chris and Joe
>
>Le 07/06/13 03:17, Mattmann, Chris A (398J) a écrit :
>>> 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?)
>
>Actually it does not choose a DataStore (this work will be done later by
>an other class) - it just provides various way to connect to a specific
>storage (File, InputStream, database, etc.). The storage can also be a
>PostGIS or other database, in which case serializer/deserializer may not
>be accurate...
Got it. Maybe: StorageConnector?
>
>
>Le 07/06/13 13:35, Joe White a écrit :
>> Why not DataStoreProvider?
>
>We already have DataStoreProvider :-), as a factory for creating the
>actual DataStore instance after we found which one is appropriate.
>
>Thanks for the proposals
Cheers,
Chris
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattmann@nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Re: Base storage classes, and 2 open questions
Posted by Martin Desruisseaux <ma...@geomatys.fr>.
Hello Chris and Joe
Le 07/06/13 03:17, Mattmann, Chris A (398J) a écrit :
>> 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?)
Actually it does not choose a DataStore (this work will be done later by
an other class) - it just provides various way to connect to a specific
storage (File, InputStream, database, etc.). The storage can also be a
PostGIS or other database, in which case serializer/deserializer may not
be accurate...
Le 07/06/13 13:35, Joe White a écrit :
> Why not DataStoreProvider?
We already have DataStoreProvider :-), as a factory for creating the
actual DataStore instance after we found which one is appropriate.
Thanks for the proposals
Martin
Re: Base storage classes, and 2 open questions
Posted by "Mattmann, Chris A (398J)" <ch...@jpl.nasa.gov>.
Hey Martin,
-----Original Message-----
From: Martin Desruisseaux <ma...@geomatys.fr>
Organization: Geomatys
Reply-To: "dev@sis.apache.org" <de...@sis.apache.org>
Date: Thursday, June 6, 2013 7:49 AM
To: Apache SIS <de...@sis.apache.org>
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: chris.a.mattmann@nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++