Andrea Aime wrote: > 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? > Sure, sounds good.
>> 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 > This sounds like the way to go to me. >> * 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. > Yeah, my first item on the GeoWebCache roadmap post 1.0 is to have it cache WFS requests, like exactly the links that are there. So the first user to hit it will generate it, and then GWC will just keep it on disk to return to the next. Eventually hook up to the ability to listen to transactions. >> *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)? > Good point. Yeah, should put that in GWC, if it's not already. A max total disk size, and use LRU to remove stuff. > 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? > Ah yes. Could perhaps be easier to make it only show up if you're an admin? Will have to ask some javascript people. >> * 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? > Yeah, that should probably just be config options in gwc. >> *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? Make it run as a service. That's the big request. > We also miss sorely > .rpm and .deb, I would invest more time in them before making the > win installer better. > Agreed. -- Chris Holmes 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
