Chris Holmes ha scritto: > Hey all, sorry for sounding in late on this thread. > > GeoSearch as a core module is the top of my list. And after that > getting RestConfig as a core module - we hit it pretty heavily recently, > flushed out some bugs, so it should be pretty good. I'm super psyched > on the Styler stuff, and a basic version should be easy from a GeoServer > perspective (and depends on restconfig). We should think about how we > want better integration. Directory datastore would also be really nice > to have.
I looked into it a bit, and I would like to propose a rewrite for it. I mean, don't be scare by the term, the datastore is really just 2 classes now, I would replace it but slightly less more. I have some ideas in mind, shall I start a discussion on gt2-devel? > And ogr output for wfs would be a nice win, especially since > we already have the gdal stuff, so people will be more used to the > platform specific stuff. Sure. The idea here is a bit different in that we would use ogr2ogr executable instead of my old attempt at an OGR data store (export to shapefile, ogr2ogr to whatever other format). Upsides: - the user can use whatever is shipped on her plaftorm (think unix users) - if ogr2ogr crashes GeoServer lives happily along and can report a service exception - ogr2ogr is available in binary form for many platforms and we don't need to move a finger Downsides: - less control over the feature type in output (we're basically stuck with the shapefile limitations) - using shapefile in the middle means paying a performance price... I guess this is not much relevant thought, since extracting a file is pretty much a one time operation, whilst say GML clients such as uDig tend to make requests over and over > * When GeoSearch per layer about pages are in, we should be sure to link > to them from the preview page. Those output pages concern me a little bit as you have a direct "download as shapefile link". As much as I know the functionality was there before, now it's right in the face of a user. Shapefile output does not stream, if the admin is not very careful to setup a small maxFeatures limit the server will end up doing a very long processing to create and zip the file even if the user is not really waiting for it anymore Think random user that wanders around the previews, hit a shapefile link, takes too much time, then moves to another type, and so on. > *GeoWebCache integration feedback* > It's really great we have GWC as a part of things. I think we should > work on both making it more obvious that users can use it, and to > integrate it more directly > > * GWC options in openlayers preview. At the very least the drop down > should be 'single tile, tiled, and cached'. Ideally we would also have > buttons in there to 'truncate cache' (for when a user changes a style), > and even 'seed the cache'. Again from the resource usage department, do we really want to show in a easy for a random user to use position the "cache" option that has the side effect of consuming server side disk space? Arne, is there any way to have the out of the box GeoServer never use more than X megabytes grand total in the cache (not per type, globally)? The two buttons seem like a good idea, but they should work only for the admin. Is the browser going to ask for credentials if you're not logged in? > * More prominent links to GWC from admin console - perhaps on the front > page, along with the capabilities links. And perhaps links from the > demo page. Nice one. > * Real tiling integration - right now we make an in memory tile cache > when tile requests come in. Better would be to check the GWC cache to > see if a tile is already there. And to add it if it's not. Then > GeoServer would have seamless caching whenever tiling clients are used. > For this to work really well we'd need GWC listening to styling config > changes and transactions (and anything else that may affect rendering), > so that people don't change styles and continue to see the old. But we > also could just have a useCache param or something in the wms request? Yep, very much agreed this is a good idea. Imho we should give the admin more control too. Do we want a certain layer to be cacheable? What is the max amount of disk we allow for caching each type, and what is the grand total max amount? > *Installers* > > The mac installer is now way better than the others. We should step up > on the others. Suggestions on how to make the Win better? We also miss sorely .rpm and .deb, I would invest more time in them before making the win installer better. > *Docs* > > Really, from a product perspective, this should probably be the highest > priority. Our tech is kicking major ass, we need to make it more > obvious to people how to use it. The RestConfig stuff in particular > will need a lot of documentation and examples and sample scripts. But > we've known for awhile that most of the docs could use some love. I'd > like us to make a commitment to being the best document geospatial > server, open source or otherwise. Docs wise, what about screenshots? They are important for ease of use of the docs, but the UI is going to change a lot... Cheers Andrea -- Andrea Aime OpenGeo - http://opengeo.org Expert service straight from the developers. ------------------------------------------------------------------------------ SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
