You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This issue is also related to the new programming model we're currently working on, but probably is outside the scope of this effort.
In the same way we're getting rid of the need for function.json files with the new programming model, and allowing the worker to provide the necessary metadata to the host, we could also git rid of the host.json file, and supply whatever metadata there to the host through the worker. An example would be:
This would get rid of an extra configuration JSON file, allow users to reduce boilerplate, by us providing defaults when appropriate, and providing intelliscence for host.json properties. However, this would require significant changes on the Functions Host side, since currently only the host is able to read host.json files, and the settings there are needed to configure some Host settings, before even spinning up a language worker. If work is done on the Host side to enable an alternative workflow, this may also impact cold start times. All this would be to ultimately get rid of one configuration file, as opposed to potentially hundreds of function.json files.
This issue is to collect feedback and discussion around this proposal and whether it's worth investing time and resources into.
The text was updated successfully, but these errors were encountered:
This issue is also related to the new programming model we're currently working on, but probably is outside the scope of this effort.
In the same way we're getting rid of the need for
function.json
files with the new programming model, and allowing the worker to provide the necessary metadata to the host, we could also git rid of thehost.json
file, and supply whatever metadata there to the host through the worker. An example would be:This would get rid of an extra configuration JSON file, allow users to reduce boilerplate, by us providing defaults when appropriate, and providing intelliscence for
host.json
properties. However, this would require significant changes on the Functions Host side, since currently only the host is able to readhost.json
files, and the settings there are needed to configure some Host settings, before even spinning up a language worker. If work is done on the Host side to enable an alternative workflow, this may also impact cold start times. All this would be to ultimately get rid of one configuration file, as opposed to potentially hundreds offunction.json
files.This issue is to collect feedback and discussion around this proposal and whether it's worth investing time and resources into.
The text was updated successfully, but these errors were encountered: