Alternate Proposal for Secure Messaging

[ilinkuo]

Taking a lot of ideas from @montlebalm in #150.

Here's a fiddle: http://jsfiddle.net/ilinkuo/n7pz2/7/

Features:

• (Security) Instead of wide open topics, emit/publish happens on a private channel between Container and App by default.
• Wide open topic publishing in the old style should be made available via emitTopic, subscribeTopic (not implemented)
• Apps are automatically subscribed to a group channel
• A vendor channel subscription can be added as well (not implemented)
• (Security) Channels can have policies set via setPolicy(). This should be done by the app itself, but in this fiddle is done by Container.
• (Security) Policies are assigned per channel. Policies can determine who gets to emit to channel (implemented) and who gets to subscribe to channel(not implemented). Policies restrictions can be by vendor (not implemented), by appid (implemented), or by instance(not implemented)
• (Security) F2.Events public object is no longer exposed
• Each instance receives its own EventsEmitter accessor via a constructor argument. * The accessor is expored to the public in the fiddle, but in general should be kept in a closure. However, the App may also choose to delegate its message sending ability by handing over the ee object or its emit method handle to a third party.
• (Security) An App can hijack its own emitter's methods without affecting any other App instance.

Details

• The implementation technique is by implicitly prefixing the event name with "namespaces". I call this Implicit Namespacing
• By prefixing, the App can still use its own event namespaces without any interference at all from the prefix
• This uses no advanced features from the EventEmitter2, so this can be done the same way injQuery or Dojo eventing.