MPNotifications.h |
The MPNotifications class aids in handling notifications of port activity that are to be
sent to Framework clients. The following constants MPMSG, MPINFO, MPWARN, MPERROR, MPDEBUG
define the names of notifications that Framework clients can register for.
The posted notificaion's userInfo dictionary contains the following keys and values
MPNOTIFICATION_NAME - The name of the notification e.g. MPWARN, MPDEBUG etc.
MPCHANNEL - The channel to which the message was logged eg. stdout, stderr
MPPREFIX - The prefix string for this message e.g. DEBUG:
MPMETHOD - The method whose execution led to this notification eg. sync, selfupdate
MPMESSAGE - The output message logged to channel
THERE IS A REASON I'M NOT INCLUDING MPALL AS ONE OF THE POSSIBLE NOTIFICATIONS TO REGISTER FOR.
HOW IS THE FRAMEWORK SUPPOSE TO KNOW THAT SOMEONE HAS REGISTERED FOR ALL NOTIFICATIONS? THE ONLY
WAY TO DO THAT THAT I CAN SEE IS FORCING CLIENTS TO USE A CUSTOM METHOD (THAT UPDATES SOME
INTERNAL VARIABLE) OTHER THAN THE COCOA NSNOTIFICATION METHODS FOR REGISTERING ... I DON'T
WANT TO DO THAT.
SO CLIENTS CAN BOTH REGISTER FOR AND BLOCK CERTAIN NOTIFICATIONS FROM BEING SENT ... IS THIS
TOO MUCH FLEXIBILITY? WILL THIS GET CONFUSING? IF I WAS A FRAMEWORK USER I WOULD JUST
REGISTER FOR THE NOTIFICATIONS I'M INTERESTED IN AND NOT CARE ABOUT THE REST. BUT ON THE
FRAMEWORK SIDE I DON'T WANT TO GO THROUGH OVERHEAD OF SENDING A NOTIFICATION OF THE CLIENT
IS DEFINITELY NOT GOING TO USE IT ....
OK DISCUSS WITH RANDALL.
Last Updated: Wednesday, September 03, 2008