Changes between Initial Version and Version 1 of MacPorts.Framework_Roadmap

Timestamp:

May 27, 2008, 4:14:15 PM (16 years ago)

Author:

armahg@…

Comment:

--

MacPorts.Framework_Roadmap

@@ +1 @@
+The following are notes by my mentor Randall Wood on the MacPorts.Framework
+GSoC project. I will be using them as a sort of Roadmap to track my progress as the summer progresses.
+
+= MacPorts Frameworks =
+The MacPorts Project would benefit from having Cocoa frameworks wrapped around the core APIs. Currently in a user's space on the MacPorts SVN server, there is a rough MacPorts.Framework. This document attempts to define a stronger framework. Please note that when this document refers to a current class or the current state, it is referring to the existing Framework code.
+
+== MacPorts Foundation (MacPorts.Framework) ==
+The MacPorts Foundation needs to provide for the following capabilities:[[BR]]
+1. Allow for Port discovery (search the PortIndexes)
+This is trivial and the current MPMacPorts class provides methods for doing this.
+
+2. Provide information about Ports (state, indexed information, files, etc)
+The port discovery methods return wither a single MPPort object or an array of such objects. The MPPort currently provides state and indexed information about the port.
+
+3. Manipulate Ports (install, uninstall, upgrade, etc)
+The MPPort class has methods for doing this, but they are incomplete as they accept no arguments (like a list of variants during install)
+
+4. Expose the MacPorts configuration
+With some exceptions, this is not currently done, and may not be really necessary. The important exception is that there is a method for getting the MacPorts ${prefix} path.
+
+5. Notify the system of MacPorts activity (upgrade/installation/uninstallation of port foo has started/stopped/failed)
+I think this may be the most difficult part of making this framework, but that may simply reflect the reality that I have not been able to sit down for more than about an hour at time to work on it. I think the ideal situation would be that activity in the Foundation framework should be spewed in either local or global notifications depending on the activity
+
+
+
+== MacPorts Application Kit (MacPortsAppKit.Framework) ==
+The MacPorts Application Kit should provide the following:[[BR]]
+1.  A memory resident index of ports that can be rapidly searched
+This is currently the MPIndex class, but I think this can be pulled from the Foundation, as it really only benefits GUI applications where rapid response to user input is required
+
+2. A GUI for authenticating to perform MacPorts activities
+This would entail embedding a helper application in the AppKit that can be launched in a privaleged manner to perform privaleged tasks. It should use the standard Authorization services to the greatest extent possible
+
+3. A GUI for selecting variants
+A panel that can be attached to a window?
+
+4. A GUI for responding to errors and --force requests
+Another panel that can be attached to a window?
+
+5. Extend MPPort to add methods identical in scope to the standard methods (install/uninstall/upgrade/etc) that accept the (id)sender argument and enable a GUI for handling the standard MPPort methods
+This is basically a requirement to make MPPort behave as expected in a GUI environment and is an enabler for those panels that the AppKit provides. Ideally the sender should be an NSWindow, NSWindow Delegate, or an MPMacPorts Delegate (see 6 below)
+
+6. Define a protocol for delegates to handle feedback
+The delegates would be delegates to MPMacPorts as extended by the Application Kit and delegation would allow for applications to override the App Kit to use their own GUI or to automate activities that the Framework should not (for example, the App Kit should not automate the forcing of the uninstallation of an inactive port, but a GUI application may allow a user to say that it should always force that, in which case the Application would just tell the App Kit to drive on).
+