Rob Atkinson ha scritto:
> Good points Justin, Paul etc
>
> Without any of {correct, useful, fast, reliable and maintainable}
> behaviour, there is failure.
>
> There are several requirements out in the wild:
>
> 1) point of truth - make sure you can deliver to the main infrastructure
> something they can trust. This requires correctness of behaviour to be
> paramount.
> 2) ease of use - end user is going to have a play, and start thinking
> bout real requirements when they see how it works (lets face it, this is
> the majority of WFS and WCS experience at the moment, but the near
> future goal is these players moving to point of truth and
> high-availability services.
> 3) high availability - performance and reliability. Typically these use
> denormalised forms of the point-of truth, in a forward-caching
> configuration. WMS services tend to be in this space, since WMS by
> nature can provides little or no authoritative data.
>
> It seems that to date have focussed almost exclusively on #2, as can be
> seen by less-than-useful behaviour for WFS and less-than-ideal
> performance for WMS.
If WFS behaviour was less than useful Geoserver would not have any user,
traffic on the mailing lists is proof of the contrary imho.
Not being able to handle complex feature is a pity thought, very much
agreed on that.
Less than ideal performance for WMS is something that needs to be
addressed on specific cases, on the general one, we have very few to do
to improve it more. Specific cases are 256 colors rendering, dataset
caching when they are so small that they fit into memory, tile
caching, and maybe parallel rendering, thought I don't expect it to
make us lots faster on a production server, just faster when the number
of users hittin the server is lower than the number of processors, or
when we're cascading from remote
> So +1 for including performance as basis for regressive test cases. -10
> for not making the code useful and maintainable in the process. It looks
> like the design folks are doing a good job of decoupling the issues, but
> cannot implement every possible improvement they enable immediately.
>
> We must simply make calm, informed and pragmatic choices about how to
> best use resources to fill in the gaps. IMHO we are spending far too
> much time backporting key imporvements to old versions instead of
> fixing reliability and performance (including tests) on the trunk.
We did not back port any new functionality afaik, besides the CQL
parser. My day to day work usually involves (painfully) forward porting
bug fixes to trunk. 2.3.x is "stable", yet still bug ridden. Should
I tell poeple having issues to come back in 3/6 months time, when
a Geosever based on trunk will be ready for production use?
Cheers
Andrea
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
