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
I had already refactored it out of GeoServer, removed (quite roughly)
all the dependencies from WFS/HTTP/XML/etc. and I had it working from
a simple JUnit TestCase. It's not pluggable though.
I added a simple Wiki page where you can download it and that we can use
to discuss this matter:
http://docs.codehaus.org/display/GEOS/TransactionResponse+refactoring
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.0I 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.
This would be great!!! I don't know how you intend to manage it,
but if you can do that, I'll follow!!!
Plus, we'd get a chance to see how well the plugin system
works and use
that to make 2.0 "even better".
Yes, it can work as a sort of proof-of-concept for a more complex plugin
system.
Does that work for your schedule?
It can, if you really know how to put it in place.
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.
Yes, the full 2.0 is probably really more complex. We already have
repackaged GeoServer so that DataStores are pluggable, but services
(WFS,WMS, etc.) are still fixed (well they're fixed by the web.xml nature),
and also it works only with JBoss. But we can share what we have and see
if you find it interesting.
dave
Bye Paolo