Comments below...
On Mar 28, 2006, at 3:35 PM, Allen Gilliland wrote:
David M Johnson wrote:
On Mar 28, 2006, at 1:08 PM, Allen Gilliland wrote:
now that i think about it, maybe it is not a good idea to squeeze
this in at such a late time in the release process.
I see that last point, but these changes are isolated to two
Servlets, don't impact any existing features and are disabled by
default.
yes, but the moment they go out in a release we are required to
support them forever, so we had better be sure about it.
I totally disagree with that. Nothing obligates us to support this
forever. And specifically for the Atom protocol, people are going to
target Atom protocol 1.0, not draft 8 (which is what we now support).
The folks who target draft 8 are the folks trying to help IETF get
the protocol right (i.e. the folks in the working group).
I would not propose moving out of the sandbox if I didn't think Atom
protocol was stable, very near complete and ready for serious interop
testing.
It would be helpful and much more convenient for me and other
folks working on this stuff to avoid the custom build setup. I
really don't think there is a downside here.
i know that's a pain, but that is not a reason to move code out of
the sandbox.
so, after taking a closer look at the code i think everything looks
fine, but i am still -1 on committing this to the core codebase
right now for 2 reasons.
1. as i said before, i think it is a little late in the release
cycle to just be throwing this in. any code that we put in a
release we are responsible for, so i don't like the idea of putting
this code in the release if we think it's still experimental and
want to keep it low profile.
I disagree with that too. I probably should not have used the word
experimental.
I want to get interop testing on Atom protocol and interop testing is
part of the development of the IETF Atom protocol itself. It's harder
to get people to do that testing if they have to create a custom
build to participate.
2. more importantly, i think we should think more carefully about
the servlet endpoints we choose for these services. we are
planning to reform the roller url structure for Roller 3.0 and i am
just about to send that proposal out to the dev list. since both
atom services introduce new urls which will be affected by this
change i think it's better not to rush the decision to put them in
the core codebase.
We don't have to stick with the end points we have now, so I disagree
with this too. There are only two endpoints here, one for Atom and
one or Admin. All other URLs are discovered at runtime. Changing the
endpoint URLs is really no big deal.
I disagree with each of your objections, but I'm not going to call
for a vote on this yet because of the timing. I'll respect this as a
veto. Thanks for taking a closer look at the code.
- Dave
