On Tuesday 08 March 2005 03:32 am, Dominique Pfister wrote:
What you're saying is if someone wants to adapt Jackrabbit to their own authentication scheme, they are going to have to create a JAAS adapter/implementation? This is doable, no doubt. But Ben's idea has the advantage of being simple. There is always a tension and balance between "abstract" and "simple" - but what I've seen over the years is that developers tend to choose simple over abstract (though not always, of course). If I was evaluating Jackrabbit and saw the "AuthenticationToken" interface, the cost in implementing it (learning curve + effort + time) would be so low that I wouldn't have to give it a second thought. However, if I saw that Jackrabbit was tied directly to JAAS, I would have to give it a second thought: "is the implementer on the team familiar with JAAS? What will his learning curve be, and how much time will it take him to get up to speed just enough to create this adapter? How much will the added complexity increase testing time (how many more test cases will be necessary to write)?" etc...
Well, I estimate JAAS to be quite a well-known standard nowadays and every major application server vendor supports it. At the time authentication and authorization came into place with jackrabbit, a decision was made to integrate as smoothly as possible into a J2EE environment. To give an example, this was also the reason for javax.jcr.XASession to die, because today's resource adapter support inside application servers makes it obsolete.
Just my 2c. :)
- Andy
Cheers Dominique
