river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom Hobbs <tvho...@googlemail.com>
Subject Re: Suggestion for future
Date Sun, 26 Dec 2010 21:06:45 GMT
Hi Niclas,

Thanks for the suggestion.  I can't seen anything in your message that
might start a flame war.

You raise some good points.  Let me respond to a few of them;

>  * Full Resilience to failure possible, preferably expressed in SLA.

Agreed, this is definitely needed as it's something we're missing.
River is lacking a lot of marketing-style stuff, hopefully recent
updates to the web site are going to start addressing this.  I've
certainly never seen an SLA style document.

> * APIs expressed in well-known interfaces.

I think we have these, what I think is missing though is that there
are no clear examples of how you can implement certain distributed
patterns using River bits.  And yes, I agree, River terminology is
expressly unique to the River domain which makes comparing our
software with others difficult.

>  * Packaged with reasonable defaults [snip]

Reggie, Outrigger, Mahalo are all reasonable defaults aren't they?

> * Avoid confusing the users with underlying tech
> [snip] and ease of use.

This is something very close to what I've been thinking about for
quite a while.  However, whenever bringing it up on this list the
general feeling (at least, as I interpret it) has been that we/users
should be using downstream projects to actually Do Stuff.  I get the
feeling that there is not a clear agreement in the River community
about what it thinks River *is*.

Is it, a complex tech designed for "downstream projects" to do stuff
with or is it a complex tech aimed at application developers to do
stuff with directly?

Personally don't see any reason why River can't be both.  I've built
cool stuff directly with River, I've also gone on to re-invent several
wheels when I could have gone and grabbed a downstream project
instead.

I don't want to detract from the original point of your message; that
River needs to start stating itself better if we want to be strong
contenders next time companies are looking to adopt a tech; but I do
think that we need to have some discussion about who River's users are
because that's going to drive what the above documentation looks like.

Like I've already said, I think River is big enough to cover both
camps.  We absolutely should be working with downstream projects to
standardise certain bits, add functionality and generally makes things
better.  However, I don't believe that we should ignore the developers
who might be using River directly - even at the cost of possibly
duplicating certain features of those downstream projects (but by no
means *everything*!)

I'm interested to hear other people's opinions, particularly those who
are using River - in whatever capacity.

I'd now like to join you in your hole ducking the flames...

Cheers,

Tom


On Sun, Dec 26, 2010 at 1:56 PM, MICHAEL MCGRADY
<mmcgrady@topiatechnology.com> wrote:
> No flames here.  I am all for this approach.  The non-functional values and services
drive my thinking.
>
> MG
>
>
> On Dec 26, 2010, at 4:52 AM, Niclas Hedhman wrote:
>
>> Gang,
>>
>> There is a strong distributed tradition in the group of people here,
>> yet unable to communicate the 'purpose' of River. Large companies look
>> at Gigaspaces, pays good money for it and asked if liking Jini, most
>> will go "Huh? Why would we use that?", mostly ignorant to the fact
>> that Jini specs drove Gigaspaces into where it is.
>>
>> At my company, we are doing evaluations of distributed technologies at
>> the moment. Jini/River is not even on the map, because it "misses the
>> points" that are our starting point. But an open source contender like
>> Hazelcast is, because it delivers an 'starting point' which is easy to
>> understand, i.e. a list of features as Distributed
>> Map/Queue/Events/Executor/... expressed in terminology that we (the
>> users) already know.
>>
>> So here is my modest suggestion for the Jini community; If you are as
>> hot on distributed technology as you think you are, then start
>> thinking in terms (and deliver a clear message) that matters to the
>> users;
>>
>>  * Full Resilience to failure possible, preferably expressed in SLA.
>>
>>  * APIs expressed in well-known interfaces.
>>
>>  * Avoid confusing the users with underlying tech
>>
>>  * Packaged with reasonable defaults and ease of use.
>>
>>
>> /me ducking for the flames.
>>
>> Cheers
>> --
>> Niclas Hedhman, Software Developer
>> http://www.qi4j.org - New Energy for Java
>>
>> I live here; http://tinyurl.com/3xugrbk
>> I work here; http://tinyurl.com/24svnvk
>> I relax here; http://tinyurl.com/2cgsug
>
> Michael McGrady
> Chief Architect
> Topia Technology, Inc.
> Cel 1.253.720.3365
> Work 1.253.572.9712 extension 2037
> mmcgrady@topiatechnology.com
>
>
>
>

Mime
View raw message