It would be great if they could reply and say what there interest is in
FM (even if just "I think it will be good in the future"), what type of
timeline constraints they have (if any), and what kind of resources they
have that they could throw at it (if any).
Complex-features is 90% of what is needed to do useful work on data
standards, and deploy "real-world" GML application schemas. I'm told
fixing the last 10% relies on FM...
FM becoming the trunk represents having data interoperability actively
supported, and one or more whole markets for geoserver (and people like
me) opened up: spatial data infrastructures and scientific applications.
I will update and actively maintain the "Geometryless" datastore, which
I find is useful in at least 50% of real world applications, but only
against FM branch. Through this I can help with reviewing
architecture/APIs for refactoring the datastore, jdbc and core
datastore testing regimes - I wont have time to lead this and do all the
liaison with the the heavyweights out there who need to review and
approve it, so its better if this is led by the main developers.
Once FM looks like the focus of effort I will also undertake some
testing of community schema support via creation of test cases.
My biggest stake is getting everyone back in the same pool. Having a
better feature model to accomdate simple and advanced uses will be a
huge step forward in doing that as people will be able to do more
straight with trunk. And if we want to avoid another fork in the code
base as GML 3 comes down the pipe this needs to happen.
The massive dissipation of effort in current branches seems like a major
problem - it increases total effort required, reduces accessibility,
reduces testing of any given bit of code, generates dependencies and
despondencies. I would suggest that if OWS CITE becomes an opportunity
it is used to bring together the key functional and code refactroing
into a critical mass of testing. Coverages and FM are related if WMS,
WFS, WCS are to be managed with common configurations.
dave
ps. At least two people mentioned that GC 'requires' or affects FM,
which (if true) would mean that there needs to be some planning between
FM and GC. This could really throw a "wrench in the works" if FM need
modification to properly accommodate GCs (or visa-versa).
Or its a good thing as it means we might put enough effort into one
place for a change. Maybe we should bite the bullet and undertake
merging them both at the same time. Bug fixes to releases must be
converted to a regime of bug fixes against the new trunk with back ports
to stable version ASAP.
Rob A
-------------------------------------------------------
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
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
