Open grahamehorner opened 7 years ago
In general, we try to be very strategic about the public surface area we expose and keep it to a minimum. These internal interfaces get modified frequently. We do have an abstraction that lets you decouple from storage. (see https://github.com/Azure/azure-webjobs-sdk/blob/1d6e30fd719b85b0b0c6cf9e8a0b07e1e0a26bef/src/Microsoft.Azure.WebJobs.Host/Singleton/IDistributedLockManager.cs ) . What exactly do you need exposed?
Please consider allowing for custom implementations for storage/providers clients, JobHost & JobInvoker etc. at present the implementation has a number of internal interfaces and implementations which makes swapping out services for custom implementation (such as on premise or service fabric) difficult.
Initially my use case was to allow the hosting of WebJobs/JobHost inside of a ServiceFabric cluster, replace the storage with the internal ServiceFabric package store and allowing the JobHost to trigger ServiceFabric actors by way of WebJob Functions