Re: Starting to modularize legacy

On Feb 24, 2006, at 10:14 AM, Mark Norton wrote:

User is similar - we need a framework level user and a common level User.

Less clear. What capabilities would be at the common level that wouldn't be at the framework level, given the layer definitions below? I do think that User should be more abstract that UserDirectory. There are more than one way to implement a User than in a directory. UserDirectory is a holdover from CHEF, as near as I can tell.

Don't get stuck on the word "Directory" or the word "CHEF" the API for User has nothing to do with how the information is stored.

I also had to change the EntityProducer interface's syncWithSiteChange(Site site, ChangeType change) to syncWithSiteChange(String siteId, ChangeType change) to keep the Site dependency out of the framework.

This is the Site dependency noted above. I have mentioned this to Glenn in the past and there was some discussion about alternative approaches at that time. Personally, I think that a reference to Sites at the Entity level is completely wrong. It totally violates the layering of services. I think we should consider moving it into the Site Service (if possible) or consider developing a synchronization service of some kind. It sholdn't be in Entity at all. That said, your proposed change reduces coupling. I could live with that.

We need to find a way to reduce the coupling - the event discussion might get us there - but this requires careful thought.

Josh's suggestion would get us the biggest bang for the buck in the short term (Site becomes SiteId). Longer term, Sakai really needs some kind of generic notfication system for internal and external synchronization. Course Management needs this ASAP. Maybe we can figure it out as a new service and integrate it further down the line.


I really really do not want to wholesale rename things for 2.2. I thing that we can get away with some refactoring (making new jars etc) in preparation for a rename pass - but I would prefer to minimize the needed changes to tools under development (both inside and outside the source tree) and web services and local plugin code.

Makes sense. Package name changes are not quite as bad though, right?

Depends - lets just talk each through as a proposal on this list and see where we go. One problem is that there is a set of folks who will always say "no" to any change and yet we have to make progress. We will have to understand that the members of the list do not have pocket veto on changes or progress. The commit list in the framework are the ones who will decide when/how we go forward. If we allow a few "no" votes to stop progress we will go no where. Discussion is great and exploring options is great - but categoric "no" votes with no rationale will be ignored.

Renaming is easy once things are nicely broken out - and the "bad" connections are changed. Fall is a good time (say october) to do these kinds of things (sorry Rutgers) because I think that increasingly sites will not upgrade over holiday break except those sites in pilot and able to "keep up".

Read the follow ups to this. To my way of looking at it, there is no good time to be making these sorts of changes. Therefore we have to be careful and rigorous every time. Does it make sense to capture (document) how we go about this sort of thing? In general, I mean.

This group is the "document" - we need to have open conversations about all of these things. We need a group value to stop jumping on every post and turning it into a vote or governance discussion. We need a lot of discussion.


This automatic notification message was sent by Sakai Collab
( from the WG: Framework site.
You can modify how you receive notifications at My Workspace > Preferences.