Architectural proposal

[Michelangelo]

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 at 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?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2409 bytes
Desc: not available
Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080323/5a6d097a/attachment.bin