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
