Hi,
On 8/15/06, Bob Scheifler <[EMAIL PROTECTED]> wrote:
I'll try again. It seems we're discussing three different things:
1. development of code
2. development of specs
3. running a standards process
My concern is about #3, and not trying to do it in an ASF project.
My reason is simple: there aren't people willing to do it.
I'm guessing that others in this discussion have been focused on #2,
and/or are tying #2 and #3 tightly together. Perhaps differences in
what we each mean by "specification" is causing mutual confusion?
I think the difference in how the Jini specs are seen is the key issue
here. Quite a few of the Java projects in Apache are implementations
of external specs, so bringing in a project that essentially defines
its own specifications raises some questions especially since the
specs were managed by a process and are stated to allow independent
implementations.
Stretching quite far to make a point; we don't expect for example the
Lucene project to branch a separate spec project to allow independent
implementations of the Lucene API.
I think the question boils down to the issue of what will happen to
the Jini standard now that the JDP has been closed down. It's correct
to insist in that the standard shouldn't be developed within the
implementation project if the goal is to allow independent
implementations. Thus, there are two options:
1) It is decided (by what community?) that there is no need for
independent implementations, in which case bringing in the project
with both the implementation and the specifications under the name of
"Apache Jini" would make sense.
2) Independent implementations remains a goal for the Jini standard,
and a suitably independent body (be it an Apache project, a real
standardization organization, or whatever) is chartered for the
maintenance and development of the standard. In this case we bring in
the JTSK (+ related tools) implementation as an "Apache Something"
project that focuses on the implementation of the externally defined
standard.
I'm personally in favor of option 2, but at this point I think it's
premature to decide what to do with the Jini standard.
BR,
Jukka Zitting
--
Yukatan - http://yukatan.fi/ - [EMAIL PROTECTED]
Software craftsmanship, JCR consulting, and Java development
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
