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
