www-jcp-open mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sam Ruby" <ru...@intertwingly.net>
Subject Re: Handling Innovation and Producing an RI
Date Mon, 17 Mar 2008 14:22:37 GMT
On Mon, Mar 17, 2008 at 7:23 AM, Geir Magnusson Jr. <geir@pobox.com> wrote:
>
>  On Mar 17, 2008, at 7:17 AM, Steve Loughran wrote:
>
>  > Endre StĂžlsvik wrote:
>  >
>  >> Can this be easily copied in other projects? Do one have the
>  >> dedication from the dumpsters to pull this through, as one has
>  >> _had_ with Sun on Tomcat? .. or the dedication from other vendors,
>  >> having full-time employees basically owning the implementation, as
>  >> JBoss on Tomcat?
>  >> It most definitely didn't work with IBM on Pluto, IMO.
>  >
>  > I think the issue is not so much RI as general code quality.
>  > Sometimes companies, to great PR, donate truckloads of source to the
>  > OSS world, including to apache, but neglect to include a single line
>  > of comment on it. Because in the closed source team, there was
>  > always fred who understood the database module, and sarah who knew
>  > the networking side of things. Whenever you had a problem, you knew
>  > who to walk over and ask.
>  >
>  > In the OSS ecosystem, any project that is only understood by a group
>  > of developers who work for a single vendor, is at risk of the vendor
>  > changing their plans on a whim. I actually think JBoss is different -
>  > they are committed to Tomcat and their stack- but again, in Axis1.x,
>  > a lot of the original IBM axis team suddenly got repurposed to deal
>  > with internal crises, and others had to (eventually) step into the
>  > gap, but even there there whole swathes of code we were scared of.
>  >
>  > At least with a TCK-driven project, you have a test kit that is the
>  > effective specification.
>
>  That's not always the case - there are many instances where tests in
>  TCKs are challenged because there are implementation assumptions built
>  in that can conflict with other spec-complaint implementations.

Glen Daniels would likely find statements that Axis 1.x was dominated
by IBM to be amusing.

And to back up Geir's point: Axis 1.x did generate a number of
successful TCK challenges.

The TCK was effectively a second test suite, an adjunct to the one we
already had at the time.  It uncovered a number of bugs.  In the
initial runs, if memory servers, the largest set was simple Axis bugs.
 Not JAX RPC compliance issues, but bugs of other sorts.  These second
largest set was JAX RPC issues.  The remainder (and smallest set of
the three) were TCK issues.  An example of the latter was that SOAP
does involve HTTP headers, and HTTP headers have a number of options
in the way that they are expressed (e.g. quoting).  The TCK at the
time made a few simplifying assumptions in areas such as these in ways
that weren't warranted.

Given how hard it was to challenge the TCK, in some cases we simply
complied instead.

- Sam Ruby

Mime
View raw message