As I said, TOPP has 2 new (and very good) people that we're going to put
on geoserver. The TransactionResponse method really needs to be
re-factored. Its also a good place to try to test out some "plug-in"
ideas that we want to put in Geoserver Enterprise (2.0). GS 2.0 will
probably be built on something that makes plugins easier than what its
currently based on (which is nothing).
In about 2-3 weeks, why dont we get together and try to refactor
TransactionResponse so that:
1. its understandable
2. has places to "plugin" your special-task code
Ideally, I'd like to see you folks running the same code base as
everyone else (instead of on an independent branch) while also having
the ability to do all your development.
What I'm trying to avoid is a situation in which we have 4 forks:
1. current one (1.3.0)
2. one for geotools trunk
3. one you're doing work on
4. one that gabriel is doing work on
5. Geoserver 2.0
I think if we do things right we can narrow this down so that we can
share as many bug fixes and improvments with each other but keep the
"in house" development as independent as possible so that it doesnt
affect others. Ideally we'd get the best of both worlds with none of
the disadvantages.
Plus, we'd get a chance to see how well the plugin system works and use
that to make 2.0 "even better".
Does that work for your schedule?
The full Geoserver 2.0 plugin system could actually take a long time to
develop -- its certainly not something thats going to happen overnight.
It will probably involve moving the udig catalog to geotools (or
scrapping it, or modifying it...) plus figuring out a bunch of
plugin-related issues, looking at configuration & service issues, then
moving all the current systems (wms/wfs/...) to the new Geoserver.
I *definately* do not want to put a timeframe on it since there's a
bunch of other things I also want to do.
dave
----------------------------------------------------------
This mail sent through IMP: https://webmail.limegroup.com/