Moving forward with the discussion about the code being "proof of concept".
By "proof of concept" I don't mean that the code is bad, I mean that it's a
stage
where it proofs the concept but it's not ready to be integrated in a code
based that was meant to become stable soon, simply because it's last minute
(last minute changes are rarely good) and imcomplete.
This one is mostly about what's happening above the catalog.
Right now we have some exemplar use cases, which have been indeed picked up
with care.
However they are only three, that's my biggest worry, I'm pretty sure that
by
developing the full switch you might have seen more use cases and found more
bugs in the implementations.
Now, in order to reap the benefits of the scalable API one has to make the
code
actually use the new scalable methods whenever large amounts of data is read
from the catalog, meaning switching also most other capabilities documents,
the Describe* methods (most of them can take no layer/coverage/feature type
identifier and describe the whole server as a result), the GUI, I guess
some parts of RESTConfig.
Now, let's say we commit the proposal as it is now, with only the exemplar
cases.
You argue it is done to minimize the risk. I say the net effect is that
it actually makes it way too easy, if not natural, to do all of the above
work outside of the proposal framework with little scrutiny, because
everything
related to scalability is turned to "bug" or "improvement" jiras,
forgetting that
these jira wire up with code that is not as well tested as the rest, and
thus
put us at risk of getting something fundamentally broken while we are
doing bugfix releases.
So in the end the same amount of work gets done in the 2.2.x series, but
with
very little scrutiny, and the proposal looks less scary because it changes
less
code. Seems like a trick, that's why I called it the "trojan horse".
Even if you "promise" not to do any of these changes in the 2.2.x series the
fact remains that these changes are getting in very late in the game, after
3 months since I asked to start the release process and was told to wait
"two weeks".
As much as you feel my feedback is unfair, try to put on the other plate of
the
scale how much unfair it has been already for me.
I'd much prefer to see the work done in a new trunk, done fully, done well,
and eventually be backported later if we don't find a compromise on timed
releases.
Again, this is negative feedback but I don't want to be a show stopper, if
everybody
else feels the proposal should go on I'll vote -0 on it.
Cheers
Andrea
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
