[PEAK] Breaking up PEAK

Erik Rose psucorp at grinchcentral.com
Mon Jun 6 09:30:54 EDT 2005

Hi, pje, all.

> Here are some preliminary thoughts on how the breakup might go.

Just as a data point for you, the packages I'm using directly are  
binding, naming, config, model, protocols, and storage.

> My initial feeling about this list is that it's both too coarse and  
> too fine-grained at the same time.  It's too coarse because for  
> example both peak.util and peak.running are umbrella packages  
> containing many things that could quite reasonably be split out  
> individually.

I'd worry less about trying to normalize the structure of PEAK as if it  
were a DB and more about the interaction with users' brains. I think  
the breakdown you suggested—3 clumps of about 5 packages each—is good;  
it fits ESR's definition of compactness  
ch04s02.html#compactness), and each clump even fits in the  
5-plus-or-minus-2 size of human working memory. If you break things  
down further, I think new users will again descend into panic, saying  
"I have no idea what this thing does; there are 500 pieces!"

> I'm also uneasy because keeping track of versioning and release  
> information for *fifteen* packages (versus two now) seems a little  
> overwhelming.

That is going to be hard, and there's little way around it. However,  
it's also one of the most useful things you could do for someone in my  
position two months ago. I had significant trouble getting PEAK  
accepted in my department because the latest release said "alpha" on  
it; to some people, labeling carries a lot of weight. If, by splitting  
PEAK up a bit, you could label more parts "stable", you'd probably win  
some conservative users.

Btw, I'm sure you've considered this, but if you're going to switch  
version control systems, now would be a natural time. Maybe one or two  
of them has some tricks to ease cross-package versioning.

> documentation.  And, people encountering these small packages don't  
> run into that "trying to learn PEAK" (as in *all* of it) barrier.

Yep, I'm still scaling that barrier myself, but I learned what was  
important pretty quickly by reading the tutorials and looking at the  
diagram at http://peak.telecommunity.com/DevCenter. Btw, how up-to-date  
is that diagram? An interesting thing happens when you publish  
something—people believe it! :-)

> Further, it will be more obvious to people just how much functionality  
> is available in the PEAK "family of products"

The above-mentioned diagram made that clear to me.

> -- frankly I myself am amazed whenever I realize that I don't even  
> know myself how much stuff is in there.  There's more than I can keep  
> track of consciously any more!

See the link about compactness, above. :-)

Thanks for the opportunity to give input; you're doing a fine job!


More information about the PEAK mailing list