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
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
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,
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.