I dont think you read my post very carefully - I supported the mass market (KML etc) focus as a short term goal. I dont think its me criticising your position as a default here. I simply feel its worth pointing out that since UI investment is a massive burden, we should be aware there are definitely multiple perspectives on what the product (and hence UI) should focus on.
for example - I dont want a fancy UI to allow me to manually enter virus signatures - it works very nicely distributing updates. We need to "work smarter, not just harder". Do we go round the hill, over it, or through it? Merry Christmas Rob On Wed, Dec 24, 2008 at 6:49 PM, Andrea Aime <aa...@opengeo.org> wrote: > Ben Caradoc-Davies ha scritto: >> >> Andrea Aime wrote: >>> >>> Rob Atkinson ha scritto: >>>> >>>> Glossy UIs are not a bad thing by any means, but only make them >>>> believe for a short time they can do the technology side. There will >>>> always be issues the content folks will never be capable of dealing >>>> with (connection pools and dimensioning databases, security of web >>>> services etc. ) >>> >>> Rob, you're missing the point there. >>> I remember you saying one/two years ago that GeoServer was useless >>> without complex features... well, look again, it's been some time >>> and we're still here and growing. >> >> Meanwhile, deegree is eating our lunch. Those delivering >> application-schema-conforming WFS use deegree, Cocoon-based XSLT, or >> commercial solutions. >> >>> And quite frankly, what's the last time you enjoyed putting >>> together an SLD by writing it directly, all or in part? >>> Or when did you had fun putting together yet another >>> OL based viewer? >>> I for sure hate the first and find the second annoying at best. >>> Please please (please!) give me a UI so that I don't have >>> to waste my time doing that again! >> >> Those using deegree to deliver application-schema-conforming WFS yearn for >> the (relative) elegance and simplicity of hand-edited XML configuration >> files. Ugly, yes, but at the moment they have to write many complicated XSLT >> to postprocess their output, and corresponding XSLT to preprocess incoming >> queries. Nasty. >> >> We have a window of opportunity in which GeoServer can provide a more >> robust and repeatable solution. Of course, a good UI is desirable in the >> long term, but the immediate priority must be to deliver application schema >> WFS with the minimum of fuss. > > Then act. Nobody is stopping you, we just ask that things are done > properly that they don't break a successful product solid to deal with > a use case that, for the moment, is for a minority of users. > > Do you see tons of users asking for complex features on the users > list (I'm not saying there are any, but that's not exactly what > is being requested day in day out)? > > Put under another perspective, look at a sample GeoServer site > such as MASSGIS, here is their layer list: > http://giswebservices.massgis.state.ma.us/geoserver/mapPreview.do > > Out of 300+ layers only a handful are rasters (the last two only > afaik), everything else is vector and it's published using both > WMS and WFS. Now, can you tell me how many of those layers > have a community schema that could be used to publish them > in a "compliant" way? 2? 10? > > I'm not saying community schema is not important, and I'm not saying > we should drop it or anything. I'm just stating my priorities and > my reactions to a course gone bad. > Is it really such news that in _my_ book (my book, not OpenGeo one) > the important elements are spatial analysis, good cartographic output, > decent performance and a good UI? > (and that we fall short on 3 out of 4 of them?) > > If those in your book are community schema related, act on them, > we won't stop you, we'll even provide enough review time to > do basic damage control. Just don't pretend everybody jumps > on your bandwagon because you say it's important, accept > that other people have different priorities. > > When we did more KML, or better labelling, or a security > subsystem, and so on, did we ask for buy in, or for other people > to join the battle and provide resources? > Or when GeoSolutions worked on coverages, raster symbolizer, > or GDAL support, did they ask anything other than a review > when it was time to merge? > > Then why every time we speak about doing anything other than > community schema you jump the gun? Aren't we free to allocate > resources to what we feel is important? We already agreed > to give a helping hand in terms of review and merge, why is > that not enough? > > Cheers > Andrea > > -- > Andrea Aime > OpenGeo - http://opengeo.org > Expert service straight from the developers. > ------------------------------------------------------------------------------ _______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
