Architectural proposal

Sat Mar 22 17:42:08 PDT 2008

By the way,  Michelangelo is proposing this in general, but is also  
looking to do part of this for GSoC.  I wanted him to solicit  
feedback, especially since this idea touches on a lot of the tasks  
we're looking for in GSoC (privilege separation, GUIs, etc).

-Bill

On Mar 22, 2008, at 5:21 PM, Michelangelo wrote:
> 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?
>
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

----
William Siegrist
Software Support Engineer
Mac OS Forge
http://macosforge.org/
wsiegrist at apple.com
408 862 7337

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2421 bytes
Desc: not available
Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080322/65c4825e/attachment-0001.bin 