Skip to content
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

Closed
danielwiehl opened this issue Aug 4, 2022 · 0 comments
Closed

Unique identifier for capabilities and intentions #162

danielwiehl opened this issue Aug 4, 2022 · 0 comments

Comments

@danielwiehl
Copy link
Collaborator

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.

@Marcarrian Marcarrian self-assigned this Oct 31, 2022
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.
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
Projects
None yet
Development

No branches or pull requests

2 participants