My initial thoughts ...
In general I think it's a nice thing to make Roller more flexible in
terms of plugging into external systems, but I'm also a bit suspicious
that some of this work is going to complicate things for typical
scenario users in order to support a much smaller number of more
enterprise type users. At the risk of sounding too cautious, my biggest
fear with this proposal is that we are going to over complicate things.
We already have a system that works well and it's not *too* difficult
to plug it into larger systems, so the point is that we have to draw the
line somewhere in terms for what work we do to support more specialized
types of installations and some of the work in this proposal is near
that line in my eyes.
General feelings aside though, some thoughts on the details ...
Externalize User Management.
I don't think we need a new "UserRepository API", that is the same thing
as the existing UserManager. I think the approach for plugging in an
external user system is just to plug in an alternate implementation of
the UserManager interface which should have all the right methods
available for dealing with users. As you outline in your proposal, we
would need to change a fair amount of code so that instead of relying on
pojo relationships to fetch users we would need to consult the
UserManager everywhere, which is a bit of a PITA.
I would also fairly strongly side with option #3. At the end of the day
I don't think we should be setting up funky ways of partitioning profile
data so that you have to get a User and then call User.getProfile() to
get the rest of the profile data. The User object should be all that is
needed and it can come from whatever system is configured. The goal is
transparency and #3 is the best option in that regard.
Externalize User Permissions
This is where things get yucky IMO and this is also where I start to
believe that we are likely to complicate a simple, and already working,
solution just for a very small number of people who would run Roller
this way. But if we really need to do this then same as above, I don't
see why we need a new "User Permissions API", we have the UserManager
interface and that should be enough. Adding in more interfaces and APIs
seems unnecessary to me. If we need to rework the UserManager methods
which deal with permissions checking then that's fine, but I think those
methods should remain in the UserManager.
Like the user object, the biggest issue with trying to externalize
permissions the way you are proposing is that you are asking us to break
our object association model used by our ORM solution. This is the part
of your proposal that makes me the most nervous.
Other considerations ...
Your design seems very intent on trying to call out to 3rd party systems
directly rather than just allowing a 3rd party system to control Roller,
why is that? Much of what you are proposing here could be done in a
different way where instead of focusing on changing the apis so that
accessing the data makes calls to 3rd party systems, we could instead
focus on allowing 3rd party systems have easier ways of controlling
Roller. so instead of calling out to a 3rd party system to check
permissions, that system would notify Roller that userX now has
permissionY on blogZ when a permission change happens. A very modest
event management system (something Roller needs anyways) would be
perfect for this. This way changes happening in external systems can be
easily reflected in Roller by firing off an event like ... user profile
update, or user permissions change, etc, etc.
Mucking around with the backend systems and data model of Roller seems
to me like a more intrusive and highly coupled solution than just trying
to allow an external system the ability to somewhat remotely manage some
pieces of Roller.
One of the other major problems I see with trying to talk directly to
3rd party systems is performance. Constantly making calls to these 3rd
party systems is going to make performance management a pain because
instead of just worrying about Roller and how it performs on its own you
now have to worry about a whole string of interdependencies and remote
system calls which can all become bottlenecks. Remember that if looking
up a User object requires a call to a remote system then if I want to
display 30 entries and show the authors name then that equals 30 calls
to that system and I will have minimal ways to optimize those calls on
Roller's end of things. So from a performance point of view I would be
more worried about trying to keep all of these 3rd party systems
separate and continuously make remote calls between them.
-- Allen
Dave wrote:
I'm working on two new proposals (see below) for externalizing user
and permissions management, which is something that I need and others
have requested, for example Elliot of Lulu.com and James Snell of IBM.
These proposals are not complete, but I'd like to get some feedback
now before I go too far into design.
So, interested parties, please take a look and provide feedback. Does
this meet our common requirements for externalized user profiles and
permissions? What about the implementation? See any red flags for
performance or scalability?
- Dave
Externalize User Management
For ease of installation and management, Roller is able to manage it's
own users without relying on any external system other than its RDBMS.
We definitely don't want to lose that that easiness, but as Roller
moves into enterprise scenarios where Directory Servers rule and
social networking scenarios where user profile information is key, we
need to make some changes. For Roller to be successful in large
organizations and social networks, we need to make it easy to
integrate Roller with existing user management systems. The way to do
that is to externalize user management, or rather to make it
externalizable.
This proposal outlines a plan to make it easy to hook Roller up to an
external user management system for user information, user profiles
and user roles. The general approach is to define a UserRepostory API,
provide a default implementation for Roller, and change UserManager to
use that API. Developer could then provide alternative implementations
of that API to plug in their own user management systems. Also, to
allow more authentication options make it possible to configure Roller
to use CMA instead of Acegi.
Read the rest here:
http://cwiki.apache.org/confluence/display/ROLLER/Proposal+Externalize+User+Management
AKA http://tinyurl.com/352ttm
Externalize User Permissions
For ease of installation and management, Roller is able to manage it's
own users permissions relying on any external system other than its
RDBMS. We don't want to lose that ability, but we do want to make it
possible to plug Roller into existing sites and applications that have
their own permissions management systems.
This proposal outlines a plan to make it easy to hook Roller up to an
external user permissions system. The general approach is to define a
User Permissions API, provide a default implementation for Roller, and
change UserManager to use that API. Developer could then provide
alternative implementations of that API to plug in their own user
permissions systems.
Read the rest here:
http://cwiki.apache.org/confluence/display/ROLLER/Proposal+Externalize+User+Permissions
AKA http://tinyurl.com/2rfpba
