-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ability for other adapters to automatically request forwarding of specific URLs #134
Comments
In general a good idea.,m The question is basically how to configure this and also how to store this. So yes an adapter could adjust the config diretcly on the object or via a message, but as soon as this gets persoisted and the other adapter gets deleted this entry stays here ... So when we need some other way to configure such proxy routes which would require a io-package flag/enhancement to dynamically build this on startiup additionally to config or such |
Yes and no. The proxy adapter could monitor status of those adapters it receives messages from and remove rules when the other adapter dies. Ie.
With this solution Point 2. would need to be achieved with a 'persistant message' library or similar that itself subscribes to the status of the destination proxy adapter (eg. The above does seem slightly inelegant though. I do note that there is a mechanism by which each adapter can contain specific 'settings' relevant only when another specific adapter is installed - think I saw this with history, lovelace, etc. Surely that would be a better option? Only the 'settings' would be set automatically from the adapter and not manually in admin. |
What I just said here...
.. in fact, maybe that isn't true. If 'settings' for an adapter instance were automatically configured, wouldn't it be down to any proxy instance to look at these (startup or via subscription) and act accordingly? Would then need a mechanism for requesting adapter (Eg. ACME) to check it's 'settings' had been noted and the providing instance was actually running before attempting to use that. |
Currently it seems that routing of paths to other adapters must be configured manually. However, imagine a world where an adapter can request a path be send to it without any user intervention. Ie. Imagine the ACME adapter could request
/.well-known/acme-challenge/...
be forwarded to it for handling (noting that that path cannot currently be handled - see #133).A mechanism such as this that performed automatic forwarding where necessary would be very useful and simplify installation/administration.
The text was updated successfully, but these errors were encountered: