[Geoserver-devel] GSIP 34, call for vote

Justin_Deoliveira · March 17, 2009, 7:17pm

Hi all,

I would like to call for a vote on GSIP 34:

http://geoserver.org/display/GEOS/GSIP+34+-+New+data+directory+structure+for+2.x

Most feedback as been incorporated but the proposal of adding the idea of maps into the picture has not been incorporated for now. The reasons why being:

1) It increases scope in the short term without a lot of gain. Since the the upgrade to including maps into the picture is strictly additive to the data directory structure, it won't be an issue to add it later. Implementing maps in the short term, even just creating the idea of a default map is not trivial, and adds a pretty big hurdle.

2) Andrea pointed out that the data publishing split with regard to maps has not totally been fleshed out at this point. And indeed there is some thoughts about using a thread local view of the catalog as an alternative. So adding in maps to the structure now could indeed be a crutch come later.

So that is the rationale for leaving it out of the picture for now. Those who stand by the feedback still can vote -1.

So with that said, let the voting begin.

-Justin

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

jive · March 17, 2009, 11:40pm

Thanks for the nice clear presentation - I am happy to vote +1.

I would consider:
global.xml
service/wfs.xml
service/wms.xml
service/wcs.xml
service/wps.xml

But it does not make much of a difference.

Jody

On Wed, Mar 18, 2009 at 6:17 AM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Hi all,

I would like to call for a vote on GSIP 34:

http://geoserver.org/display/GEOS/GSIP+34+-+New+data+directory+structure+for+2.x

Most feedback as been incorporated but the proposal of adding the idea
of maps into the picture has not been incorporated for now. The reasons
why being:

1) It increases scope in the short term without a lot of gain. Since the
the upgrade to including maps into the picture is strictly additive to
the data directory structure, it won't be an issue to add it later.
Implementing maps in the short term, even just creating the idea of a
default map is not trivial, and adds a pretty big hurdle.

2) Andrea pointed out that the data publishing split with regard to maps
has not totally been fleshed out at this point. And indeed there is some
thoughts about using a thread local view of the catalog as an
alternative. So adding in maps to the structure now could indeed be a
crutch come later.

So that is the rationale for leaving it out of the picture for now.
Those who stand by the feedback still can vote -1.

So with that said, let the voting begin.

-Justin

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Rob_Atkinson1 · March 18, 2009, 12:04am

Hi

I'm just consulting my team on this - but I'd make two comments

1) agree with Jody - if services are "plugged in", having hard coded
top level file names for config seems wrong. Can we change this to a
more explicit

services/<unique service plugin name>.xml

so that it can be extended without further negotiated change to the
formal structure?

2) We are still burying database connections deep, and not re-using
them. I'd like database connections and other local configuration to
be normalised and re-used.

can we have a top level directory connections/ or authorisations/

This is a real issue when we distribute a re-usable Geoserver
configuration via version control - with multiple geoservers
delivering common stuff - INSPIRE for example would require this.
There may be an element of local mapping - but we actually found that
was often encapsulated in database views and it was only multiple,
buried, not-separately-testable database connections that needed
configuring.

3) It is important that namespaces be "augmented" by explicit
declaration - the general case is that the target configuration
exposes a namespace as part of a contract between the service and the
world of clients. It should be possible to "make this up" during
FeatureType configuration, or use one extracted from the definition of
the FeatureType (the application schema case). Its not clear to me if
this is an issue - probably an implementation issue, not a directory
structure issue

Sorry to provide feedback so late.

Rob Atkinson

On Wed, Mar 18, 2009 at 10:40 AM, Jody Garnett <jody.garnett@anonymised.com> wrote:

Thanks for the nice clear presentation - I am happy to vote +1.

I would consider:
global.xml
service/wfs.xml
service/wms.xml
service/wcs.xml
service/wps.xml

But it does not make much of a difference.

Jody

On Wed, Mar 18, 2009 at 6:17 AM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Hi all,

I would like to call for a vote on GSIP 34:

http://geoserver.org/display/GEOS/GSIP+34+-+New+data+directory+structure+for+2.x

Most feedback as been incorporated but the proposal of adding the idea
of maps into the picture has not been incorporated for now. The reasons
why being:

1) It increases scope in the short term without a lot of gain. Since the
the upgrade to including maps into the picture is strictly additive to
the data directory structure, it won't be an issue to add it later.
Implementing maps in the short term, even just creating the idea of a
default map is not trivial, and adds a pretty big hurdle.

2) Andrea pointed out that the data publishing split with regard to maps
has not totally been fleshed out at this point. And indeed there is some
thoughts about using a thread local view of the catalog as an
alternative. So adding in maps to the structure now could indeed be a
crutch come later.

So that is the rationale for leaving it out of the picture for now.
Those who stand by the feedback still can vote -1.

So with that said, let the voting begin.

-Justin

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

jive · March 18, 2009, 12:51am

Ah you miss understand me; we are discovery the services in code form;
as such we do not need a folder to straighten all the individual
service files out.

I expected to see a service/ folder but it is not strictly needed.
Jody

2) We are still burying database connections deep, and not re-using
them. I'd like database connections and other local configuration to
be normalised and re-used.

Rob I think that you have the option of using your container to manage
the database connections. As such if you want a single place to manage
connections you could look to your application server?

This is a real issue when we distribute a re-usable Geoserver
configuration via version control - with multiple geoservers
delivering common stuff - INSPIRE for example would require this.

Okay I see how that makes it harder to just backing on to your
application server for connection pools etc.

Jody

Rob_Atkinson1 · March 18, 2009, 1:11am

On Wed, Mar 18, 2009 at 11:51 AM, Jody Garnett <jody.garnett@anonymised.com> wrote:

Ah you miss understand me; we are discovery the services in code form;
as such we do not need a folder to straighten all the individual
service files out.

I expected to see a service/ folder but it is not strictly needed.

I wasnt calling you a Miss!

I know we are discovering services - but if this is an extensible
mechanism, why not set up a naming convention so every new file doesnt
need a modification to the agreed structure (I reckon specifically
named files in the top level should be used sparingly, and under
control of the proposal, since documentation will need to be kept up
to date etc)

2) We are still burying database connections deep, and not re-using
them. I'd like database connections and other local configuration to
be normalised and re-used.

Rob I think that you have the option of using your container to manage
the database connections. As such if you want a single place to manage
connections you could look to your application server?

Good point - makes the argument for removing the database connections
from the guts of the config even more compelling IMHO!

This is a real issue when we distribute a re-usable Geoserver
configuration via version control - with multiple geoservers
delivering common stuff - INSPIRE for example would require this.

Okay I see how that makes it harder to just backing on to your
application server for connection pools etc.

yes - no guarantee that the application server will provide this either.

Rob

Justin_Deoliveira · March 18, 2009, 1:52am

Hi Rob,

Thanks for the feedback, comments inline.

Rob Atkinson wrote:

Hi

I'm just consulting my team on this - but I'd make two comments

1) agree with Jody - if services are "plugged in", having hard coded
top level file names for config seems wrong. Can we change this to a
more explicit

services/<unique service plugin name>.xml

so that it can be extended without further negotiated change to the
formal structure?

I am ok with putting these files in the services directory but whether they are at the top level or in a sub directory really makes no difference to how they will be read. The existence of the file does not mean the service is active, and vice versa.

2) We are still burying database connections deep, and not re-using
them. I'd like database connections and other local configuration to
be normalised and re-used.

can we have a top level directory connections/ or authorisations/

This is a real issue when we distribute a re-usable Geoserver
configuration via version control - with multiple geoservers
delivering common stuff - INSPIRE for example would require this.
There may be an element of local mapping - but we actually found that
was often encapsulated in database views and it was only multiple,
buried, not-separately-testable database connections that needed
configuring.

While I agree with the concept I want to reinforce that this proposal is not proposing any improvements to the configuration, and is not proposing any new information to be stores in the dat directory. It is just a reorganization of the information that is already there.

We don't store this info in config today so this is out of scope.

3) It is important that namespaces be "augmented" by explicit
declaration - the general case is that the target configuration
exposes a namespace as part of a contract between the service and the
world of clients. It should be possible to "make this up" during
FeatureType configuration, or use one extracted from the definition of
the FeatureType (the application schema case). Its not clear to me if
this is an issue - probably an implementation issue, not a directory
structure issue

You lost me on this one :).

Sorry to provide feedback so late.

Rob Atkinson

On Wed, Mar 18, 2009 at 10:40 AM, Jody Garnett <jody.garnett@anonymised.com> wrote:

Thanks for the nice clear presentation - I am happy to vote +1.

I would consider:
global.xml
service/wfs.xml
service/wms.xml
service/wcs.xml
service/wps.xml

But it does not make much of a difference.

Jody

On Wed, Mar 18, 2009 at 6:17 AM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Hi all,

I would like to call for a vote on GSIP 34:

http://geoserver.org/display/GEOS/GSIP+34+-+New+data+directory+structure+for+2.x

Most feedback as been incorporated but the proposal of adding the idea
of maps into the picture has not been incorporated for now. The reasons
why being:

1) It increases scope in the short term without a lot of gain. Since the
the upgrade to including maps into the picture is strictly additive to
the data directory structure, it won't be an issue to add it later.
Implementing maps in the short term, even just creating the idea of a
default map is not trivial, and adds a pretty big hurdle.

2) Andrea pointed out that the data publishing split with regard to maps
has not totally been fleshed out at this point. And indeed there is some
thoughts about using a thread local view of the catalog as an
alternative. So adding in maps to the structure now could indeed be a
crutch come later.

So that is the rationale for leaving it out of the picture for now.
Those who stand by the feedback still can vote -1.

So with that said, let the voting begin.

-Justin

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

Rob_Atkinson1 · March 18, 2009, 3:17am

I am ok with putting these files in the services directory but whether they
are at the top level or in a sub directory really makes no difference to how
they will be read. The existence of the file does not mean the service is
active, and vice versa.

Understood - it wasnt about the functionality, but simply not setting
a number of particular services in stone and needing changes to
directory structure to add any more (a top level file is part of
directory structure according to the scope of this request)

2) We are still burying database connections deep, and not re-using
them. I'd like database connections and other local configuration to
be normalised and re-used.

can we have a top level directory connections/ or authorisations/

This is a real issue when we distribute a re-usable Geoserver
configuration via version control - with multiple geoservers
delivering common stuff - INSPIRE for example would require this.
There may be an element of local mapping - but we actually found that
was often encapsulated in database views and it was only multiple,
buried, not-separately-testable database connections that needed
configuring.

While I agree with the concept I want to reinforce that this proposal is not
proposing any improvements to the configuration, and is not proposing any
new information to be stores in the dat directory. It is just a
reorganization of the information that is already there.

OK - so if this is not going to make it harder to fix this later, you
have my +1 officially.

We don't store this info in config today so this is out of scope.

3) It is important that namespaces be "augmented" by explicit
declaration - the general case is that the target configuration
exposes a namespace as part of a contract between the service and the
world of clients. It should be possible to "make this up" during
FeatureType configuration, or use one extracted from the definition of
the FeatureType (the application schema case). Its not clear to me if
this is an issue - probably an implementation issue, not a directory
structure issue

You lost me on this one :).

Manually defining namespaces during configuration is a corner case in
the long run. These will always be defined in application schemas, or
can be generated automatically without user configuration if they have
no external meaning. So, just want to avoid putting too much effort
into something I think needs fixing.

Sorry to provide feedback so late.

Rob Atkinson

On Wed, Mar 18, 2009 at 10:40 AM, Jody Garnett <jody.garnett@anonymised.com>
wrote:

Thanks for the nice clear presentation - I am happy to vote +1.

I would consider:
global.xml
service/wfs.xml
service/wms.xml
service/wcs.xml
service/wps.xml

But it does not make much of a difference.

Jody

On Wed, Mar 18, 2009 at 6:17 AM, Justin Deoliveira <jdeolive@anonymised.com>
wrote:

Hi all,

I would like to call for a vote on GSIP 34:

http://geoserver.org/display/GEOS/GSIP+34+-+New+data+directory+structure+for+2.x

Most feedback as been incorporated but the proposal of adding the idea
of maps into the picture has not been incorporated for now. The reasons
why being:

1) It increases scope in the short term without a lot of gain. Since the
the upgrade to including maps into the picture is strictly additive to
the data directory structure, it won't be an issue to add it later.
Implementing maps in the short term, even just creating the idea of a
default map is not trivial, and adds a pretty big hurdle.

2) Andrea pointed out that the data publishing split with regard to maps
has not totally been fleshed out at this point. And indeed there is some
thoughts about using a thread local view of the catalog as an
alternative. So adding in maps to the structure now could indeed be a
crutch come later.

So that is the rationale for leaving it out of the picture for now.
Those who stand by the feedback still can vote -1.

So with that said, let the voting begin.

-Justin

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based
development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based
development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

Justin_Deoliveira · March 18, 2009, 2:54pm

Rob Atkinson wrote:

I am ok with putting these files in the services directory but whether they
are at the top level or in a sub directory really makes no difference to how
they will be read. The existence of the file does not mean the service is
active, and vice versa.

Understood - it wasnt about the functionality, but simply not setting
a number of particular services in stone and needing changes to
directory structure to add any more (a top level file is part of
directory structure according to the scope of this request)

Cool, sounds good, services directory it is.

2) We are still burying database connections deep, and not re-using
them. I'd like database connections and other local configuration to
be normalised and re-used.

can we have a top level directory connections/ or authorisations/

This is a real issue when we distribute a re-usable Geoserver
configuration via version control - with multiple geoservers
delivering common stuff - INSPIRE for example would require this.
There may be an element of local mapping - but we actually found that
was often encapsulated in database views and it was only multiple,
buried, not-separately-testable database connections that needed
configuring.

While I agree with the concept I want to reinforce that this proposal is not
proposing any improvements to the configuration, and is not proposing any
new information to be stores in the dat directory. It is just a
reorganization of the information that is already there.

OK - so if this is not going to make it harder to fix this later, you
have my +1 officially.

We don't store this info in config today so this is out of scope.

3) It is important that namespaces be "augmented" by explicit
declaration - the general case is that the target configuration
exposes a namespace as part of a contract between the service and the
world of clients. It should be possible to "make this up" during
FeatureType configuration, or use one extracted from the definition of
the FeatureType (the application schema case). Its not clear to me if
this is an issue - probably an implementation issue, not a directory
structure issue

You lost me on this one :).

Manually defining namespaces during configuration is a corner case in
the long run. These will always be defined in application schemas, or
can be generated automatically without user configuration if they have
no external meaning. So, just want to avoid putting too much effort
into something I think needs fixing.

Ahh I see, and yeah I fully agree. This is the motivation behind the workspace idea, have it be a container for data stores, etc... and have a namespace just be an attribute of a feature type. Ideally the way it would work is as you say, upload a bunch of application schemas, figure out the application schema namespaces, and choice one when setting up a feature type.

Sorry to provide feedback so late.

Rob Atkinson

On Wed, Mar 18, 2009 at 10:40 AM, Jody Garnett <jody.garnett@anonymised.com>
wrote:

Thanks for the nice clear presentation - I am happy to vote +1.

I would consider:
global.xml
service/wfs.xml
service/wms.xml
service/wcs.xml
service/wps.xml

But it does not make much of a difference.

Jody

On Wed, Mar 18, 2009 at 6:17 AM, Justin Deoliveira <jdeolive@anonymised.com>
wrote:

Hi all,

I would like to call for a vote on GSIP 34:

http://geoserver.org/display/GEOS/GSIP+34+-+New+data+directory+structure+for+2.x

Most feedback as been incorporated but the proposal of adding the idea
of maps into the picture has not been incorporated for now. The reasons
why being:

1) It increases scope in the short term without a lot of gain. Since the
the upgrade to including maps into the picture is strictly additive to
the data directory structure, it won't be an issue to add it later.
Implementing maps in the short term, even just creating the idea of a
default map is not trivial, and adds a pretty big hurdle.

2) Andrea pointed out that the data publishing split with regard to maps
has not totally been fleshed out at this point. And indeed there is some
thoughts about using a thread local view of the catalog as an
alternative. So adding in maps to the structure now could indeed be a
crutch come later.

So that is the rationale for leaving it out of the picture for now.
Those who stand by the feedback still can vote -1.

So with that said, let the voting begin.

-Justin

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based
development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based
development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

Michael_Melvin · March 19, 2009, 3:11pm

Hi all. I know I'm very late to the party here, so please forgive.

I like this proposal. It makes the directory more complex (in terms of quantity of files) but also more granular. That's a trade off I'm comfortable with.

The GSIP page doesn't seem to mention (or at least I can't find) the directory called "data" (either in the new schema or the old). Does this directory (which as we all know contains the actual shapefiles) still exist in the same place or has it been moved?

I ask because this highlights something uncomfortable for me: The Data Directory isn't really a data directory. What I mean is that it is both a Configuration Directory _and_ a Data Directory. And, also personally, I find it confusing (and so have some others) to have a "data" directory inside of the "Data Directory", especially when there are other things inside the "Data Directory" that aren't data. (Whew.) Perhaps this is just a nomenclature issue. (Jumping the gun here, I guess perhaps I'm asking that if we want to change the structure of the "Data Directory", perhaps it's a good time to change the name of it as well.)

Can anyone direct me through this?

Thanks,
Mike Pumphrey
OpenGeo - http://opengeo.org

Justin Deoliveira wrote:

Hi all,

I would like to call for a vote on GSIP 34:

http://geoserver.org/display/GEOS/GSIP+34+-+New+data+directory+structure+for+2.x

Most feedback as been incorporated but the proposal of adding the idea of maps into the picture has not been incorporated for now. The reasons why being:

1) It increases scope in the short term without a lot of gain. Since the the upgrade to including maps into the picture is strictly additive to the data directory structure, it won't be an issue to add it later. Implementing maps in the short term, even just creating the idea of a default map is not trivial, and adds a pretty big hurdle.

2) Andrea pointed out that the data publishing split with regard to maps has not totally been fleshed out at this point. And indeed there is some thoughts about using a thread local view of the catalog as an alternative. So adding in maps to the structure now could indeed be a crutch come later.

So that is the rationale for leaving it out of the picture for now. Those who stand by the feedback still can vote -1.

So with that said, let the voting begin.

-Justin

Justin_Deoliveira · March 19, 2009, 5:08pm

Hi Mike,

You are very correct, the "data directory" is poorly named to the purpose it actually serves. But this is what it has always been called so I fear trying to rename or rebrand it woudl cause more confusion.

But you are right, calling it "GEOSERVER_CONFG_DIRECTORY" would make much more sense imo. And calling the "data" directory under the config directory the actual "data directory".

And about the "data" directory, it is the same in the new as in the old. I simply forgot to add it.

-Justin

Mike Pumphrey wrote:

Hi all. I know I'm very late to the party here, so please forgive.

I like this proposal. It makes the directory more complex (in terms of quantity of files) but also more granular. That's a trade off I'm comfortable with.

The GSIP page doesn't seem to mention (or at least I can't find) the directory called "data" (either in the new schema or the old). Does this directory (which as we all know contains the actual shapefiles) still exist in the same place or has it been moved?

I ask because this highlights something uncomfortable for me: The Data Directory isn't really a data directory. What I mean is that it is both a Configuration Directory _and_ a Data Directory. And, also personally, I find it confusing (and so have some others) to have a "data" directory inside of the "Data Directory", especially when there are other things inside the "Data Directory" that aren't data. (Whew.) Perhaps this is just a nomenclature issue. (Jumping the gun here, I guess perhaps I'm asking that if we want to change the structure of the "Data Directory", perhaps it's a good time to change the name of it as well.)

Can anyone direct me through this?

Thanks,
Mike Pumphrey
OpenGeo - http://opengeo.org

Justin Deoliveira wrote:

Hi all,

I would like to call for a vote on GSIP 34:

http://geoserver.org/display/GEOS/GSIP+34+-+New+data+directory+structure+for+2.x

Most feedback as been incorporated but the proposal of adding the idea of maps into the picture has not been incorporated for now. The reasons why being:

1) It increases scope in the short term without a lot of gain. Since the the upgrade to including maps into the picture is strictly additive to the data directory structure, it won't be an issue to add it later. Implementing maps in the short term, even just creating the idea of a default map is not trivial, and adds a pretty big hurdle.

2) Andrea pointed out that the data publishing split with regard to maps has not totally been fleshed out at this point. And indeed there is some thoughts about using a thread local view of the catalog as an alternative. So adding in maps to the structure now could indeed be a crutch come later.

So that is the rationale for leaving it out of the picture for now. Those who stand by the feedback still can vote -1.

So with that said, let the voting begin.

-Justin

------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

Michael_Melvin · March 19, 2009, 6:31pm

Hi Justin. Thanks for the clarification.

I understand that we're trying to minimize confusion, which is good. However, since are making so many changes with this GSIP, if ever there were a time to change names of things (major release and all), now would be the time.

So, I'd like to propose changing the name of the Data Directory. Just because it's always been this way doesn't mean it always should be this way! (I'm saying this so strongly just to elicit passionate feedback from people. )

Caveat: This isn't (just) because it pains me to tell people to look in the data directory of their Data Directory. But think how nice it would be (especially for a new user) to say "look in the data directory inside your GeoServer Configuration Directory." Breathe out.

Thanks,
Mike Pumphrey
OpenGeo - http://opengeo.org

Justin Deoliveira wrote:

Hi Mike,

You are very correct, the "data directory" is poorly named to the purpose it actually serves. But this is what it has always been called so I fear trying to rename or rebrand it woudl cause more confusion.

But you are right, calling it "GEOSERVER_CONFG_DIRECTORY" would make much more sense imo. And calling the "data" directory under the config directory the actual "data directory".

And about the "data" directory, it is the same in the new as in the old. I simply forgot to add it.

-Justin

Mike Pumphrey wrote:

Hi all. I know I'm very late to the party here, so please forgive.

I like this proposal. It makes the directory more complex (in terms of quantity of files) but also more granular. That's a trade off I'm comfortable with.

The GSIP page doesn't seem to mention (or at least I can't find) the directory called "data" (either in the new schema or the old). Does this directory (which as we all know contains the actual shapefiles) still exist in the same place or has it been moved?

I ask because this highlights something uncomfortable for me: The Data Directory isn't really a data directory. What I mean is that it is both a Configuration Directory _and_ a Data Directory. And, also personally, I find it confusing (and so have some others) to have a "data" directory inside of the "Data Directory", especially when there are other things inside the "Data Directory" that aren't data. (Whew.) Perhaps this is just a nomenclature issue. (Jumping the gun here, I guess perhaps I'm asking that if we want to change the structure of the "Data Directory", perhaps it's a good time to change the name of it as well.)

Can anyone direct me through this?

Thanks,
Mike Pumphrey
OpenGeo - http://opengeo.org

Justin Deoliveira wrote:

Hi all,

I would like to call for a vote on GSIP 34:

http://geoserver.org/display/GEOS/GSIP+34+-+New+data+directory+structure+for+2.x

Most feedback as been incorporated but the proposal of adding the idea of maps into the picture has not been incorporated for now. The reasons why being:

1) It increases scope in the short term without a lot of gain. Since the the upgrade to including maps into the picture is strictly additive to the data directory structure, it won't be an issue to add it later. Implementing maps in the short term, even just creating the idea of a default map is not trivial, and adds a pretty big hurdle.

2) Andrea pointed out that the data publishing split with regard to maps has not totally been fleshed out at this point. And indeed there is some thoughts about using a thread local view of the catalog as an alternative. So adding in maps to the structure now could indeed be a crutch come later.

So that is the rationale for leaving it out of the picture for now. Those who stand by the feedback still can vote -1.

So with that said, let the voting begin.

-Justin

------------------------------------------------------------------------------

Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Alessio_Fabiani · March 25, 2009, 3:03pm

Hi guys,

a +0 on my side since it seems very good to me but I'm not deeply
involved in the 2.x development.

The only thing I can say is that it would be really nice to have at a
certain point a sort of "lazy" catalog or some mechanism which allow
us to persist/load only the things we are asking for, and as far as I
understood from the GSIP page this is one of the goals of this new
directory structure.

Cheers,
Alessio.

-------------------------------------------------------
Eng. Alessio Fabiani
Vice-President /CTO GeoSolutions S.A.S.
Via Carignoni 51
55041 Camaiore (LU)
Italy

phone: +39 0584 980933
fax: +39 0584 983027
mob: +39 349 8227000

http://www.geo-solutions.it

-------------------------------------------------------

On Thu, Mar 19, 2009 at 7:31 PM, Mike Pumphrey <mike@anonymised.com> wrote:

Hi Justin. Thanks for the clarification.

I understand that we're trying to minimize confusion, which is good.
However, since are making so many changes with this GSIP, if ever there
were a time to change names of things (major release and all), now would
be the time.

So, I'd like to propose changing the name of the Data Directory. Just
because it's always been this way doesn't mean it always should be this
way! (I'm saying this so strongly just to elicit passionate feedback
from people. )

Caveat: This isn't (just) because it pains me to tell people to look in
the data directory of their Data Directory. But think how nice it would
be (especially for a new user) to say "look in the data directory inside
your GeoServer Configuration Directory." Breathe out.

Thanks,
Mike Pumphrey
OpenGeo - http://opengeo.org

Justin Deoliveira wrote:

Hi Mike,

You are very correct, the "data directory" is poorly named to the
purpose it actually serves. But this is what it has always been called
so I fear trying to rename or rebrand it woudl cause more confusion.

But you are right, calling it "GEOSERVER_CONFG_DIRECTORY" would make
much more sense imo. And calling the "data" directory under the config
directory the actual "data directory".

And about the "data" directory, it is the same in the new as in the old.
I simply forgot to add it.

-Justin

Mike Pumphrey wrote:

Hi all. I know I'm very late to the party here, so please forgive.

I like this proposal. It makes the directory more complex (in terms
of quantity of files) but also more granular. That's a trade off I'm
comfortable with.

The GSIP page doesn't seem to mention (or at least I can't find) the
directory called "data" (either in the new schema or the old). Does
this directory (which as we all know contains the actual shapefiles)
still exist in the same place or has it been moved?

I ask because this highlights something uncomfortable for me: The
Data Directory isn't really a data directory. What I mean is that it
is both a Configuration Directory _and_ a Data Directory. And, also
personally, I find it confusing (and so have some others) to have a
"data" directory inside of the "Data Directory", especially when there
are other things inside the "Data Directory" that aren't data.
(Whew.) Perhaps this is just a nomenclature issue. (Jumping the gun
here, I guess perhaps I'm asking that if we want to change the
structure of the "Data Directory", perhaps it's a good time to change
the name of it as well.)

Can anyone direct me through this?

Thanks,
Mike Pumphrey
OpenGeo - http://opengeo.org

Justin Deoliveira wrote:

Hi all,

I would like to call for a vote on GSIP 34:

http://geoserver.org/display/GEOS/GSIP+34+-+New+data+directory+structure+for+2.x

Most feedback as been incorporated but the proposal of adding the
idea of maps into the picture has not been incorporated for now. The
reasons why being:

1) It increases scope in the short term without a lot of gain. Since
the the upgrade to including maps into the picture is strictly
additive to the data directory structure, it won't be an issue to add
it later. Implementing maps in the short term, even just creating the
idea of a default map is not trivial, and adds a pretty big hurdle.

2) Andrea pointed out that the data publishing split with regard to
maps has not totally been fleshed out at this point. And indeed there
is some thoughts about using a thread local view of the catalog as an
alternative. So adding in maps to the structure now could indeed be a
crutch come later.

So that is the rationale for leaving it out of the picture for now.
Those who stand by the feedback still can vote -1.

So with that said, let the voting begin.

-Justin

------------------------------------------------------------------------------

Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based
development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Justin_Deoliveira · March 25, 2009, 4:27pm

Hi Alessio,

Yeah, this is something I would love to see too. However doing lazy loading with the in memory catalog could be a lot of work. But def something that is needed for sure.

My unofficial plan has always been to handle this with the hibernate based catalog.

-Justin

Alessio Fabiani wrote:

Hi guys,

a +0 on my side since it seems very good to me but I'm not deeply
involved in the 2.x development.

The only thing I can say is that it would be really nice to have at a
certain point a sort of "lazy" catalog or some mechanism which allow
us to persist/load only the things we are asking for, and as far as I
understood from the GSIP page this is one of the goals of this new
directory structure.

Cheers,
Alessio.

-------------------------------------------------------
Eng. Alessio Fabiani
Vice-President /CTO GeoSolutions S.A.S.
Via Carignoni 51
55041 Camaiore (LU)
Italy

phone: +39 0584 980933
fax: +39 0584 983027
mob: +39 349 8227000

http://www.geo-solutions.it

-------------------------------------------------------

On Thu, Mar 19, 2009 at 7:31 PM, Mike Pumphrey <mike@anonymised.com> wrote:

Hi Justin. Thanks for the clarification.

I understand that we're trying to minimize confusion, which is good.
However, since are making so many changes with this GSIP, if ever there
were a time to change names of things (major release and all), now would
be the time.

So, I'd like to propose changing the name of the Data Directory. Just
because it's always been this way doesn't mean it always should be this
way! (I'm saying this so strongly just to elicit passionate feedback
from people. )

Caveat: This isn't (just) because it pains me to tell people to look in
the data directory of their Data Directory. But think how nice it would
be (especially for a new user) to say "look in the data directory inside
your GeoServer Configuration Directory." Breathe out.

Thanks,
Mike Pumphrey
OpenGeo - http://opengeo.org

Justin Deoliveira wrote:

Hi Mike,

You are very correct, the "data directory" is poorly named to the
purpose it actually serves. But this is what it has always been called
so I fear trying to rename or rebrand it woudl cause more confusion.

But you are right, calling it "GEOSERVER_CONFG_DIRECTORY" would make
much more sense imo. And calling the "data" directory under the config
directory the actual "data directory".

And about the "data" directory, it is the same in the new as in the old.
I simply forgot to add it.

-Justin

Mike Pumphrey wrote:

Hi all. I know I'm very late to the party here, so please forgive.

I like this proposal. It makes the directory more complex (in terms
of quantity of files) but also more granular. That's a trade off I'm
comfortable with.

The GSIP page doesn't seem to mention (or at least I can't find) the
directory called "data" (either in the new schema or the old). Does
this directory (which as we all know contains the actual shapefiles)
still exist in the same place or has it been moved?

I ask because this highlights something uncomfortable for me: The
Data Directory isn't really a data directory. What I mean is that it
is both a Configuration Directory _and_ a Data Directory. And, also
personally, I find it confusing (and so have some others) to have a
"data" directory inside of the "Data Directory", especially when there
are other things inside the "Data Directory" that aren't data.
(Whew.) Perhaps this is just a nomenclature issue. (Jumping the gun
here, I guess perhaps I'm asking that if we want to change the
structure of the "Data Directory", perhaps it's a good time to change
the name of it as well.)

Can anyone direct me through this?

Thanks,
Mike Pumphrey
OpenGeo - http://opengeo.org

Justin Deoliveira wrote:

Hi all,

I would like to call for a vote on GSIP 34:

http://geoserver.org/display/GEOS/GSIP+34+-+New+data+directory+structure+for+2.x

Most feedback as been incorporated but the proposal of adding the
idea of maps into the picture has not been incorporated for now. The
reasons why being:

1) It increases scope in the short term without a lot of gain. Since
the the upgrade to including maps into the picture is strictly
additive to the data directory structure, it won't be an issue to add
it later. Implementing maps in the short term, even just creating the
idea of a default map is not trivial, and adds a pretty big hurdle.

2) Andrea pointed out that the data publishing split with regard to
maps has not totally been fleshed out at this point. And indeed there
is some thoughts about using a thread local view of the catalog as an
alternative. So adding in maps to the structure now could indeed be a
crutch come later.

So that is the rationale for leaving it out of the picture for now.
Those who stand by the feedback still can vote -1.

So with that said, let the voting begin.

-Justin

------------------------------------------------------------------------------

Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based
development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.