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