Thanks for the feedback. Comments are inline below.
On 7/19/07, Allen Gilliland <[EMAIL PROTECTED]> wrote:
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.
On second thought I agree with you on this. We do not need a User
Repository API or a User Permissions API. The UserManger is the API,
it's the right level at which to plugin external systems.
With that in mind, it really does not make sense for the UserManager
to incude all of those page and website methods. Those should be
moved. I suggest this:
UserManager - for user and role/permissions management
WeblogManager - for Weblog and Page management
WeblogEntryManager - for WeblogEntry and Comment management
How do folks feel about that refactoring?
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.
I think we'll need extensible user attributes at some point, but for
now using the User object can meet all of my requirements. So #3 works
for me.
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.
I disagree with that sentiment. Roller's biggest advantages are it's
abilities to handle large mutli-weblog sites and in such sites it is
almost always a requirement to hook into to user management
permissions systems.
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.
Agree. The UserManger is the API, it's the right level at which to
plugin external systems.
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.
It is a big change, but I believe we need it.
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.
I believe that ideally Roller should provide both a Provisioning API
so an external system can control users/weblogs and also pluggable
user/permissions management.
My team decided against using a Provisioning API because it is to
problematic and has too many moving parts. The controlling system has
to keep things in sync, disabling blogs and users when employees
leave, 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.
What I'm proposing is making Roller more pluggable with a minimum
amount of changes to the data model. I want to make things pluggable
and less highly coupled.
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.
Yes, performance is definitely a concern but if we design this right
it should only be a concern for those plugging in external user
management.
I'm going to rewrite and combine the two proposals into one with this
feedback in mind. I hope to be done by mid-week.
Thanks,
- Dave
