Hello, I've been thinking about this proposal for the whole day; William has suggested me to write it here, to hear directly from you, to hear your feedbacks and, most thing important for me, your objections. Ah! I was about to forget, my name's Michelangelo De Simone, I'm very pleased to meet you all.:) Synopsis 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. Visionary scenarios Mike (limited user) wants to use an Adium version built on his own, to accomplish that he launches a MacPorts/MaPoD client, search for Adium in the search box, once he has found it he chooses to build and install it. The client confirms the action to Mike and giving him a notification that his version of Adium will be delivered directly into his ~/ Applications folder once the build process is over. The client becomes immediatly available for new commands. Amanda (limited user) already built Cyberduck but she needs it no more and then she decides to uninstall it. To accomplish that Amanda launches a MacPorts/MaPoD client, search for installed apps, once she has found Cyberduck she select it and mark it for removal. Her client confirms the action and becomes immediatly available for new commands. John (administrator on his own system) decides that Mike and Amanda need Gimp, so he decides to build and install it in order to let Amanda and Mike use it. To do that he launches a MacPorts/MaPoD client, search for Gimp; once he has found it he tells the client to install Gimp system wide, for users to use it. His client confirms the action and becomes immediatly available for new commands. Amanda (limited user) needs Gimp, so she starts looking for it with her MacPorts/MaPoD client and asks the client to build and install it. Client notifies Amanda that Gimp is already being built because of John choice to deploy it system wide and that she we’ll be able to use in some time; MacPorts/MaPoD will notify her with a Growl notification when Gimp will be ready to be used. Mike (limted user) asks himself how to remove objects and “stuff” produced by MacPorts/MaPoD and finds out that there’s no reason to be concerned about because MacPorts/MaPoD mantains itself scheduling maintance operations at the right time. Amanda (limted user) worries about tree sync and tries to manually update it using her client but it notifies her that the latest sync has been done automatically by MacPorts/MaPoD itself yesterday night. MaPoD Architecture Overview MaPoD aims to provide MacPorts additional features applying de- coupling among actual and future software components. See pic here: http://snipurl.com/22dyy The whole architecture of MaPoD shall be developed as a system service (LaunchDaemon), letting the clients at the upper layer request services asynchronously (“Build Adium, notify me when you are done”); users could also benefit from scheduled/automatic maintance operations such as self-update, application upgrades, tree syncs, objects cleanup. MaPoD Core ‘s task is to accomplish basic functionalities, wrapping those already provided by MacPorts’ port and adding them mechanism such scheduling, permission managment, event notifications (“Adium succesfully built by John”). No user on the system should sudo to build an app for his own use. MaPoD Interface is the real glue between MaPoD/MacPorts and GUI. Clients and MaPoD are completely loosly coupled because MaPod Interface provides a neutral way for them to communicate. Third party MacPorts developers could develop plugins to extend core functionalities (“Build Adium, notify me when you are done with a Growl notification” or “Build Adium, notify me when you are done with an email to jdoe@apple.com”). Conclusions With the appropriate choices any user on the same system, even limited ones, would see a full-featured MacPorts “distribution”; any user will have the possibility to search, install (from source or normal binary), remove his application with no touch to MacPorts at all. System administrator would also benefit from a fine grained permission system (“Do not let Mike build Adium” or “John can build and install only between 3pm and 9pm”). MacPorts installation would be “piloted” by MaPoD itself, so there will be no need to sudo-run it for occasional users. It’s clean, it’s “secure” (you know, Santa believes in security...:)). Whis this architecture possibilities are endless: how long would be needed to develop a plugin to mirror the tree among multiple nodes? How long to develop a web client and an adapter to manage the same build on multiple nodes? Obviuosly MacPorts core should never be used by users/clients, preferring MaPoD way to accomplish tasks. Back to the ground, there is much effort to spend and many issues to solve; first of all: how should MaPoD be launched, with whose privileges and permissions? Which technology should be used to develop all this stuff? Obj-C or C++ would be either good choices, once a good threading model has been decided (NSThread in 10.5 is a slightly forced choice). What about dependencies overlap? To respect decoupling how should MaPoD interface expose its own services? Stream/Socket interface? -- // Et quid amabo nisi quod rerum enigma est?