Perhaps it might be time to make JERI a separate release. JERI method constraints allow authentication to occur prior to code download and object deserialising.
It Jini's pre JERI implementation that prevents it. Only secure discovery takes advantage of it. With recent Java security scares, JERI offers an opportunity to avoid those issues. You can't escape the sandbox if you can't authenticate to even access it. Take JERI, make it modern and concurrent, release that separately. Jini is restricted to Sun's JVM because of all the legacy cruft no one want's to let go of. Why should JERI suffer the same fate? Cheers, Peter. ----- Original message ----- > Interesting observation. > > So if I do a search in google for "customisable rmi" I don't get a hit > on River. A quick wander through our docs says we don't present > ourselves as having a superior RMI implementation (maybe we do but > it's buried deep). > > We've got some conceptual stuff out there (good) but some grass roots > (here's the hot bits of our tech) maybe not so much. > > So, we're not leveraging the obvious tools for discovery. That said, > even if we were, we have to expect some people will reinvent wheels > badly. Rob Gingell once observed that “those who do not use Jini are > doomed to reinvent it.” > > On 24 January 2013 04:39, Gregg Wonderly <ge...@cox.net> wrote: > > I didn't know about this project. The more things like this I see, the more > > it really seems River is hidden from view, more and more. > > > > http://sourceforge.net/apps/mediawiki/dirmi/index.php?title=Dirmi > > > > Gregg Wonderly
