[Chandler-dev] Moving color/etc out of ContentCollection

[Alec Flett]

Phillip J. Eby wrote:
>
> It is; that's why nothing should be depending on it.  Chandler depends 
> on its parts, its parts should not depend on it.
>
> So, in general, osaf.app should be empty except for specifying what 
> parts are to be included in Chandler-as-a-whole.
>
This sounds totally reasonable.

In the spirit of recording IRC ideas, here were some other things that 
bryan, morgen and I discussed today on irc:
1) a "new" module osaf.chandler (as Morgan suggested earlier) probably 
sits on top of osaf.app. Some stuff from osaf.app moves 'up' into 
osaf.chandler where appropriate  - maybe osaf.chandler is what osaf.app 
was meant to be? This might at least make it clearer 'who's on on top' - 
(osaf.app sounded like app services to me, that I could use elsewhere... 
I might be one of the main parties guilty of abusing it!)
2) osaf.views.main becomes into osaf.chandler.ui
3) As much as possible from application/ goes into either osaf.app or 
osaf.chandler, depending on the dependencies involved
4) osaf.framework.blocks.detail could go into osaf.chandler.ui.detail, 
since it is defining actual chandler-specific blocks.

These are just some ideas, we weren't making any hard decisions. I also 
threw around the idea that, since we're not trying to make CPIA a 
general purpose framework, that we just throw osaf.framework.blocks into 
osaf.chandler.ui - stearns wasn't so hot on that idea and I'm not wed to 
it, but its something to think about.

I did some crude code exploration (mostly grep) and found roughly 43 
dependencies on osaf.app, including the Amazon/feeds/etc parcel and 2 
tests.

I do agree that trying to do this piecemeal is in general the wrong 
approach, but I think we can at least start to break some of these 
dependencies now so that future modularity work, however it may pan out, 
will be easier. One place to start is me moving the timezone pref out of 
osaf.app!

Alec

I think everyone is on board with the modularity goals - avoiding 
circular dependencies and the like.