Dan, you're wise and I respect your view. Security matters to me because I plan to deploy over insecure networks.
Luckily security is mostly complete, Bob Scheifler's team achieved what they set out to do, a very difficult task I might add. But this takes skill on the application developers part to understand and utilise.
For an application developer, determining policy files and permissions is often one of the big hurdles.
I get where you're coming from, deployment needs to be simpler and installation / configuration needs to be automagic.
To make it possible to add in security later, requires the application developer to follow certain rules and method calls. These are typically very similar among different services.
I'm wondering if it's possible to use annotations to hide these methods from the application developer on the client side, so they can learn to develop without worrying about security, perhaps using only reflective proxy's to start with, then activate security later and start using smart proxy's when ready?
Typically we're talking proxy verification, dynamic permission grant's, running as Subjects, using key stores and using method constraints.
Cheers, Peter. Dan Creswell wrote:
I recall Waldo saying some time ago that systems get harder and harder to do as you in order from: (1) Single-thread single machine. (2) Multi-thread single machine. (3) Multi-machine. (4) Multi-machine with security. On that basis, I'm tempted to say we should make our lives easier by setting something that limits the amount of heavy-lifting we need before we have anything to show for it/play with. Thus, I'd say we do, in order: (1) We should look at easing the admin burden - in terms of scooping up exceptions, logging, monitoring and such. (2) Sort out a bare bones out of the box experience - minimal configs, intelligent auto-setup for network interface selection. (3) Security for all the above. Now, I know and it's right to say on some levels, baking in security from the start often is what needs to be done but Jini itself managed without security early on and we probably ought to plan to "throw one away" (as per Mythical Man Month) as we figure these things out so I personally believe security can wait. +1 for doing as much through JMX as possible by default if that's practical (fear with multiple JVMs on one box a la simulating distributed services it might get tough).
