Wow, lots of discussion on branching, RnD work, and the Geoserver
Enterprise Edition (ie. geoserver with a better plugin architecture).
My plan was to wait until after 1.3.0 had been released before moving
over to geotools trunk again. 1.3.0 would be based on the Geotools
2.1.x branch. After that, I wasn't quite sure what was going to
happen. Ideally, I'd like to see 1.3.1 still based on the "solid"
Geotools 2.1.x branch.
Personally, I don't see a reason to jump to Geotools trunk until the
FeatureType (FT) stuff has been properly integrated into it. Thats
supposed to happen around the time 1.3.0 will be released. Since
Geoserver doesn't really directly touch actual features that much (they
get processed in the lite tenderer (WMS) or in the GML xform stuff
(WFS)) I don't expect there to be too many changes for us. At least,
thats what I'm hoping. This does, however, heavily assume that
everything in Geotools actually works after the FT switch.
The TransactionResponse code is the place where things will most likely
break and be difficult to actually fix. Paolo already mentioned this
as a place that works needs to be done. The function is a 600 line
function-of-doom thats unintelligible. I'd really like to see this
refactored so its maintainable. Now, I think we can also add some
amount of plug-ability to this so (much like the way the current
validation stuff sticks in) so that groups like paolo can add a bunch
of functionality (that perhaps no one else uses) but doesn't actually
affect the main codebase. This way everyone will be using the same
codebase but also be able to go in their own direction.
This is one of the main ideas around the Geoserver 2.0 -- making it
plugable. We could put plugin "insertion/extensions" points in the
TransactionResponse function. We could "try" this in the current
codebase first.
I do, however, think that having a Geoserver-for-Geotools-2.1 and
Geoserver-for-Geotools-2.2 is going to be a pain. I'd like to wait
until after 1.3.0's release before we do that, but if a need arises....
My main concern is just there being an overhead in maintaining the two
branches.
I've decided to add a few things to 1.3.0, so its not quite code
complete. Really astute geoserver folks will notice that I added the
SPI mechanism so you can add your own Geoserver WFS output formats.
Currently supported are GML2 and GML2-GZIP, but I'm hoping to also add
a zipped-shapefile output.
As many know, TOPP just hired two new people to work on
geoserver-related things. One of them (Brent Owens) just started last
week, and I'm getting him to do a few "fundamental" things so he knows
geoserver/geotools "inside and out". The second (Justin Deolive) will
be starting mid-september.
I'm currently building geotools trunk and I'll see how much work there
is to actually get it working in Geoserver. I dont think there's been
too many changes, but there's a HUGE number of changes that will be
hitting soon. Who know how well they will work - its likely that we'll
be the test guinea pigs.
Some one was also asking about geoserver being web-only. Although I see
geoserver being web-only, I'd like to minimize the amount of actually
HTTP code in it. The sub-modules (ie. WFS, WMS, WCS, ...) should be
fairly detached from the HTTP environment. Anything they require from
the HTTP request should be explicitly stuck in the Request object(s). I
would also like to see more and more stuff moved from Geoserver into
Geotools, but the new plugin stuff (for 2.0) is suppose to make that
both optional and easy-to-migrate.
Given the fact that the geoserver code base is fairly stable (there's
been very few changes to its "core" in the last 6 months), I can really
appreciate the fact that people would want to develop their code inside
it. I've really tried to protect Geoserver developers from whatever's
been happening in Geotools.
I think thats going to be a bit more difficult in the future because I
see more actual geoserver changes, especially as Geotools does more
radically different things.
So, in summary:
* I'd like to not see geoserver branch, but its probably inevitable.
Ideally, i'd like to see this happen AFTER 1.3.0 releases (ie. about
the same time Geotools FT changes happen). I'm open for other options
so that others can continue their work.
* I'd also like to see TransactionReponse refactored, just to make it
understandable (ie. maintainable), but also so that others (ie. Paolo)
can "plugin" their special-task code (ie. everyone working on the same
codebase, but different groups will have certain functionality).
* I'm worried about branching making everything more difficult/work for
everyone!
* Geoserver 2.0 ("Enterprise Edition") will make this type of thing much
easier to deal with. I think we can still handle these issues the
current codebase with a little bit of work (ie. in
TransactionResponse).
* Geotools doesn't want any new development on 2.1.x, so anything new
you plan to do in Geotools needs to happen on Geotools trunk.
* doing something and hoping that someone else will integrate it
"properly" will never happen.
* Highly encourage people to "work together" since, in the long run, its
less work.
Dave
PS. Paolo (and whomever else), whats your time frame for what you're
doing?
----------------------------------------------------------
This mail sent through IMP: https://webmail.limegroup.com/
