Colin Sampaleanu wrote:
I can't speak about the release, as Ben has actually done all of those (and after a spurt of code and suggestion in April, I' ve actually been too busy to do much with Acegi anyways, aside from just using it of course). W/regard to making it "the" security component for Spring, I'm not so sure there's much reason to do that right now, from a technical reason anyways. Because of the whole IOC implemenmtation approach there are no real constraints on what the framework can do as an external addon. From a marketing point of view of course, it might help, but we (the Spring developers) push it as much as possible anyways. The trouble with trying to qualify it as "the" security framework is that almost everybody's needs in this space are different..In relation to the next release, I have been a little disappointed with both 0.5 and 0.51 in that there were bugs related to caching. As a result, I've deliberately delayed an 0.6 release until the last batches of changes get tried out by people. I asked people on 25 June to give CVS HEAD a try and advise of any issues. Feedback is appreciated....
On the other issue, I don't mind where Acegi Security sits. This is a subject I've written about in private emails to some Spring developers, as it affects much more than just Acegi Security. In general:
Own Projects
+ Can grant CVS access (= more developers)
+ Can manage own release cycle
+ Can foster multiple projects in same problem domain
- More difficult exposure
- More mailing lists
- Lower quality projects can compromise the Spring name
- Fine-grained downloads
- Absence of project management tools like Wiki, bug tracking, Cruise Control etc
All in Spring Core
+ Maximum exposure for what would be separate projects
+ Maximum marketing benefits for Spring as a community
+ Easy one-stop download and documentation
+ More leverage on project management tools
+ Fewer mailing lists
- Explosion in number of CVS committers and/or reluctance to add new committers
- One release cycle
- Difficult to deprecate components, so supported components grow (take ORM)
- Forced CVS checkout for early-stage projects (take sandbox)
- Discourages use of external projects if something similar in core
That latter point may need clarification. Whilst Spring Core handles many problem domains, many users elect to use external projects. Take Mule over Spring JMS, or JGoodies over Spring RCP, or Tapestry/Struts/WebWork over Spring MVC, or Sitemesh integration over Spring Tiles integration, or indeed Acegi Security over Spring's Servlet spec-related classes. The problem with this is users may get the impression they should use the "supported" project and/or it is simply easier to do so (as the code, docs and integrated samples are already downloaded). Only those with particularly strong needs will venture outside the Spring Core problem domain treatment and use something else.
The view that "Acegi Security doesn't belong in Spring Core because different security implementations may be required" doesn't reflect precedent. There are many examples (see previous paragraph) of alternative parallel implementations being used in lieu of the Spring Core offering. Security is arguably no different, especially given there aren't (or likely to be) any alternative security implementations actively developed. On the other hand, it might be more strategically valuable to relocate projects such as those identified above out of Spring Core and into their own projects, leaving only the genuinely core parts in Spring Core (the problem then becoming, "what is Spring?"). An issue is this would cause a large number of projects and the disadvantages identified above.
The other counter argument to multiple security implementations is there is only so much open source developer time available to work on Spring IOC-specific security, and in my experience open source project leaders and developers tend to be cooperative folk (especially in Spring land). I would do my best to accommodate any new developers or their ideas within the existing framework. And if their vision (and available time commitment) is so revolutionary the existing framework simply couldn't be used, I'd see to what extent the new framework could deprecate Acegi Security and offer a migration path to users. Acegi Security is not an MVC framework, nor a JVM-level solution: it's a Spring IOC-specific security solution. I respectfully disagree with people who believe there are so many users and developer hours available that it is both necessary and possible to cultivate a _choice_ of Spring IOC-specific security implementations. Even if it happened, the fragmentation of the community, adverse marketing message sent outside the community, and duplication of developer efforts would probably cause consolidation of such projects over time. Consolidation has happened in much larger problem domains than the small niche of Spring IOC-specific security.
So, repeating my opening remark, I don't mind whether Acegi Security sits inside Spring Core or not. Both projects seem to be doing just fine at present. I'm sure Spring will thrash out a project placement strategy when there is some extra time available.
Best regards Ben
-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
Acegisecurity-developer mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
