Now that Wasp and Swarm 1.3.0 final are soon to be released i would
like to take this opportunity to discuss some of the changes i have
planned for the 1.3.1 release and maybe pick your brains for even more
ideas.

Although i am quite happy with the way things are now there is room
for improvements, a quick look at how things are now:
2 projects wasp and swarm (not multi project)
wasp : api
swarm : reference implementation
swarm project contains custom build security framework (hive)

Problem:
Security is too tightly integrated with wicket making it difficult if
not impossible to use the same security for soap calls, background
jobs or anywhere else there is no wicket application involved.
Wasp was already designed to plug in any existing security framework
and off course it has a solid dependency on wicket but that should be
transparent to the security framework being used in the
implementation. However because of the actions it cannot.

Solution:
wasp actions extend wicket actions, either wicket actions should be
available as a stand alone jar (didn't think you would like this)
or
break the inheritance between wicket actions and wasp action (simple
operation without much consequence) and package action related classes
in a standalone jar.
Also the security implementation (hive) needs to be stripped of the
few wicket specific stuff and packaged as a stand alone jar
This will introduce a few api breaks and break binary compatibility
but nothing extreme (tested these changes already against the
examples, takes less then a minute to fix the 2 constructor changes
introduced by this)
For this the project structure should be changed to something like this:
-wicket-security (parent project)
 -actions
 -wasp
 -swarm
   -hive
   -acegi integration?
 -examples
   -example 1
   -example 2
  ......

The svn structure should resemble this project layout.

Questions:
Some people argue that wicket-auth-roles is simpler and easier to set
up for simple projects.
Should we port wicket-auth-roles to wasp? (it would address the
request for annotations too)

Does anybody have ideas how to simplify swarm (lower threshold) ?

Should we use a "proven" security implementation rather then a home
brew, in effect replace hive?

Any other ideas on how to improve wasp / swarm?

Anything that needs to be done before wasp and swarm can be approved
as core projects?

Thanks,

Maurice

Reply via email to