-
Notifications
You must be signed in to change notification settings - Fork 9
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
Unique identifier for capabilities and intentions #162
Comments
Marcarrian
added a commit
that referenced
this issue
Nov 8, 2022
closes #162, closes #171 BREAKING CHANGE: Using unique identifier for capability and intention ID introduced a breaking change. Previously, the IDs used for capabilities and intentions were stable but not unique, which caused problems when deregistering capabilities and intentions. If your application requires stable capability identifiers, you can register a capability interceptor, as follows: ```ts import {Capability, CapabilityInterceptor} from '@scion/microfrontend-platform'; import {Crypto} from '@scion/toolkit/crypto'; import {Beans} from '@scion/toolkit/bean-manager'; Beans.register(CapabilityInterceptor, { useValue: new class implements CapabilityInterceptor { public async intercept(capability: Capability): Promise<Capability> { const stableId = await Crypto.digest(JSON.stringify({ type: capability.type, qualifier: capability.qualifier, application: capability.metadata!.appSymbolicName, })); return { ...capability, metadata: {...capability.metadata!, id: stableId}, }; } }, multi: true }) ```
Marcarrian
added a commit
that referenced
this issue
Nov 8, 2022
closes #162, closes #171 BREAKING CHANGE: Using unique identifier for capability and intention ID introduced a breaking change. Previously, the IDs used for capabilities and intentions were stable but not unique, which caused problems when deregistering capabilities and intentions. If your application requires stable capability identifiers, you can register a capability interceptor, as follows: ```ts import {Capability, CapabilityInterceptor} from '@scion/microfrontend-platform'; import {Crypto} from '@scion/toolkit/crypto'; import {Beans} from '@scion/toolkit/bean-manager'; Beans.register(CapabilityInterceptor, { useValue: new class implements CapabilityInterceptor { public async intercept(capability: Capability): Promise<Capability> { const stableId = await Crypto.digest(JSON.stringify({ type: capability.type, qualifier: capability.qualifier, application: capability.metadata!.appSymbolicName, })); return { ...capability, metadata: {...capability.metadata!, id: stableId}, }; } }, multi: true }) ```
Marcarrian
added a commit
that referenced
this issue
Nov 8, 2022
closes #162, closes #171 BREAKING CHANGE: Using unique identifier for capability and intention ID introduced a breaking change. Previously, the IDs used for capabilities and intentions were stable but not unique, which caused problems when deregistering capabilities and intentions. If your application requires stable capability identifiers, you can register a capability interceptor, as follows: ```ts import {Capability, CapabilityInterceptor} from '@scion/microfrontend-platform'; import {Crypto} from '@scion/toolkit/crypto'; import {Beans} from '@scion/toolkit/bean-manager'; Beans.register(CapabilityInterceptor, { useValue: new class implements CapabilityInterceptor { public async intercept(capability: Capability): Promise<Capability> { const stableId = await Crypto.digest(JSON.stringify({ type: capability.type, qualifier: capability.qualifier, application: capability.metadata!.appSymbolicName, })); return { ...capability, metadata: {...capability.metadata!, id: stableId}, }; } }, multi: true }) ``` Note that the communication protocol between host and client has NOT changed.
17 tasks
Marcarrian
added a commit
that referenced
this issue
Nov 8, 2022
closes #162, closes #171 BREAKING CHANGE: Using unique identifier for capability and intention ID introduced a breaking change. Previously, the IDs used for capabilities and intentions were stable but not unique, which caused problems when deregistering capabilities and intentions. If your application requires stable capability identifiers, you can register a capability interceptor, as follows: ```ts import {Capability, CapabilityInterceptor} from '@scion/microfrontend-platform'; import {Crypto} from '@scion/toolkit/crypto'; import {Beans} from '@scion/toolkit/bean-manager'; Beans.register(CapabilityInterceptor, { useValue: new class implements CapabilityInterceptor { public async intercept(capability: Capability): Promise<Capability> { const stableId = await Crypto.digest(JSON.stringify({ type: capability.type, qualifier: capability.qualifier, application: capability.metadata!.appSymbolicName, })); return { ...capability, metadata: {...capability.metadata!, id: stableId}, }; } }, multi: true }) ``` Note that the communication protocol between host and client has NOT changed. You can independently upgrade host and clients to the new version.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
The IDs assigned to capabilities and intentions are not unique since the ID is calculated as a hash from the manifest objects (type, qualifier, appSymbolicName). This can be problematic, particularly when registering/deregistering intentions at runtime.
Expected behavior
Instead of a hash, the platform should assign a UUID to capabilities and intentions. If an application needs a stable identifier for capabilities/intentions, the application should implement such a mapping. For example, SCION Workbench needs a stable identifier for capabilities to implement persistent navigation.
The text was updated successfully, but these errors were encountered: