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 >> [email protected] >> 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 [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
