river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Calum Shaw-Mackay" <calum.shawmac...@gmail.com>
Subject Re: Split JavaSpaces and JINI
Date Thu, 11 Dec 2008 09:36:35 GMT
To my mind - if you can't get something up and running within 10
minutes, no amount of 'but it's cool' will save you. Jini doesn't have
the groundswell that other projects have for instance Spring that will
keep a developer looking at it and the docs for a couple of hours
before they get something useful happening...

We have to get the 'download'-'edit'-'build'-'aha this is great, why
haven't I used this before' cycle down to as quick as possible.... it
took me a week of wrangling to go from Jini 1.2 to 2.0 - quite simply
it's not a good sign....

Yes Jini makes the hard network things easier - but working _with_
Jini should be made easier, and quicker in the first instance..... yes
we have all the security aspects and they're very good.... but you
can't drop new people into that quagmire straight away.... to be
honest, I think it's scaring people off

2008/12/11 Jools <joolski@gmail.com>:
> 2008/12/11 Niclas Hedhman <niclas@hedhman.org>
>> </snip>
>> Well, I will stop arguing about what I think is wrong, and just go out
>> and make the changes I think is necessary. And funny enough, it is not
>> that much that needs to be changed. If I am not welcome to do so that
>> here at River, then fine, I bring the codebase elsewhere.
>  When Jini, and JavaSpaces where first conceived many years ago now things
> were in a very different state to what we have now.
> For a start the language has been refined, the JVM is now very stable and is
> very efficient compared to those early days.
> We have lots of nice new features, and some excellent tools to make our
> programming days so much easier.
> But here in the river incubator we say 'bah!' to all these new tools, and
> state that what we have is good enough. Well actually no.
> We are not leading the curve, we are some way behind now.
> The last few projects I have worked on, the developers wont entertain
> 'download a zip, unpack, shuffle the jars, curse, read the docs' type
> approach.
> They just want to add the dependency to their pom, and off they go.
> I asked a friend who has been involved in this technology for a longer long
> time, just when was the last time you used norm, or mercury ?
> Exactly. I think I fired them up for a test, maybe 7 or 8 years ago. So why
> do I seem them clogging up my release download ?
> Where I'm basically heading here, is.. lets get radical. nicals, if you want
> to change stuff. Do it. Prove it works. Get people using it and off we go.
> It's how apache got where it is today. It's where the name came from, people
> supplying patches to make it better.
> There are lots of cool toolkits for developing services using this
> technology, river is the bottom layer. The enabler.
> Lets focus on making it easier for these toolkits to grow by listening to
> the needs of these developers, not dictating the state of the world.
> However, I have to admit. I'm not really debating anymore, I'm doing. If it
> means a split away from river, then so be it. And to be honest, it's already
> happened.
> So many times I see "I've made a local change to allow..... blah blah blah",
> so why wasn't it easy to get that change into the code base in the first
> place ?
> So I guess it comes to this. Is river just a place where Sun has parked
> jini, so legacy codebases can get access to the old code, or is it a place
> where we can start to build the tools for the next generation of distributed
> systems ?
> --Jools

View raw message