What is River?

[Tom Hobbs <tv...@googlemail.com>]

I've been having a chat about what various things in the "Extras (was
PGP)" thread and something has come up that I think requires a new
thread.

What *is* River?

Some of the work in "Extras" that I want to do is make is easy for
developers to get started writing and using River services.
Paraphrasing some of the comments on tha; "there's plenty of
containers and third party applications around, users should just be
pointed towards them.  We should be concentrating on making it easy
for users to swap between these containers, rather than reproducing
anything that they do".

Please correct me if that paraphrasing is unfair/wrong.

So my question is this; do people see River as existing solely to
provide functionality to the third party containers, thereby meaning
that developers should only ever be downloading River as a dependency
for their chosen container/application; or do we see developers
downloading and using River directly?

My personal view is *both*.

In my experience, I've worked on a project that was implemented
without any third party container, directly using the River (or rather
Jini 2.1) code-base.  I admit that we ended up writing a
container-like service in the end.  We certainly never downloaded or
used any of the existing containers, in fact I'd never heard of them
until I started getting involved in River.  My work on that project
would have been much more simple if the River/Jini download had come
with a few more examples and utilities - or if more noise existed on
the River site about all the third-party applications available!

Reading the comments written by others who use/own/write service
containers, it seems like a lot of work could be done in River to make
their jobs easier.  There's certainly a lot of information and ideas
that can flow both ways.

So is there room for both approaches?  I certainly have the will to
try and work on both, I'm reluctant to reduce the "make using River
directly easier" component to being fulfilled by just supplying a list
of external links to other software products - although such a list
would be a desirable addition.

Cheers,

Tom

Re: What is River?

[Tom Hobbs <tv...@googlemail.com>]

Agreed.

Next week I'll make some new pages on the River site/wiki.  I want to
put together a "Who's using River?" page - consider this a request for
submissions.

I'll also create some kind of page detailing external projects, so if
anyone is interested, send me a blurb and a link and I'll put it up.
(Or get a wiki account yourself and add the text as you like it...
:-)

Cheers,

Tom


On Fri, Oct 15, 2010 at 11:34 PM, Peter Firmstone <ji...@zeus.net.au> wrote:
> I'd like to see currently external projects join River as subprojects.
>
> By working together we increase our strength and visibility.
>
> Peter.
>
> Dennis Reedy wrote:
>>
>> On Oct 15, 2010, at 738AM, Sim IJskes - QCG wrote:
>>
>>
>>>
>>> On 15-10-10 13:17, Tom Hobbs wrote:
>>>
>>>>
>>>> So my question is this; do people see River as existing solely to
>>>> provide functionality to the third party containers, thereby meaning
>>>> that developers should only ever be downloading River as a dependency
>>>> for their chosen container/application; or do we see developers
>>>> downloading and using River directly?
>>>>
>>>> My personal view is *both*.
>>>>
>>>
>>> Both! We dont have, nor desire any control over all the additions you can
>>> find on the internet. Others have made forks of jini/river and added
>>> facilities to it. No problem with that. But the River community right now
>>> should care foremost about itself. When we have our house in order, then we
>>> can care about others. Right now we are working hard to make River a popular
>>> package, and try to reduce the tendency of others to fork.
>>>
>>
>> I dont know of any available open source project that builds on River that
>> has actually forked the River codebase. I do know of at least one commercial
>> company that has forked River (and also forked my project).
>>
>>
>>>
>>> I refuse to let our attempts at lowering the threshold be stifled by
>>> others who think we should leave this to them.
>>>
>>
>> Lowering the threshold? In what way? By taking advantage of experiences
>> that others have had over the past decade of using Jini, that have put those
>> experiences into projects external to Jini?
>>
>> I'm not telling you to stop, I'm telling you to first look around and see
>> whats out there. If you dont like it, go re-develop what (in my guess) most
>> likely exists and is running in someone's application today.
>>
>> Cheers
>>
>> Dennis
>>
>>
>>
>>
>
>

Re: What is River?

[Peter Firmstone <ji...@zeus.net.au>]

I'd like to see currently external projects join River as subprojects.

By working together we increase our strength and visibility.

Peter.

Dennis Reedy wrote:
> On Oct 15, 2010, at 738AM, Sim IJskes - QCG wrote:
>
>   
>> On 15-10-10 13:17, Tom Hobbs wrote:
>>     
>>> So my question is this; do people see River as existing solely to
>>> provide functionality to the third party containers, thereby meaning
>>> that developers should only ever be downloading River as a dependency
>>> for their chosen container/application; or do we see developers
>>> downloading and using River directly?
>>>
>>> My personal view is *both*.
>>>       
>> Both! We dont have, nor desire any control over all the additions you can find on the internet. Others have made forks of jini/river and added facilities to it. No problem with that. But the River community right now should care foremost about itself. When we have our house in order, then we can care about others. Right now we are working hard to make River a popular package, and try to reduce the tendency of others to fork.
>>     
>
> I dont know of any available open source project that builds on River that has actually forked the River codebase. I do know of at least one commercial company that has forked River (and also forked my project).
>
>   
>> I refuse to let our attempts at lowering the threshold be stifled by others who think we should leave this to them.
>>     
>
> Lowering the threshold? In what way? By taking advantage of experiences that others have had over the past decade of using Jini, that have put those experiences into projects external to Jini?
>
> I'm not telling you to stop, I'm telling you to first look around and see whats out there. If you dont like it, go re-develop what (in my guess) most likely exists and is running in someone's application today.
>
> Cheers
>
> Dennis
>
>
>
>   

Re: What is River?

[Dennis Reedy <de...@gmail.com>]

On Oct 15, 2010, at 738AM, Sim IJskes - QCG wrote:

> On 15-10-10 13:17, Tom Hobbs wrote:
>> So my question is this; do people see River as existing solely to
>> provide functionality to the third party containers, thereby meaning
>> that developers should only ever be downloading River as a dependency
>> for their chosen container/application; or do we see developers
>> downloading and using River directly?
>> 
>> My personal view is *both*.
> 
> Both! We dont have, nor desire any control over all the additions you can find on the internet. Others have made forks of jini/river and added facilities to it. No problem with that. But the River community right now should care foremost about itself. When we have our house in order, then we can care about others. Right now we are working hard to make River a popular package, and try to reduce the tendency of others to fork.

I dont know of any available open source project that builds on River that has actually forked the River codebase. I do know of at least one commercial company that has forked River (and also forked my project).

> 
> I refuse to let our attempts at lowering the threshold be stifled by others who think we should leave this to them.

Lowering the threshold? In what way? By taking advantage of experiences that others have had over the past decade of using Jini, that have put those experiences into projects external to Jini?

I'm not telling you to stop, I'm telling you to first look around and see whats out there. If you dont like it, go re-develop what (in my guess) most likely exists and is running in someone's application today.

Cheers

Dennis

Re: What is River?

[Sim IJskes - QCG <si...@qcg.nl>]

On 15-10-10 13:17, Tom Hobbs wrote:
> So my question is this; do people see River as existing solely to
> provide functionality to the third party containers, thereby meaning
> that developers should only ever be downloading River as a dependency
> for their chosen container/application; or do we see developers
> downloading and using River directly?
>
> My personal view is *both*.

Both! We dont have, nor desire any control over all the additions you 
can find on the internet. Others have made forks of jini/river and added 
facilities to it. No problem with that. But the River community right 
now should care foremost about itself. When we have our house in order, 
then we can care about others. Right now we are working hard to make 
River a popular package, and try to reduce the tendency of others to fork.

I refuse to let our attempts at lowering the threshold be stifled by 
others who think we should leave this to them.

Gr. Sim

-- 
QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397

Re: What is River?

[Dennis Reedy <de...@gmail.com>]

On Oct 15, 2010, at 717AM, Tom Hobbs wrote:

> I've been having a chat about what various things in the "Extras (was
> PGP)" thread and something has come up that I think requires a new
> thread.
> 
> What *is* River?
> 
> Some of the work in "Extras" that I want to do is make is easy for
> developers to get started writing and using River services.
> Paraphrasing some of the comments on tha; "there's plenty of
> containers and third party applications around, users should just be
> pointed towards them.  We should be concentrating on making it easy
> for users to swap between these containers, rather than reproducing
> anything that they do".
> 
> Please correct me if that paraphrasing is unfair/wrong.

I dont think this an incorrect paraphrasing of what has been discussed. The main point being made was (quoting fro my earlier reply):

The issue here is that many of the things that you wish to accomplish have most likely been done across the myriad of Jini projects that have been out there for years. The reason these projects have been created is "to make it easy and obvious to application developers". Historically, the Jini community at large seems to have a hard time recognizing and endorsing external projects, I dont know why, it just has. What I am seeing here is an opportunity to leverage the work that has been done to move River forward in a better way.

Instead of going out and developing utilities, you could provide a list of capabilities (perhaps creating a call for action), and those that would be inclined to contribute can. Alternatively, you may also be pointed to open source projects that allow you to build upon (or leverage/learn) what has already been done. Consider this includes things like:

Configuration utilities and approaches
Maven archetypes (and support in general)
Smart proxy approaches
Annotations for Jini services
IoC for services you require
(others ...)

The above has nothing to do with containers.

Other conversations focused on River providing an SPI for containers to make it easy to move services across different projects. 


> 
> So my question is this; do people see River as existing solely to
> provide functionality to the third party containers, thereby meaning
> that developers should only ever be downloading River as a dependency
> for their chosen container/application; or do we see developers
> downloading and using River directly?

I dont know how you arrived at this opinion. River exists right now as a technology that provides infrastructure for the development of services that can be discovered and used through the network. If you use River "raw", that is just use the classes found in the JSK it takes a bit of work. I liken this to other infrastructure focused technology, that also provides plenty of room for higher level frameworks to build on.

I dont see that there needs to be a schism here. As I see it, the utilities project that you are embarking on is exactly like the other projects that have been developed for Jini over the past few years. The only difference is you are merging your approach into the River ciodebase.

Dennis