pnoltes commented on code in PR #710: URL: https://github.com/apache/celix/pull/710#discussion_r1451786664
########## bundles/remote_services/remote_service_admin_dfi/src/remote_service_admin_dfi_constants.h: ########## @@ -36,6 +36,15 @@ #define RSA_DFI_CONFIGURATION_TYPE "org.amdatu.remote.admin.http" #define RSA_DFI_ENDPOINT_URL "org.amdatu.remote.admin.http.url" +/** + * @brief RSA Configuration type for zeroconf http, it is synonymous(https://docs.osgi.org/specification/osgi.cmpn/7.0.0/service.remoteservices.html#i1698916) with RSA_DFI_CONFIGURATION_TYPE, they refer to the same endpoint. Review Comment: I have some new thoughts about the dynamic ip assignment resolving challenges. First off, I think is good to come to a sound conclusion, but this does not mean that this should be directly solved in this issue. So if we agree on a desired solution, I will make a ticket for this and we can then decide what should flow back to this PR. My thoughts: a) Let RSA implementations decide if they support "dynamic IP fill-in" by providing a additional service property on the registered RSA service b) Optionally RSA export registration that support dynamic IP fill-in should also opt-int for dynamic replacement by adding a endpoint property to the export registration properties c) Let discovery implementations decide if the they support "interface specific" endpoints by providing a additional service property on the registered endpoint listener interface. c) Update the Topology Manager to detect RSA services what support dynamic IP fill-in and in that case create multiple endpoints for a single export registration based on the available network interfaces and an optional network selection configuration. These endpoints are then forwarded to the discovery listener services that support network specific endpoints. The discovery implementation can pick and handle or drop endpoints based on the selected network interface. The primary idea is that most of the boiler-plating to support dynamic IP fill-in is moved to the topology manager and kept away from the RSA and discovery implementation. For the service/endpoint property something like the following can be used: - RSA Dynamic IP fill-in support - Property name: "rsa.dynamic.ip.support" - Type boolean - Indicates whether the RSA implementation supports dynamic IP address fill-in for service exports - RSA Export Registration replacement opt-in - Property name: rsa.export.dynamic.ip.optin - Type boolean - Description: Signals if a service export opts in for dynamic IP address replacement - RSA Export Registration dynamic replaceable property - Property name: rsa.ip.address - Type string - Description: The dynamically determined IP address for the endpoint. - Discovery interface-specific endpoints support. - Property Name: "discovery.interface.specific.endpoints.support - Type boolean - Description: Indicates if the discovery implementation supports handling of interface-specific endpoints. I understand that this is different from the current solution, but maybe a more cleaner approach. WDYT? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@celix.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
