[MacPorts] Notification: MPFramworkGSocWk modified

[MacPorts]

Changed page "MPFramworkGSocWk" by armahg at macports.org from 139.147.156.115*
Page URL: <http://trac.macports.org/wiki/MPFramworkGSocWk>
Diff URL: <http://trac.macports.org/wiki/MPFramworkGSocWk?action=diff&version=9>
Revision 9

-------8<------8<------8<------8<------8<------8<------8<------8<--------
Index: MPFramworkGSocWk
=========================================================================
--- MPFramworkGSocWk (version: 8)
+++ MPFramworkGSocWk (version: 9)
@@ -153,8 +153,16 @@
 and svn co http://svn.macosforge.org/repository/macports/users/armahg/MacPorts_Framework/MPFMidtermRelease/ for the whole folder
 
 
+= Weeks 8 & 9 =
+I scrapped my initial solutions to the Notifications issue and just embedded all the
+code for the Tcl notifications command within MPInterpreter.m. I also added an MPNotifications class whose main function is to let Framework users block and unblock sending of various notifications. It seems like too much flexibility on first thought: A framework user can turn on e.g. Debug notifications, then choose to register for them or turn them off. Why didn't I just let users choose to register and then send all notifications? I didn't want the Framework to become sluggish because of NSNotification "flooding".
 
+I was almost done with most of the Framework's functionality when I ran into a small problem: Authorization. Technically, the approach we are using is to use NSError handling to report errors to Framework users, they can then proceed from there by taking an appropriate action based on the error reported. I decided to try this out by putting myself in the shoes of a Framework User (with the Framework Tester GUI App.). What I found out was that, for processes that required running as root, we couldn't do things the way Apple recommends. This is because we haven't really factored out root operations into some binary executable within the Framework.
 
+I was a bit panicky at first but then I realized, we could just have an executable that called the very same method that we were calling before (with the right arguments of course). So right now here is our basic policy for Authorization. We have our own internal auth ref which we preauthorize. We have clients implement a delegate method with which they can override our internal auth ref with their own. When it comes to time to call the root process, we check for authorization with whichver auth ref we happen to have. If we gain permission we go ahead with the process, else we report the error back to the client.
+I think thats a sane solution (and it was all Randall's idea :P).
+
+Ok .. its off to coding now then ...
 
 
 

-------8<------8<------8<------8<------8<------8<------8<------8<--------


* The IP shown here might not mean anything if the user is behind a proxy.

--
MacPorts <http://www.macports.org/>
Ports system for Mac OS

This is an automated message. Someone at http://www.macports.org/
added your email address to be notified of changes on MacPorts.
If it was not you, please report to http://www.macports.org/.