river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sam Chance <sgcha...@gmail.com>
Subject Re: Jini.org
Date Fri, 26 Jun 2009 16:18:57 GMT
That's a very emotional reply. :-)  I don't share the same "IBM domination"
view.  One can kick and scream, but the fact remains that the largess is
moving to or has already moved to OSGi.  Sorry.

You can stay on your path but you will increasingly find yourself an
outlier.  It's a high risk, high reward proposition.  The customers I
support use IBM, Oracle, Sun, Red Hat, SpringSource, TIBCO, etc.  They also
use open source things like FUSE, Jetty, Tomcat, Apache _____, etc.  Most,
if not all, are going to OSGi or are already there.

Your assertion that "OSGi from the outside doesn't seem to be "adding"
anything... [you] need..." suggests you may not fully understand it.  I
could be wrong.  OSGi is certainly not a competitor to Jini, but rather an
exceptional complement. Further, your own "interests" suggest you would
embrace OSGi and SCA.

Anyway, my aim is not to convince, but rather illuminate.


On Fri, Jun 26, 2009 at 11:39 AM, Gregg Wonderly <gregg@wonderly.org> wrote:

> As statement of my perspective...
> IBM leads the OSGi thrust, and the bad taste that I got from IBM/Eclipse
> doesn't leave me feeling excited about doing anything to "work with" IBM.  I
> found it to be impossible to "work with" eclipse developers.  They insisted
> it was their way or the highway.
> I am interested in simple software assembly techniques.  I am interested in
> manageable software systems.  Currently, I have no problems getting all of
> this out of using Jini and the power of the Java ".jar" mechanisms and
> dynamic class loading features of the language.
> OSGi from the outside doesn't seem to be "adding" anything to the features
> that I need.  I currently use netbeans, and not eclipse.  I currently don't
> have a software development system nor a server deployment system based on
> OSGi.  So, I don't have an easy road to using, trying or developing in the
> OSGi "way".
> The divisions in systems that developments like OSGi create, are not near
> as helpful as they could be if OSGi developers would snuggle up with others
> in the industry already doing such things.
> From my perspective, the lack of IBM/OSGi knocking on the door, and the
> lack of there being netbeans plugins and other more "ever present" OSGi
> "stuff" visible in day-to-day Java news, really tells me that IBM is once
> again, like Eclipse, on the path of "Our way or the highway", trying to not
> work with anyone else. NIH seems to be the name of the game, and they will
> either steam roll everyone into submission, or they will fail because such a
> huge wall gets built up around them, that they can't get through.
> The absolute panic that the Java community was in when it looked like IBM
> might buy Sun, I believe, speaks directly toward similar feelings, to mine,
> being present elsewhere.
> I'm not saying that I should have these feelings, but I'm just laying my
> biases out so that it is clear where I'm coming from.
> Gregg Wonderly
> Sam Chance wrote:
>> I'm "pleasantly stunned" to hear someone mention OSGi in this list. OSGi
>> is
>> effectively the norm for Java modularization and all the other things that
>> come with the standard.  All the big guys are migrating or have migrated
>> to
>> OSGi as there internal architecture. (See [1], [2], [3])  Distributed OSGi
>> (RFC 119) and OSGi in general exhibits *many* analogies to the Jini model.
>> I do mean "many".  It's a missed opportunity that Jini/River has not
>> embraced OSGi and sought to be the de facto standard for [managing]
>> Distributed OSGi.
>> Jini was touted to be "all things distributed." OSGi is going to be the
>> common denominator across Enterprise, Mobile, Residential, Automotive and
>> other sectors. What better choice is there than Jini/River to be the
>> distribution element to create the seamless interoperation of OSGi bundles
>> (i.e. services) for intra- and inter-sector interoperation? Jini/River
>> could/should power the upcoming "wave" of convergence across all the
>> sectors.
>> To the best of my knowledge, only Paremus has seen the vision and began to
>> implement it (See [4]). Their runtime fabric is fully autonomic,
>> decentralized and dynamic.  It features no single point of failure and no
>> single point of control.  It's also a self similar architecture, meaning
>> it
>> eats its own dog food!  The runtime manages OSGi bundles and the fabric
>> services are also OSGi bundles. It uses Service Component Architecture
>> (SCA)
>> to assemble bundles into systems; and yes, the fabric bundles are
>> similarly
>> wired together using SCA to form the fabric services.
>> As a disclaimer, I get nothing for extolling the Paremus fabric!  But as
>> far
>> as I know it's the only one!  What a vision!  Yet, no one in this
>> community
>> - to the best of my knowledge - even considers OSGi as a managed artifact
>> or
>> an organic aspect of Jini/River.
>> [1] http://www.osgi.org/wiki/uploads/News/2008_09_16_worldwide_market.pdf
>> [2] http://www.osgi.org/wiki/uploads/News/2009_02_24_OSGi_Emerging.pdf
>> [3] http://www.osgi.org/wiki/uploads/News/2009_02_12_100Members.pdf
>> [4] http://www.infoq.com/news/2008/02/infiniflow-12
>> Thank you!
>> Sam
>> On Fri, Jun 26, 2009 at 6:23 AM, Peter Firmstone <jini@zeus.net.au>
>> wrote:
>>  I'll contribute too, let's get that Paypal account going, what a good
>>> idea
>>> ;)
>>> I've recently spent some time going over some of the content on
>>> jini.organd feel strongly that key information there will assist us with
>>> River's
>>> future, both technical and philosophical.
>>> I've listened to the speeches in JCM more than once and still find the
>>> information relevant.
>>> There is too much opportunity and potential left for us with River to let
>>> it die, if anything I think that the shortcomings of Java have held us
>>> back
>>> to some degree, namely classpath, jar, the complexity of security and the
>>> challenges of the internet.  It'll be interesting to watch how the OSGi
>>> and
>>> project Jigsaw evolve and see if there's potential to use relevant
>>> pieces.
>>> I've been thinking that rather than transferring whole jar files via
>>> classfile servers, versioned classes, individually compressed on demand
>>> (using caching with deflate compression and nio byte buffers) to speed up
>>> code transfer over slow networks (provided your not using whole package
>>> imports) and provide greater flexibility if required.  Furthermore,
>>> individual classes can evolve and exist alongside legacy copies, if they
>>> can
>>> be versioned.  There are other issues in doing so, however, such as, when
>>> to
>>> evolve a class with a new version, much like the versioning issues with
>>> serialization.  That would of course require OpenJDK7.
>>> But first we must make it easier to participate, I think that the current
>>> focus on changes to the build and testing structures will help us grow,
>>> we
>>> must continue to do so while preserving the past in order not to forget
>>> important lessons or repeat old mistakes in the future.
>>> N.B. Thank you very much Jim Waldo, for going to the trouble of
>>> retrieving,
>>> getting approval for and uploading very relevant documentation.  And for
>>> inspiration...
>>> Cheers,
>>> Peter.
>>> Greg Trasuk wrote:
>>>  On Thu, 2009-06-25 at 14:42, Sam Chance wrote:
>>>>  Wow! This whole topic is scary. I know factually Jini is still
>>>>> relevant in certain places. I don't want it to die, personally.
>>>>> Is there an easy way for individuals (like me) to acquire the content
>>>>> on jini.org?
>>>>> Can we set up a fund or account using Paypal? This would allow us to
>>>>> individually contribute, as long as a trusted agent disperses funds to
>>>>> pay the bills.
>>>>> Also, can we change the wiki model to a controlled access site? Casual
>>>>> visitors get read-only rights. Others may apply for write-enabled
>>>>> accounts.
>>>>> I am willing to pay the bills as the trusted agent, if the group is
>>>>> willing to allow me.
>>>>> Just don't let it die.
>>>>> Sam
>>>>>  I agree.  Don't let it die, and I've always thought that Jini should
>>>> have an identity apart from River.  I very much like the idea of a
>>>> Paypal donation page.  Does anyone know how to do that?  If there were
>>>> sufficient funds donated, it would be great to setup some sort of entity
>>>> to hold the Jini trademarks and own the domain.
>>>> Cheers,
>>>> Greg.
>>>>  On 6/25/09, Jeff Ramsdale <jeff.ramsdale@gmail.com> wrote:
>>>>>  jini.org is currently hosted at Dreamhost and is run on Mediawiki.
>>>>>> I'm open to whatever the community decides. It's been frustrating
>>>>>> combating
>>>>>> the spammers while trying to keep jini.org as open as possible (per
>>>>>> wiki
>>>>>> culture). I'd be more defensive of keeping the site if the community
>>>>>> had
>>>>>> taken greater ownership of it, but a lot of the content is stuff
>>>>>> copied
>>>>>> from the previous site (like the Jini specs and all the content from
>>>>>> Jini
>>>>>> Community Meetings). I'd really hate to lose the JCM stuff, in
>>>>>> particular.
>>>>>> -jeff
>>>>>> On Thu, Jun 25, 2009 at 8:23 AM, Rick Innis <rick@innis.ca>
>>>>>>  This is just a heads up that we have to decide if we want to
>>>>>>>  keep Jini.org around.  The site has been around since the
>>>>>>>> inception of the Jini Community in 1999, and has gone through
>>>>>>>> a number of transformations over the years.  It's current
>>>>>>>> is that it is wiki-based and hosted by Dreamhost.
>>>>>>>>  I use Dreamhost for my own hosting, and I'd be happy to
add the
>>>>>>> jini.orgsite to that.
>>>>>>>  We have an outstanding bill for $239.40 that is due by July
8th to
>>>>>>> keep
>>>>>>>  the site going.
>>>>>>>>  I' also happy to chip in towards this.
>>>>>>>  We can either:
>>>>>>>  - try to consolidate and move the content to Apache River,
>>>>>>>> - figure out how to fund the Jini.org site, or
>>>>>>>> - just let the site (and content) expire.
>>>>>>>>  I agree with Patrick that the domain name should be kept
up. I
>>>>>>> think
>>>>>>> migrating the useful content to the Apache River project is probably
>>>>>>> a
>>>>>>> good
>>>>>>> idea, and eventually redirecting jini.org there - it makes it
>>>>>>> that
>>>>>>> there's one source for the project.
>>>>>>> R.
>>>>>>> ===========================================================================
>>>>>>> To unsubscribe, send email to listserv@java.sun.com and include
>>>>>>> the
>>>>>>> body
>>>>>>> of the message "signoff JAVASPACES-USERS".  For general help,
>>>>>>> email
>>>>>>> to
>>>>>>> listserv@java.sun.com and include in the body of the message
>>>>>>> To view past JAVASPACES-USERS postings, please see:
>>>>>>> http://archives.java.sun.com/archives/javaspaces-users.html
>>>>>>>  --
>>>>> Sent from my mobile device
>>>>> Sam Chance
>>>>> 443-694-5293 (m)
>>>>> 410-694-0240 x108 (o)

Sam Chance
443-694-5293 (m)
410-694-0240 x108 (o)

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message