Re: [Proposal] Jini Project
Niclas Hedhman wrote: On Wednesday 21 June 2006 19:19, Leo Simons wrote: What I'm missing is an idea of the interaction between jini.org and this proposed new apache project, and an idea of the interaction between the JCP process and the apache project. Eg is the apache project a (reference?) implementation of a bunch of JCP specs managed through jini.org (in which case I'd say it needs a new name), is it a 'full' move from jini.org to jini.apache.org, or something else? It has been discussed that jini.org will serve as a "information portal", with links to docs, specs, implementations, the starter kit, and so forth. The Apache project will first be the center of coding of the starter kit, and other useful generic tools. It has not yet been decided what exactly should happen to the specifications and related process (JDP). Many people like the JDP, but also recognizes the overhead needed to keep it running. One alternative that has been discussed is to let the Jini TLP manage the JDP (with a couple of amendments) as well. I think it is good to mention there is a distinction between specifications and standards in the Jini community. Most of the Jini related specifications were developed by Sun in a way that allowed input of others, but Sun was the sole entity that made the decision about what went into these specifications. The Jini community has a democratic process (JDP) that provides balance between commercial and individual stakeholders and to which people could submit their specification to have that blessed as a community approved standard (all got accepted so far, so Sun did apparently well). The initial goals of Jini can only be reached if compatibility is high on the agenda of everybody involved and standards were a way to achieve that, in the past there was even a license that commanded compatibility but that one has been replaced by the Alv2. Also at the start of the Jini community in 1999 it was thought of that a democratic process such as the JDP was the best way to ensure that all stakeholders could have their say in whether some specification would be approved as standard and that it would unity us instead of divide. Bringing the Jini specs (the community approved standards) into an ASF project without a JDP like process can IMHO be seen as monopolizing what is perceived as Jini. Whether that is a good thing or a bad thing is up to the reader ;-) My personal stance is that it is an issue that is not urgent, and can be discussed through incubation. I disagree here, some people in the Jini community find it important to know in advance which way this is heading, e.g. to hedge their risks using or investing in this technology and determine their own future path. -- Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] Jini Project
Bob Scheifler wrote: Leo Simons wrote: I guess this means keeping jini.org around for a long time to come, and I think this means you need a name for "[EMAIL PROTECTED]" which is not "jini" :) Could you expand on why you think that? Thanks. Maybe it is also good to emphasis that Jini is a technology and not an end-product. Sun provides an end-product called the JTSK (Jini Technology Starter Kit) that is an aggregation of what is described in the Jini Architecture (http://java.sun.com/products/jini/2.0.2/doc/specs/html/jini-spec.html) and that implements many of the community approved standards. I've no idea yet about the deliverables we end up with, but I assume these will be released under a different product name. So I think one should see the name Jini on par with e.g. the XML TLP that aggregates many XML related technologies. -- Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jini?
Matthias Wessendorf wrote: I think they ended up at java.net (see [1]). Last week or so I saw that and was wondering myself, b/c of the proposal here. Hi, The current distribution of the JTSK (the Jini Starter Kit) has shown up at java.net but that had to do with the old jini.org website closing down and the requirement to make the distribution available ASAP. This has nothing to do with a change of objectives from our side. The Sun people have been discussing with their trademark people how to deal with the Jini trademark (as many of us feel that it would be the proper name to maintain) and that has slowed down things considerable. We also found out we had another trademarked name (ServiceUI) as part of the proposal. We had some discussions 'in private' how to deal with this [1] and concluded last Friday to proceed this in [EMAIL PROTECTED] I expect Jim Hurley to follow up soon as he represents the owner of the trademark. [1] which by now we understand is the biggest crime one can commit here ;-), we just didn't understand that it was policy to have these type of discussion in public. It was not because we didn't want others to become involved. -- Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jini?
Sanjiva Weerawarana wrote: I know changing the name is a *really* tough thing for Jini. However, is Jini a *technology* or an *implementation*? If its the prior I'm afraid our current guidelines are not to do technology names. I understand for those not very involved with the Jini Technology it is hard to pinpoint what Jini exactly is and why some of us are willing to go through great lengths to take this name with us, so let me try. First Jini is a Technology, but with an extra handicap as the borders where Jini begins and ends are not very well defined, even while in 1999/2000 there was already a document that described the Jini Architecture and the Jini Technology Core Platform. It just lacks a clear definition, when you ask 10 people to describe Jini chances are high that you will get 10 different answers; some that will make you happy or smile, and some that make you foam with rage ... Many consider the implementation of Sun JTSK (Jini Technology Starter Kit) as being 'Jini' but this is not correct (if you would ask me) and while the proposal mainly centers around their code the proposal also includes another Jini Community Approved Standard, namely ServiceUI (the other trademark involved). What is part of this proposal are most of the Jini Community Approved Standards and the IMHO 'sad' thing is that the Jini Decision Process that ratified these specifications as community approved standards ceased to exist. Sun is no longer willing to provide the Executive to run the process and there are not enough people in the community that want to take it over (read don't want to spend time on it). The current owner of the Standards also doesn't believe they can get accepted as JSR in the JCP based on experience with some of the specifications that ended up as Jini Standard while they should have become J2SE specifications in the first place. The net result is that some really important Jini Community aspects [1] (the Standards) we all circle around are part of this proposal, and if we can stay clear of forks it should be seen as the foundation on top of which the rest of the Jini community will build their own stuff. [1] as Jim mentioned the new http://jini.org/ is another aspect of the community and is there for everything one could see as Jini related (really open ended), http://jini.dev.java.net/ should be seen as the yellow pages with regard to Jini related development projects and news around that. Renaming the Technology itself would be suicidal in my opinion as there are dozens of people/companies that develop products/specifications on top of 'Jini' so it would be harming them too. Of course it would be possible to give the TLP a different name, but then again almost every sentence would have a reference to the Jini Technology for which I guess nobody could say where the 'Jini Technology' itself lives. Given the fact the ASF project would be closest to defining the 'Jini Technology' I think it is good to emphasize this by the name of the TLP. IANAL and have no idea what the impact would be of handing over the Jini trademark to the ASF, how the ASF will deal with other communities that have Jini in their name, or other specifications that have Jini in their name. I'm reluctant to say this given the fact that Sun has to protect its trademarks, but I have the feeling that Jini has become rather generic in the past years. People say I wrote a Jini service, I developed a Jini Service Container, I do Jini, it is the Jini way, etc. I also don't understand the implications of abandoning the trademark itself, but I would like to see that Jini can be used in the future as it is today, even when it makes your mouth foam. To summarize as *I* see it at this very moment: - Jini is not a product. - Jini can't be used as a noun. - Jini in combination with another noun could serve as a specification name for which one can have multiple implementations, such as 'Jini Helper and Utility Classes', 'Jini Platform', 'Jini Service Container', etc. - the deliverables of an Apache Jini TLP should get their own distinct name without Jini in it, except when it represent a 'Jini ... Specification'. - Jini itself only represents the magic of doing distributed computing in a proper way and comes in a lamp, these are already hard to find these days so please don't make it even harder :-) I would like to know whether people object against using Jini as name for a TLP based on the above reasoning. I think for the discussion it would be handy to tackle the appropriateness of the name first before we deal with legal issues, as I guess that most people here have the IANAL prefix, just like me. -- Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jini : Separate Governance and Implementation Projects
Jim Hurley wrote: On Aug 15, 2006, at 4:46 PM, Jukka Zitting wrote: I'm not convinced the goal in the past was to have multiple implementations, vs allowing multiple implementations. I think the interpretation of this goal underlies both the naming and standard issues. In essence, does the Jini community see the project being proposed as *the* Jini implementation or as *a* Jini implementation? Hi Jukka- I'm not going to try and pull a Bill Clinton with "it depends what the definition of "is" is" but I'd answer that I believe the Jini Community views the project as *the* Jini implementation. But *the* as in: "the main", "the original", "the most prominent", (what will be) "the Community's implementation", and "the one you'd recommend a developer go grab to get going with Jini". But not *the* as in "the only". I view it as being/becoming *the* Jini Community's touchstone (or main commons). Correct, as an example I'm the lead for the Jini Service Container called Seven that is based on many of the proposed specifications and implementations and builds on top. And while I don't re-implement the specifications I've created many derivate works of the proposed code. Some of that flowed back into the Sun codebase or likely will in the future, some won't such as re-implementations of many of the Jini services, but "specifications wise" these are still compatible. And as Dan explained for many of the (service) specifications there are already multiple implementations but with oh some many code from what is proposed here. But then again many of these reimplementation is not what I would define as "Jini" if I was pressed to describe it as a noun ;-) And as Bob explained "depending on how the ASF project evolves Jini may become easier and more synonymous with the specs and/or code produced by the project", with the exception that where he uses "the specs produced by the project" I would be inclined to say "*some* of the specs produced by the project". Or to be more explicit I would like to see a Jini Platform to be established, similar to the J2EE Platform, so that where people could say "I wrote a J2EE application" we can say "I wrote a Jini service" and that would have a meaning by the majority of the Jini Community. -- Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jini : Separate Governance and Implementation Projects
Bob Scheifler wrote: There are definitely people in the community that want to see the existing Jini community process maintained for approving standards. I used to be one of them. But, when we've looked for volunteers committed to running that process, there are very few takers. I was one of those few volunteers, and maybe even more important most people expressed they didn't see the need for "blessing" specifications as Standards given the circumstances. They seem to be happy with the way how Sun interacted with the Community with regard to their specifications in the past years. I believe it is their expectation, and I hope they are right, an ASF project will function in a similar way with the added benefits of the Open Source dynamics found here at the ASF. A few weeks ago I was not in favor of managing the specifications as part of the same ASF project but given what the Jini Community seems to want I changed opinion and decided it is better to spend my energy in mentoring new developers with the core principals part of the current Jini specifications and implementations instead of maintaining a process that not that many seem to have interest in at this stage for the Jini technology. So I guess that means I can't support Geir's proposal as it is not in line what I and the larger part of the Jini Community want. This is a pretty important step, probably equally important as your decision to use the Apache License for Jini. I don't want to impose any arbitrary barriers to acceptance into the Apache incubator, but I'd like to see a wider discussion of abandoning the "standard". To my mind the wider discussions have already taken place within the Jini community. At some point, I stop wishing for what could be in theory, and start executing on what I think can be in practice. My feeling too. While I can understand the discussion came to this point I also feel that we are deviating from whether "Jini" is an appropriate name for the project. A few raised objections for reasons that IMHO are not always *that* clear based on the answers given to Bob's questions. Assuming it is legally allowed to use the name Jini I can't see why "Apache Jini", "Codehaus Jini", "Jini Community", etc. would be problematic especially as the "Apache Jini" project seems to have multiple deliverables such as *various* Jini Specifications, implementations of these specifications and additional tools targeted at the development of Jini services. The usage of the name Jini implies to me all these projects do something Jini Technology related, so yes it is likely intended to define an "umbrella" or category, but based on the above isn't that what is proposed? I think I've spent already a few hours trying to find the right sentences to explain why the name Jini (if legally allowed) would be in the interest of us all, but after writing large pieces of text that have been deleted straight away I just can't seem to do that in a positive way that won't raise more questions. So as a last resort I'm going to try to do it the other way around, so already my excuses to the other committers if I make things worse. To be very blunt what is proposed here is that the ASF project is "monopolizing" Jini ... in the interest of the larger Jini community. This might seem a contradiction but this is how people in the Jini Community seem to want how we deal with our current process, most specifications and implementation. They just don't want to spend much energy in a Jini Decision Process but the majority want to separate specifications from implementations that was one of the fundamental principals by the Sun team that is responsible for almost all of the Jini Specifications. They want these specifications to be in the net.jini namespace where they are right now, not only because of the migration hell they would otherwise be confronted with, all the documentation/books that become useless, etc., but also because that namespace would imply stability, opposed to a namespace org.apache.jini that is likely more subject to change. That means that the committers of the ASF project will debate what should end up as specification (net.jini namespace) that allows for multiple implementations and what ends up in the org.apache.jini.xxx namespace. The major difference with the past situation is that there is no way to 'correct' what ends up in the net.jini namespace by the larger community, but, as I said before, that is what they want. And I have confidence (based on past experience) that the group of committers is willing to listen to any argument of those that have no formal say in the ASF project. And maybe when Jini gets wider adoption we could submit part of the net.jini namespace to another standards body if that would be in the interest of the wider community. I would be saddened if we can't maintain "Jini" as project name, but if it has to become something like "Genie" would it still be possible to do the following: - Create
Re: Jini : Separate Governance and Implementation Projects
Mark Brouwer wrote: I would be saddened if we can't maintain "Jini" as project name, but if it has to become something like "Genie" would it still be possible to do the following: - Create various specification deliverables that are of the form "Jini bla bla bla Specification/API". - Specifications/API in the net.jini namespace. And remember that there is no body outside the ASF project that defines those specifications, that is the job of the ASF project. Anyone? -- Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jini : Separate Governance and Implementation Projects
Niclas Hedhman wrote: On Monday 21 August 2006 03:24, Mark Brouwer wrote: I would be saddened if we can't maintain "Jini" as project name I think Mark has put it rather well. The Jini community want a water cooler to gather around. Brilliant :-) -- Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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: [VOTE] Incubate new podling, "River" (nee Braintree, nee..., nee Jini)
+1 , glad we have come to this point. -- Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
