Ben, Excellent, sounds like a well thought-out plan towards 1.0. I'd recommend an "in-between" approach for the container adapters. I agree that including lightly-used, non-portable modules in the main distribution can lead to expectations that they be maintained as fully as the core. However, there is potentially a lot of value in having them available with documentation and samples, and you never know which of them may become heavily used over the next year. As you already know, app security is a big problem space that Acegi helps a lot with, but everyone historically has taken different approaches to the problem so there's a lot to think through when incorporating Acegi into their project (add to that Spring IoC/DI - something new to most developers). The good thing is that container adapters, documentation and samples can help a lot with the initial learning curve since it helps the developer get a working prototype up and running faster in the environment they need to operate in, and I'd posit that there will be a handful of popular ones to boil out over 2005, probably including Siteminder (but that may just be my own environment talking). So what's a middle-ground? Perhaps keep them in the same project, but distribute them out into separate, optional JARs, a la Hibernate-Tools and document them in addendums of the main reference, and then clarify that these are platform-dependant without official owners, so they aren't considered part of the core product. Not a bad idea to try to pin an owner on each one nonetheless... Just thinking out loud - take or discard as you wish...! Scott
On Thu, 30 Dec 2004 12:53:04 +1100, Ben Alex wrote > Version 0.7.0 introduces the final features that I believe are > necessary for a broadly useful enterprise application security > framework. I believe most of the code could now be considered mature, > except for the newer domain object instance security capabilities. > Whilst these new capabilities have only existed for between two and > four months, they're potentially HIGHLY useful, well-documented, > fully unit tested, and demonstrated in the Contacts sample > application. I also know of several real applications where they're > being used, so I expect the API to remain fairly stable. > > By releasing Version 0.7.0 I hope to see the domain object instance > security achieve more widespread use, so there can be appropriate > confidence in a 1.0.0 release. To a lesser extent it is also > intended to test the various new "minor" features added to CVS over > the past few months, along with the Mavenised build system. > > I do not intend to add any new major features prior to a 1.0.0 > release. There are several potentially useful areas, but none are > critical for most applications and the architecture enables them to > be added very easily and safely: > > * Remember-me functionality. There has been some design ideas put > forward, but just not implemented. > * Anonymous user functionality. This should be similar to any > remember-me approach. People have already implemented solutions to > this requirement (see forums). * Maintained and unit tested LDAP > provider. There is something in the sandbox and contributions on the > forums, but we need tests to add any to core. * Wider support for > remoting protocol automatic security propagation. We already offer > RMI and HttpInvoker, which covers most Spring Rich users. * Database- > sourced ObjectDefinitionSources. Spring itself will be offering > database-driven configuration (see sandbox). * Java 5 annotation > support. I am waiting to see what happens with Spring core's > attributes abstraction, and then use whatever approach follows. * > AspectWerks support for domain object instance security. It's easy > to do this, but I'd like a similar model to AspectJ where Spring DIs > the advice. > > One issue I'd appreciate some comments on is container adapter > deprecation. I know some people use the JBoss container adapter (as > they need to use EJB security as well), but I've not heard of any > usage of the Resin, Tomcat or Jetty adapters. It seems unwise to > maintain a suboptimal (non-portable) approach, especially as pre- > 1.0.0 we can deprecate them. > > Finally, the status of the project is up for discussion. I met Rod a > few days back and we briefly discussed making Acegi Security a > formal Spring subproject. This, coupled with a 1.0.0+ version number, > would make some people and organisations more comfortable using it. > What does the community think of this idea? > > Best regards > Ben > > ------------------------------------------------------- > The SF.Net email is sponsored by: Beat the post-holiday blues > Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. > It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt > _______________________________________________ > Home: http://acegisecurity.sourceforge.net > Acegisecurity-developer mailing list > Acegisecurity-developer@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
