Good email Tom, I agree with your sentiments entirely.
I think Niclas' commentary on having a starting point is a good one, though I wouldn't necessarily agree with the solution outline there-in. I suspect ultimately, we need to agree which users we're serving and what problems we want to solve for them, the rest, including packaging, APIs, SLA's or whatever will follow. Having been through this whole discussion many times and from many angles, I'd expect no flames but plenty of conflicting views and no resolution. It would be a big step forwards for the community as a whole to really engage with this one, not sure if it's ready yet. Last thing to say: "And yes, I agree, River terminology is expressly unique to the River domain which makes comparing our software with others difficult" The language used internally needn't be the language used externally in fact, it probably shouldn't be. Consider the linux kernel hackers have their own terms and such but the language used by e.g. Ubuntu or Redhat in packaging that up is completely different. Interesting too I think that the is a layer of vendors between many Linux end users and the kernel team. Speaks to how River might/could develop.. Happy Christmas, Dan. On 26 December 2010 21:06, Tom Hobbs <[email protected]> wrote: > 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 > <[email protected]> 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 > > [email protected] > > > > > > > > >
