The type of issues you’re talking about seem to be centred on putting Jini services on the open internet, and allowing untrusted, unknown clients to access those services safely.
Personally, my interest is more along the lines of Jini’s original goal, which was LAN-scoped or datacenter-scoped SOA. Further, I use it on more controlled networks. As far as I’m concerned, only code that I trust gets on the network. In a larger corporate scenario, I might lock down access to Reggie, but beyond that, I don’t consider DOS a threat. I think it would make sense to be able to put a byte limit on the stream used to load the class, and possibly a time limit, but beyond that, I think you’re adding complexity that isn’t needed. If you want to put a service on the web, use RESTful services, not Jini. I’m sure there’s a discoverability tool out there, if needed, but typically it isn’t. Also, since object serialization is not specific to River, I wonder if there’s a better forum for these kinds of deep discussions. I think it makes River look far harder than it is. Cheers, Greg Trasuk. On Feb 19, 2015, at 9:03 AM, Peter <j...@zeus.net.au> wrote: > What are your thoughts on security? > > Is it important to you? Is it important for River? > > Regards, > > Peter.
