Would it be possible to have an Implementation Erratum section on the TC
website to track this sort of thing. Its fine to take such a decision
on the basis that "The Spec is silly", but it does need to be broadcast
for the attention of the userbase. At the very least it will curb
future buzilla noise from this direction and kill any user angst about
the subject of "Exactly which spec does TC support".
Maybe each case can have its own page detailing:
* Summary of the situation.
* What the specification says should happen. The TC developers
interpretation of what the spec means to TC and realworld apps.
* The technical argument why the specification is not practical or not
useful in the realworld.
* Affected versions of TC.
* Any details on the specification committee being notified to allow the
subject to at least be brought before other interested parties of the
respective JSR.
* Workaround ideas that might help someone trying to get back to the
specified behaviour to make their app work again.
* Related Bugzilla Entries. Although negative publicity about the point
maybe undesirable.
No one can then complain in the future about any deviation from the spec
is formally documented. Otherwise what does TC become if you can't cite
some level of interoperability with any confidence.
Of course blame the system and of course recommend a more constructive
approach when doing so.
Finalizing the design of any computer system in the specification stage
does not seem like sensible practice. Getting an agreed written
specification is a good start, but there should be a further process
before a final revision is closed and that should only happen after at
least 2 or 3 parties involved have implementation it and reported back
to the group on their concerns when doing so. Which then allow further
revisions and corrections to take place.
Darryl
[EMAIL PROTECTED] wrote:
http://issues.apache.org/bugzilla/show_bug.cgi?id=39503
[EMAIL PROTECTED] changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |WONTFIX
------- Additional Comments From [EMAIL PROTECTED] 2006-05-07 00:08 -------
I am totally opposed to fixing this, which has to be an obvious specification
issue.
The last part is invalid (getRequestUri will return what you gave to the
dispatcher).
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
