On Mon, Dec 27, 2010 at 5:06 AM, Tom Hobbs <[email protected]> wrote:
>> * 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. I meant "well-known outside River"-interfaces. Or reasonably close enough that the selling point is easy. My point with Hazelcast is that they have done the easy-to-market approach; java.util.concurrent interfaces in a distributed manner. Easy to understand. Others focus on DHT --> Easy to get. River --> Not so sure, and it takes a lot of reading, and once one is done; Outrigger is a distributed storage space, but not. Mahalo is a transaction manager, but not what we are used to. Reggie is a service registry, but actually much more complicated than that (if you read docs you easily get scared) yet the most useful and solid bit of work. >> * Packaged with reasonable defaults [snip] > > Reggie, Outrigger, Mahalo are all reasonable defaults aren't they? Uhhh... Can you provide me with a pointer to the equivalent of; Map m = Hazelcast.getMap( "niclas" ); This makes "entry" is fun. GigaSpaces have something similar (can't recall the API call off-my-head). >I get the > feeling that there is not a clear agreement in the River community > about what it thinks River *is*. Yes, you might hit the nail spot on. So, on one hand, if River is for "app developers" then it is "too cumbersome" and if it is for someone in between River and the "app developer", then it doesn't provide enough value to build on, compared to rolling your own (exception exist of course). So, I think Jini as a technology is needed "as-is" for the latter group, I don't think it is enough for River, and I am probably hinting that more consumable sub-projects on top are needed. > 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. Case in point; Myself. Big effort for new middle-ware infrastructure at work. Jini's value proposal is too small to make it a strategic underlying choice (even compared to rolling an in-house equivalent), the compromises one has to make are greater than the value offered in return. Solutions like Coherence, Hazelcast, Newton, Terracotta, Gigaspaces and others have enough value-add to be considered. > I'm interested to hear other people's opinions, particularly those who > are using River - in whatever capacity. Me too... I am in no way saying that this is 'must' for the project, just my highly opinionated view of a project I have followed now for 10 years. 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
