Update Engines RFC to reflect developments in and lessons from this addon

[dgeb]

• Document {{mount}} keyword
• Include as option for mount method to allow engine aliases
• Should we allow arbitrary configuration attributes to be passed from the consuming application to the engine?
• What is the long term future of this addon? Can it continue to exist by overriding only public methods?
• Go further in depth into lazy loading issues (e.g. separation of route serializers)
• Should we remove the section about potential namespaced access to engines from parents?
• Discuss synergies with routable components

[knownasilya]

Should we allow arbitrary configuration attributes to be passed from the consuming application to the engine?

That might be nice, but how is it any different from sharing a service? Could you use it to build the engine differently or something?

[rwjblue]

Discussion from Ember F2F:

Should we allow arbitrary configuration attributes to be passed from the consuming application to the engine?

Yes, the {{mount}} template keyword should allow normal handlebars style hash arguments. The router DSL style should also allow some sort of API to supply parameters too, but the exact API is less obvious.

What is the long term future of this addon? Can it continue to exist by overriding only public methods?

We decided that all overrides should be moved upstream into Ember itself, and that this addon will still continue to exist to provide blueprints/commands/etc as well as be the "single source" for importing Engine.

[dgeb]

Closing because the RFC has been merged and the remaining issues are now being tracked separately.