JIni Proposal
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 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., 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]
Re: JIni Proposal
On Wednesday 23 August 2006 03:18, Jim Hurley wrote: > 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. Isn't it a bit odd to keep net.jini (which I think is essential for compatibility reasons), and not have Jini in the name of the responsible body of those?? Cheers Niclas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JIni Proposal
While we continue to look forward to your review and
response ;-) thought I'd mention a Jini event coming up
next month:
*
Tenth Jini Community Meeting
Brussels, Belgium
September 13-14, 2006
*
* Session Abstracts:
<http://www.jini.org/wiki/10th_JCM_Sessions>
* Schedule:
<http://www.jini.org/wiki/10th_JCM_Agenda_Day_1>
<http://www.jini.org/wiki/10th_JCM_Agenda_Day_2>
It would be great to have Apache members there. The meeting is
open and free, and all interested developers are welcome.
We are hoping to provide an update on our "Jini" Proposal at
the meeting (the "Update on the Community" talk on the first
day is a placeholder whilst we get a better understanding on
where our Proposal sits with the incubator).
thanks -Jim
On Aug 22, 2006, at 3:18 PM, Jim Hurley wrote:
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 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., 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.
--
---
Re: JIni Proposal
Niclas Hedhman wrote: On Wednesday 23 August 2006 03:18, Jim Hurley wrote: 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. Isn't it a bit odd to keep net.jini (which I think is essential for compatibility reasons), and not have Jini in the name of the responsible body of those?? It might seem odd Niclas, but I have the impression that we (the group of initial committers) felt that dropping the name Jini for a TLP was required as 'concession' to proceed with the Proposal. The response so far on Jim's 'patches' is minimal leaving us a bit in the dark I guess. I can't say I sense a form of consensus here, especially with regard to #1 and #2, so that we can resolve #3 and seek for the Sponsor to proceed (if my understanding of the process is correct). So far we have seen concerns raised with regard to Jini as project name, and there were not that many ASF people that indicated this was no problem as reaction to that. I believe there is some misunderstanding about the Jini technology here at incubator and how one should perceive our key characteristics. I can completely understand that as we've done things differently for a very long time (since 1999), those relative new in our community also often have problems grasping it completely. I believe Jim's 'patches' represent what is still acceptable by the Jini Community as we have discussed in the past and recently. We can't bend our technical foundation in a way that would be considered more mainstream, but we try to adapt in a way that meets the (as Jukka pointed out) "social or perceptional" characteristics of the ASF (assuming there is a single one). And, with my Jini Community Member hat on, it would be really nice if we have an indication of light at the end of the tunnel. The license change to ALv2 for the Jini Technology was one that took very long and with a huge impact for us all, this step will likely bring even more uncertainty. We have some 'turmoil' behind us. It would be nice if the Jini Community for which the ASF project is intended to be the "water cooler" can focus on the technical and social challenges ahead instead of waiting for what will be next. BTW it hasn't been mentioned yet but September 13, 14 we have our tenth *free* Jini Community Meeting in Brussels, see http://www.jini.org/wiki/Category:10th_Jini_Community_Meeting for more details. It is a great opportunity to learn more about the Jini Technology and our greater Community. And it would be really a joy if we could report about where the "water cooler" ends up ;-) -- Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JIni Proposal
Hi,
On 8/22/06, Jim Hurley <[EMAIL PROTECTED]> wrote:
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.
OK. So the scope of a revised proposal would be broader than just the
implementation of existing standards. I'd be happy with that, and even
with keeping the Jini name based on the expressed views of the Jini
community. The Apache Jini project would be more like the Cocoon or
Lucene (just to name a few) projects that define their own interfaces
than projects like Tomcat or Xerces that implement an externally
defined interface.
* 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.
I don't see any problem with 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., and would do this as part of
the incubation phase of the project.
I think it should also be possible to place some compatibility classes
in com.sun.jini.* that can either subclass or act as proxies to the
respective classes in org.apache..*.
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]
Re: JIni Proposal
Hi, Is anyone opposed to the proposed Jini project being called "Apache Jini" after the latest comments from the Jini community? They are essentially saying that it would make most sense for the project to maintain it's own specifications, and thus be "the" Jini implementation even though there is nothing stopping external projects from implementing some of the core components. I tend to agree with them that the name issue was at least partly based on a misunderstanding of the nature of the Jini technology and standards. I also acknowledge and support the Jini community's strong desire to keep the name. Unless anyone objects to the name, I think the way forward is to revise the proposal to meet Jim's points 1 and 2 before proceeding to vote on accepting the project. If "Apache Jini" is still considered inappropriate, then the next step for us and the Jini community would be to come up with an alternative name for the project. 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]
Re: JIni Proposal
On Wed, Aug 30, 2006 at 11:57:46PM +0300, Jukka Zitting wrote: > Is anyone opposed to the proposed Jini project being called "Apache > Jini" after the latest comments from the Jini community? AIUI (haven't followed everything closely): 1) the people involved understand all the potential issues involved thoroughly now and really want to do it this way 2) Apache gets the trademark so there's no big legal worry so no objections. I'll just note the SpamAssassin people went through trademark ownership transfer in the past so any details on what needs to be done on our side, one of them will probably know. LSD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
