We've had some good and spirited discussion on the JiniProposal
over the last couple weeks. Thanks to everyone who chimed in with
your thoughts and opinions.
In reviewing the discussion again, I think we can focus on three key
items which seem to be at the root of some debate. For each item, I'll
try and propose a path forward and we'll see where we go from there.
Thanks again, and we look forward to your review and response.
-Jim
------------------------------------------------------------------------
----------
1) "specifications" / API docs
It appears that there are many (valid) lenses in which to view
the specifications question. I'd rather not reintroduce all of the
different perspectives and proposals, but rather focus on one
that we believe is acceptable to the Jini Community, and hopefully
will be to Apache.
We would like to include the API docs ("specifications" seems to
be a loaded term, with many different definitions and assumptions
tied up in it) in the project. Many of the API docs are generated
directly from the code (Javadoc), but would be made available
as a separate download within the project. These would not be called
"standards". They would be called "Jini API documents". They
are intended to clearly define the APIs and semantics that are
implemented as part of the project. Outside parties certainly have
the right, and are welcome to use those docs to create alternative
implementations - but that is not the predominant reason for producing
the docs.
The process used for introducing a change to the API docs would
be developed by the <project> PMC and committers. We'd expect
it to follow a similar process to proposed code mods, with the
added responsibilities of making them visible to the overall
Jini Community through the project email lists, and having
open discussion and debate. We'd expect that the Community
feedback would heavily influence the work performed on the
API docs.
The (perfectly reasonable) suggestion on creating a separate
project for the governance of the specifications is not viable
as we do not have the volunteers to run another project, nor was
the intention of defining a specifications process within Apache
something that the initial committers of our Proposal wanted or
can satisfy.
------ ------ ------ ------ ------ ------ ------
------ ------
2) Java package names (namespace)
There are two namespaces that are part of the Proposal that
have been discussed:
* net.jini.* -- this is the primary Jini namespace defined in
the API docs, and chiefly for compatibility reasons with existing
implementations and applications, we can not change this.
* com.sun.jini.* -- there are also some compatibility issues
associated with changing this namespace in the implementation,
but we understand the reasons for wanting to change this to
org.apache.<projectname>, and would do this as part of
the incubation phase of the project.
------ ------ ------ ------ ------ ------ ------
------ ------
3) project name
There is some pretty strong sentiment within the Jini Community
for keeping the "Jini" name as part of the Apache Proposal. Our
overall reading, however, is that given the scope of the project
proposed and other technology sites (jini.dev.java.net, Jini.org)
on the web, that the name would not be acceptable to Apache.
We, therefore, are open to discussing a name change to something
else within the Jini Community.
If there's agreement on the positions stated in 1 and 2 above,
we'll assume there's general support for our Proposal to Apache
and begin the name discussion in the Jini Community.
------------------------------------------------------------------------
----------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
