Architectural proposal

[Jordan K. Hubbard]

On Mar 22, 2008, at 5:21 PM, Michelangelo wrote:

> MacPortsDaemon (“MaPoD”) is an additional layer above the existing  
> MacPorts utilities and API that provides asynchronous access to  
> MacPorts functionalities (and new ones) to upper layer clients. It’s  
> based on a pluggable architecture.

Hmmm.

OK, so, I read through this description and I read through all the  
scenarios, then I went back and read the message from start to finish  
again, just to make sure I hadn't missed any of the subtle details,  
and my conclusion was the same as the first time:  An additional layer  
to get what you want in the scenarios described sounds like over- 
engineering.

All of the scenarios could just as easily be satisfied by another  
Cocoa port front-end that does the Growl notifications and the UI and  
everything else you've described.  Such an application could also use  
the existing port(1) infrastructure directly, no intermediate layer or  
management daemon would be necessary to install / manage ports in the  
manner you describe (some of your per-user scenarios aren't  
particularly compelling, btw, seeing that macports pretty much assumes  
a single global $prefix and starts to break once you retarget ports  
piecemeal).

If you wanted this capability on the command line, then things become  
a little different in design and scope, but you still don't need a  
separate daemon or layer to accomplish something similar to shell job  
control for multiple outstanding port operations.

Don't get me wrong, I think something which lets you manage multiple  
in-flight operations and provides a good segregated status UI for  
managing them all is a fine idea, I simply think that a single  
application can accomplish those goals without needing to change or  
substantially augment the ports infrastructure at all.  Given how  
limited a commodity time is, I also think that's a good thing.

- Jordan