our clients will be creating a SWF (most likely NOT a PureMVC application) that will need to respond/send notifications to our PureMVC multicore application
Are you saying
A) Their swf actually has compiled in at a minimum the PureMVC Notification class or INotification interface and you'll be passing an actual INotifications to the swf and expect them to somehow send them (without having a facade).
OR
B) Their swf will have some sort of API of events, methods, and message classes that you will be communicating with and your mediator needs to mediate this swf, turning the events it gets from the module into outbound notifications and inbound notes into messages and/or method calls on the swf.
HINT: B is the sane option here. Create a protocol that includes an interface and some message classes. Mediate their module like any other view component.
I have a hard time understanding why path A would be a requirement.
is there a way to add notification interests more dynamically as their SWF may not know once it "load completes" all the notifications it will need.
When will it know? At what point in its lifecycle will it know everything it's interested in? Mediate at that point and not until. Mediator interests are fixed.
Also, this situation raises some serious encapsulation and dependency issues. How is the third-party swf supposed to know the actual notification names that your application is sending around internally? How is the protocol defined and enforced? Do the third-party swf and your application both share a common constants or configuration file?
-=Cliff>